Design & Evaluation of a Highly Modular CORBA Portable Object Adapter

1. Design & Evaluation of a Highly Modular CORBA Portable Object Adapter Raymond Klefstad Douglas C. Schmidt Elec & Comp. Eng. Dept klefstad@uci.edu schmidt@uci.edu Arvind S. Krishna Info & Comp. Sci. Dept Krishnaa@uci.edu University of California, Irvine Distributed Objects & Applications (DOA) Conference 23 September 2014

2. Technical Goals for the ZEN Real-time ORB • Real-time CORBA using Real-time Java • Easily Extensible • Code and compile new alternatives • Dynamically “plug” them in/out of the ORB • e.g., new protocols, Object Adapters, IOR formats, etc. • Flexible Configuration • Small footprint • Load components only as needed • On-demand or at initialization time • Real-time performance • Bounded jitter for ORB/POA operations • Eliminate sources of priority inversion • Access to Real-time Java features in ORB by applications • Low startup latency

3. Virtual Component Design Pattern Intent • Application transparent way of loading and unloading components implementing middleware functionality Problem • Features and options for standards based middleware are large and growing • Few embedded applications use all the functionality provided • Cannot eliminate capabilities based on any particular embedded system Solution • Identify components whose interfaces represent building blocks • Define concrete components that implement capabilities • Define factories that create the concrete components using a set of loading/ unloading strategies ZEN applies the Virtual Component pattern to the CORBA Portable Object Adapter

4. What is a Portable Object Adapter (POA)? • A POA maps remote client requests to local servants • Capabilities • Generate Object References • Activate/objects • Incarnate/Etherealize servants • Demultiplex client requests to the appropriate servants • Customization based on policies • Key Components • Adapter Activator • Servant Managers • POA Manager • The POA is a large chunk of code: adds considerably to server footprint • To reduce foot print apply the Virtual Component Pattern to make POA pluggable Two levels of pluggability: (1) Coarse grained & (2) Fine grained

5. Coarse Grained Pluggability • Context • A POA maps client requests to server servants • Several types of POAs: • Standard POA: For non-real-time applications • Min POA: Reduce memory footprint & features • Real-time POA: Ensures predictability required for real-time systems • Problem • Each application needs only one type of POA • Moreover, Servers and peers need a POA, but clients do not • Solution • Apply Virtual Component pattern to allow the POA to be plugged in/out as one piece This level of granularity has been implemented in TAO But we can we do better and reduce the footprint of servers & peers?

6. Fine-Grained POA Pluggability POA Policies • POA’s behavior is governed by the policies associated with it • Servers need only a few of the features provided by a POA • Many applications use only a Root POA • Root POA has only one policy value from each policy (indicated in red) associated with it • Request Processing Policy • Use Active Object Map Only • Use Default Servant • Use Servant Manager • Implicit Activation Policy • Implicit Activation • No Implicit Activation • Lifespan Policy • Persistent • Transient • Thread Policy • - Single Thread Model • - ORB Control Model • - Main Thread Model • Id Assignment Policy • - System Id • - User Id • Id Uniqueness Policy • - Unique Id • - Multiple Id • Servant Retention • Policy • - Retain • - Non Retain • We decompose the POA across policies

7. Fine-Grain POA Architecture • Implement each policy value as a Virtual Component • E.g Servant Retention Policy • Retain • Non Retain • Each policy value is a different mechanism of enforcing the policy • Load only the components required based on policy values • POA Policy factory creates a concrete strategy for each of the abstract strategy

8. Activation Policy Strategy • Implements the Activation Policy • Values • Implicit Activation Strategy (flyweight) • Explicit Activation Strategy (flyweight) • Responsibilities • Validates operations that implicitly • activate servants: • _this(), • servant_to_reference() • validate() method on the concrete Activation strategy associated allows/disallows implicit Activation • Thread, Lifespan, and Activation Strategies are “Primary POA Components” • They are composed first during POA creation • The primary components associated with the POA influence rest of the strategies

9. Request Processing Policy Strategy • Overview • Implements the Request Processing policy • Strategized along • Active Object Map Only Strategy: • Default Servant Strategy • Servant Manager Strategy • Servant Locator Strategy • Servant Activator Strategy • Responsibilities • Handle client requests • handleRequest() method uses the Strategy plugged in to service client requests • Secondary components depend on the values of primary components • Other secondary components: • Id Assignment, Servant Retention, Id Uniqueness Strategies

