Status: pvData, pvAccess, and pvIOC

Matej Sekoranja, Cosylab

Marty Kraimer, BNL

EPICS Collaboration Meeting, Rutherford Appleton Laboratory

May 2013

Table of Contents


This talk provides that status of the Java and C++ implementations of pvData, pvAccess, and pvIOC. These, especially pvData and pvAccess, are the basic components for implementing the services described in other pvdata talks.


A complete implementation of pvData is available in both Java and C++. The 2.0-BETA release has the complete implementations.

Current work involves two main components: Scalar Arrays and Conversion Facility:

Scalar Arrays

Michael Davidsaver is currently working on a new implementation of Scalar Arrays, i. e. PVByteArray, ..., PVStringArray. His effort is for the C++ implementation of pvData. The focus is efficency. There will be two major changes in the underlying implementation:

Complete Array Always Present
This existing implementation allows an array implementation that provides data in "chunks".
An example is a software driver for a camera. The camera has storage for a complete image. The driver allocates memory for a small sub-array. When data is requested it is made available in chunks by transfering data from the camera to the sub-array.
This feature has never been used and will no longer be supported. (The main reason is that limited memory platforms are becoming rare.)
Non-contiguous Arrays Allowed
This will be allowed and in fact will be provided by the default implementation. This allows the creation of a pool of memory chunks (the size chosen to optimize cpu usage for copy operations) that can be used by array instances. This helps reduce new/delete calls to allocate and free memory for arrays.

After Michael has a working implementation in C++, an effort will be made to see if a similar technique can be used for the Java implementation.

Conversion Facility

Work is being done on both the C++ and Java Conversion Facility. For 2.0-BETA The conversion facility is called Convert. In Java it is an interface named Convert and in C++ a class named Convert.

A lot of code is related to scalar array conversions, which requires extensive changes for the new implementation of scalar arrays. As part of his effort on the C++ changes, Michael is also looking at refactoring the conversion facility.

David Hicken has taken responsibility for the Java implementation of Convert. He has made significent improvements to conversions between the various numeric types. PVData supports unsigned integers but Java does not have unsigned primitive data types. David has made changes for conversion between unsigned and signed data types that are more logical than the original implementation.

When Michael has the C++ changes for arrays and the conversion facility working, he and David will work together to keep the Java and C++ conversion facilities as similar as makes sense.


A complete implementation of pvAccess is available in both Java and C++. The 2.0-BETA release includes a complete implementation of each.

In the last 6 months all the time on pvAccess development was spent on C++ implementation. The following tasks were implemented:

Direct (i.e. no-copy) Serialization/Deserialization Support for Arrays
This allows array values to be serialized/deserialized directly to/from the socket buffers. This raises throughput performance on fast networks (1Gbit+).
Performance Benchmarking and Micro-benchmarking Utilities
Benchmarking utility allows continuous generation of benchmark results during the development process. Micro-benchmarking helps reveal bottlenecks and places in the code where performance is lost.
eget improvments
Support of various normative types was added (tables, matrices, images), new options implemented, and performance was improved.
pvAccess RPC Mini-Framework
This allows programmers to develop pvAccess RPC servers and clients with great ease.


A complete implementation of pvAccess is available only in Java. The 2.0-BETA release includes the complete implementation. In fact it has more than it should.

The C++ version of pvIOC has almost none of the features that the Java version provides.

Because the Java and C++ versions are so different each will be discussed separately.


Originally the pvdata project was named JavaIOC and everything resided in a single repository. For the 2.0-BETA release pvIOCJava still has all of the older components except pvData and pvAccess. Since the 2.0-BETA release swtshell and portDriver have been moved to separate repositories.

swtshell now works only as a remote shell. Thus it can be rewritten in Java or another language and/or using a different GUI framework than SWT. CSS (Control System Studio) now provides many of the features that swtshell provides. Perhaps plugins could be implemented for the missing features (channelPutGet, channelArray, and channelRPC).

portDriver is the name of the Java implementation of asynDriver. As far as We know there has been no use of portDriver in any facility. Thus looks like no interest. The major problem is lack of: 1) low level drivers, 2) STREAMS, 3) synAPPS, and 4) areaDetector. The four things listed have a lot more code than portDriver. Will anyone ever be interested in a Java version of any of this? Maybe not.


The 2.0-BETA release has only two useful components:

pvAccess server support for accessing V3 records, i.e. records as defined by iocCore. It allows a pvAccess client to connect to a V3 record using the pvAccess network protocol.
Base Classes for pvAccess Server
These base clases implement "glue" code for implementing a pvAccess service. But any code that implements a server must supply code that implements some combination of channelGet, channelPut, ..., monitor.

v3Channel has now been moved to a separate project named pvaSrv with Ralph Lange in charge. The glue code for pvAccess will be moved to pvAccessCPP. At that time pvIOCCPP will have no useful code.


There are now efforts underway, e. g. an image application that communicates with the area detector support based on asynDriver. But such efforts, for now, either support limited features of pvAccess or require lots of code.

A new project named pvDatabaseCPP is being developed, initially by Marty Kraimer, that will provided some of the features implemenented by pvIOCJava. The first features are a complete implemenentation of a pvAccess server for a top level PVStructure. A service only needs to supply two things:

A top level PVStructure that holds the data the service uses to communicate with a client.
A method that is called when a client asks for it to be called.

pvDatabaseCPP will implement all channel methods except channelRPC (glue code is already provided by pvAccess). It will implement monitors and the ability to transmit only modified data from the server to the client. In short it will make it easier to implement services that provide complete support for pvAccess.