The Java IOC

My colleague Eric got back from a weekend in Michigan staying with Marty Kraimer, one of the two original designers of EPICS. Marty left Argonne (he insisted he wasn't 'retiring') in February this year to concentrate on his new design for a reimplementation of the core EPICS IOC ideas in Java. He had presented a summary of his progress at the EPICS Collaboration Meeting held here in June, but at that stage the code wasn't particularly complete or functional, and I think Marty was a little disapointed with the response he got at the meeting — he was hoping that other people would be sufficiently interested to offer to implement some parts of the code.

Eric reports that Marty is still putting in his 6 hours a day at the programming, in addition to walking the dogs and going out in the canoe. The Java IOC now has several record types implemented, and the record processing and links between records are fully functional. The design does not make use of Lock Sets; each record has its own mutex lock, and for a link to be used to pass data the controlling record's process routine must take the lock of the target record. Performance-wise Marty is apparently achieving a processing rate of about five hundred thousand records per second on his Apple laptop machine. His simple test example consists of 4 records (a CALC and three AOs) with 4 different kinds of links connecting them together (one each of put, get, forward and monitor), and this combination loops in 2 microseconds.

I have to admit I'm personally still slightly skeptical that any current EPICS users are going to want to use this until Marty provides both server and client side connectivity using the existing Channel Access protocol, because one of the main advantages of EPICS is the ability to connect any client up to any server using CA. Once/if he supports CA I can see there being more interest, especially from the Control System Studio crowd.