10. Dual-CPU 1.7GHz Xenon (512Mb RAM) • Debian Linux 2.4.1, • javac compiler, JDK 1.4 JVM • ZEN: Latest Version • JacORB: Version 1.4 beta 4 Root POA Footprint Analysis Overview • Root POA is the base POA for all POAs created in an ORB • A Root POA suffices for many applications unless different QoS guarantees needed, e.g object persistence Experiment • Measures the footprint increase prior and after the call to resolve_initial_references(“RootPOA”) • In particular, the increase in “process space” was measured after the association of the Root POA with the Server • Results • ZEN ~ 61 k.B • JacORB ~ 180 k.B

11. Child POA Footprint Analysis Overview • Child POA created if different QoS guarantees required than provided by Root POA • Using the Micro POA design • considerably reduces the foot print • scale as most of the components implemented as flyweights Experiment • Variation in footprint with the number of POAs created measured • The increase in footprint prior to and after a create_POA method call measured in each of the • POAs created have the following policy values: User Id, Non Retain and Servant Manager. (Maximizes number of flyweights) • Results • ZEN ~ 35 k.B • JacORB ~ 250 k.B

12. POA Demultiplexing Steps Context • A key functionality of a CORBA ORB is to demultiplex client requests to the appropriate servants • Problem • Conventional Layered demultiplexing approach inefficient, causes increased priority inversions • Factors: • The POA hierarchy is arbitrarily deep • and/or the POA is managing a large number of Servants • and/or a Servant implements an interface with a large number of operations

13. POA Demultiplexing Strategies • Demuxing Strategies • Linear Search, Binary Search,Dynamic Hashing, Perfect Hashing and Active Demultiplexing ZEN Solution • Use Active Demultiplexing and Perfect Hashing to ensure O(1) worst case time bound for all the demultiplexing stages

14. ZEN POA Demultiplexing Overview • The first step involved in request demultiplexing is finding the Object Adapter • The POA Hierarchy can be arbitrarily nested Test Description • Variation in POA demultiplexing time with the depth of the POA hierarchy measured Result Synopsis • Active Demultiplexing provides constant latency irrespective of POA hierarchy • Dynamic Hashing degrades with depth • Dual-CPU 1.7GHz Xenon (512Mb RAM) • Debian Linux 2.4.1, • javac compiler, JDK 1.4 JVM Active Demultiplexing ensures O(1) worst case lookup time for POA Demultiplexing

15. ZEN Servant Demultiplexing Overview • The POA finds the servant associated with the object • A POA can manage arbitrary number of objects in the AOM Test Description • Latency variations with the increase in number of servants measured Result Synopsis • Dynamic Hashing higher overhead, degrades with number of servants • Active Demultiplexing provides constant time latency Active Demultiplexing ensures O(1) worst case Servant lookup time

16. ZEN Operation Demultiplexing Overview • The last step at the Object Adapter layer is to demultiplex request to the appropriate skeleton • Operation dispatch time varies with the number of methods in the interface Test Description • Variation in Operation Demultiplexing latency measured with number of methods Result Synopsis • Dynamic hashing has higher overhead and degrades ~ 4 u.s • Perfect hashing guarantees constant time bound ~ 1 u.s Perfect Hashing ensures O(1) worst case operation demultiplexing time

17. Future Research on ZEN • Complete implementation of RT CORBA specification • Utilizing RT Java features within the ORB and POA for RT CORBA • Ahead of time compile ZEN using jRate • TimeSys RTSJ implementation • Using Aspects to custom generate ORBs • Extend the pluggable protocol framework to handle other protocols

18. References • ZEN open-source download & web page: • http://www.zen.uci.edu • JacORB web page: • http://www.jacorb.org • Real-time Java (JSR-1): • http://java.sun.com/aboutJava/communityprocess/jsr/ jsr_001_real_time.html • Dynamic scheduling RFP: • http://www.omg.org/techprocess/meetings/schedule/ Dynamic_Scheduling_RFP.html • Distributed Real-time Java (JSR-50): • http://java.sun.com/aboutJava/communityprocess/jsr/jsr_050_drt.html • AspectJ web page: • http://www.aspectJ.org • JRate • http://tao.doc.wustl.edu/~corsaro/jRate/