The Performance of ZEN: A Real Time CORBA ORB using Real ... · Klefstad, et al. Real Time CORBA...

Monday, 09 September 2002Research Sponsored by AFOSR

The Performance of ZEN: A Real Time CORBA ORB using Real

Time JavaRay Klefstad, Mayur Deshpande, Carlos O’Ryan , Angelo Corsaro, Arvind S Krishna, Sumita Rao, Krishna Raman

[email protected]

Electrical & Computer Engineering Dept University of California, Irvine

University of California, IrvineUniversity of California, IrvineUniversity of California, IrvineUniversity of California, Irvine 2

Klefstad, et al. Real Time CORBA with ZEN

Outline

• Background and MotivationBackground and MotivationBackground and MotivationBackground and Motivation• RealRealRealReal----Time CORBA OverviewTime CORBA OverviewTime CORBA OverviewTime CORBA Overview• RealRealRealReal----Time Java OverviewTime Java OverviewTime Java OverviewTime Java Overview• ZEN Overview and GoalsZEN Overview and GoalsZEN Overview and GoalsZEN Overview and Goals• Generations of ORB DesignsGenerations of ORB DesignsGenerations of ORB DesignsGenerations of ORB Designs• ZEN’sZEN’sZEN’sZEN’s DesignDesignDesignDesign• Current StatusCurrent StatusCurrent StatusCurrent Status• Performance MeasurementsPerformance MeasurementsPerformance MeasurementsPerformance Measurements• Future WorkFuture WorkFuture WorkFuture Work• Concluding RemarksConcluding RemarksConcluding RemarksConcluding Remarks



Historical Challenges

Motivation for QoS-enabled MiddlewareTrendsTrendsTrendsTrends

•Many mission-critical distributed applications require real-time QoS guarantees•e.g., combat systems, online trading, telecom

•Building QoS-enabled applications manually is tedious, error-prone, & expensive

•Conventional middleware does not support real-time QoS requirements effectively

•Building distributed systems is hard•Building them on-time & under budget is even harder

•Hardware keeps getting smaller, faster, & cheaper

1 1Proxy

service

Service

service

AbstractService

service

Client

•Software keeps getting larger, slower, & more expensive

New Challenges



CORBA OverviewInterface

RepositoryIDL

CompilerImplementation

Repository

Client OBJREF

Object(Servant)

in argsoperation()out args +

return

DII IDLSTUBS

ORBINTERFACE

IDLSKEL DSI

Object Adapter

ORB CORE GIOP/IIOP/ESIOPS

•CORBA shields applications from heterogeneous platform dependencies•e.g., languages, operating systems, networking protocols, hardware

•Common Object Request Broker Architecture (CORBA)

• A family of specifications• OMG is the standards body• Over 800 companies

•CORBA defines interfaces, not implementations

• It simplifies development of distributed applications by automating/encapsulating

• Object location• Connection & memory mgmt.• Parameter (de)marshaling• Event & request demultiplexing• Error handling & fault tolerance• Object/server activation• Concurrency• Security



Real-Time CORBA Overview•RT CORBA adds QoS control to regular CORBA improve the application predictability, e.g.,•Bounding priority inversions & •Managing resources end-to-end

•Policies & mechanisms for resource configuration/control in RT-CORBA include:1.1.1.1.Processor ResourcesProcessor ResourcesProcessor ResourcesProcessor Resources• Thread pools• Priority models• Portable priorities

2.2.2.2.Communication ResourcesCommunication ResourcesCommunication ResourcesCommunication Resources• Protocol policies• Explicit binding

3.3.3.3.Memory ResourcesMemory ResourcesMemory ResourcesMemory Resources•Request buffering

•These capabilities address some important real-time application development challenges

Client OBJREF

Object(Servant)

in argsoperation()

out args + return

IDLSTUBS

IDLSKEL

Object Adapter

ORB CORE GIOP

Protocol Properties

End-to-End PriorityPropagation

ThreadPools

StandardSynchronizersExplicit

BindingPortable Priorities

SchedulingService

Real-time CORBA leverages the CORBA Messaging QoS Policy framework



Motivations for Using Java•Easier, faster developmentEasier, faster developmentEasier, faster developmentEasier, faster development• Memory management is simpler• Language support for concurrency and synchronization• Large and powerful library, including portable GUI• Dynamic language features (Class loading, Reflection)•Large programmer baseLarge programmer baseLarge programmer baseLarge programmer base• Over 1,000,000 (and growing rapidly!)• Taught at many universities• Easily picked up by C++, Ada Programmers•Recent RealRecent RealRecent RealRecent Real----time Java Specificationtime Java Specificationtime Java Specificationtime Java Specification• Provides necessary features for Real-time programming



Real-time Spec for JAVA (RTSJ) Overview• Memory Management• Scoped Memory• Disposed as a whole after the scope is exited.•Similar to stack memory in C++•ScopedMemory sm = new …; sm.enter(){ … }•sm.newInstance(Class.forName(”Vector”));

• Limitations on access to/from Heap• Lifetime is from creation to exit of last thread sharing it

• Immortal Memory• Lifetime is from creation to program exit

• Physical (and ImmortalPhysical) Memory• PhysicalMemory NVRam = new PhysicalMemory( 0xFF00, 1024);• Allows access to raw physical memory addresses• int i = NVRam.getInt( 0x0A ); NVRam.setInt( 0x0A, i+1 );

• Primitives only!• Heap Memory: regular garbage-collected heap

run(){---------------------}

Scoped Memory

SM Deallocated aswhole



RTSJ Overview (cont.)•Stronger guarantees on threads•Highest priority runnable thread is always run•Faster context switching•~1-2 Microseconds down from 100s

•Asynchronous Event Handlers (AEH):•Similar to Unix Signals and handlers:•Own no resources•Run in context of current thread•Can’t pass data to them

•Asynchronous transfer of control•Java: Can interrupt only when thread is in wait(), sleep() or join() •RT-Java: can interrupt methods at any time (Asynchronous)•Will wait until critical sections are exited

•Extensive Scheduling support•Schedulable Objects (threads, AEHs), Admission control, feasibility analysis•Extend base fixed-priority preemptive scheduler to fit needs

AsynchronousTransfer of

Control

Asynch Event

Fire

AsynchEventHandlers

Fire



Motivation for ZEN• Integrate best aspects of several key technologies:Integrate best aspects of several key technologies:Integrate best aspects of several key technologies:Integrate best aspects of several key technologies:• Java: simple, less error-prone, large user-base• RT-Java: real-time support• CORBA: standards-based distributed applications• RT-CORBA: CORBA with Real-time QoS capabilities

• ZEN project goals:ZEN project goals:ZEN project goals:ZEN project goals:• Make development of distributed, real-time, embedded

(DRE) systems easier, faster & more portable• Provide open-source RT-CORBA ORB written in RT-

Java to enhance international R&D efforts



Technical Goals for ZEN•Flexible ConfigurationFlexible ConfigurationFlexible ConfigurationFlexible Configuration• Small footprint• Load classes only as needed•On demand or at initialization time

•Easily ExtensibleEasily ExtensibleEasily ExtensibleEasily Extensible• Code and compile new alternatives• Dynamically “plug” them in/out of the ORB • e.g., new protocols, Object Adapters, IOR

formats, etc.

•RealRealRealReal----time performancetime performancetime performancetime performance• Bounded jitter for ORB/POA operations• Eliminate sources of priority inversion • Access to RT-Java features in ORB by Apps• Low startup latency

Legend

RT Java Application

ZEN Internals

IIOP VME ATM

JVM / OS / Network Interconnect

PluggableProtocols

Framework

RTPOA

MINPOA

PluggableObject

Adapters RT CORBAPersonality

FT CORBAPersonality

CORBASecurity

PortableInterceptors

CORBAMessaging

IORParsers

Core Component

Optional Feature

ZENCORE



Generations of ORB Designs•Standards-based middleware (ORB) must provide a wide range of features, many have a variety of behavior options, e.g., various protocols

• 1st Generation: Static monolithic ORB •All support code is in one executable,

OS virtual memory manages footprint• Footprint too large for some applications•E.g., original implementation of TAO,

many other ORBs•2nd Generation: Monolithic ORB with

compile-time configuration flags•Conditional compilation or smart linkers

remove unwanted parts of middleware• scores of options can overwhelm the application developer• accidental complexity due to conditional compilation•E.g., second generation of TAO



Generations of ORB Designs (cont.)•3rd Generation: Dynamic micro-ORB•Small kernel of required functionality•Various components are linked/loaded on-demand•E.g., newest version of TAO and ZEN•4th Generation: Dynamic reflective micro-ORB•ORB builds a configuration description for each application based on the application’s execution history•This is used to ``prime’’ the ORB, loading required components at init-time

•5th Generation: Static reflective micro-ORB•Application configuration and needs are learned by Dynamic reflective micro-ORB above•Generator builds a custom-ORB for each application• which may then be compiled and placed into ROM



ZEN Development Plan• Start with a flexible, extensible design based on TAO Design Patterns

• 1st Version: Focus on 3rd Generation: Dynamic Micro-ORB to identifypluggable components• Focus on Real-time requirements:

implementing RT CORBA features in RT Java• 2nd Version: Focus on 4th Generation:

learn from reflection which components are likely to be used and preload them at init-time• 3rd Version: Focus on 5th Generation:

static custom ORB generation•Use Reflection and Aspects•Statically configure and trim unused components automatically



Virtual Component Pattern• Intent: Application transparent mechanism to factor out currently unneeded components

•Mechanism:•Use Abstract interfaces for all components•Upon ‘component-fault’ load concrete implementations using:•Factory method and Repository•Strategy pattern •Proxy component

ConcreteImplementations

ConcreteImplementations

AbstractInterfaces

Main Memory

SecondayStorage

ComponentLoader

Proxy

Strategy



Micro-ORB vs. Monolithic ORB Designs•Lessons learned from building TAO• Implementing full-service, flexible ORB can yield

a monolithic implementation with huge footprint•Design patterns resolve design forces and

yield highly modular, extensible designs•Achieving a small footprint must be an initial

design goal•ZEN’s Design is based on Micro-Kernel OS design• Identify core ORB services whose behavior

may vary•Move each core ORB service out of the ORB by

applying the Virtual Component pattern• Implement alternatives and make them pluggable•Remaining kernel is called Micro-ORB kernel



ZEN’s Pluggable GIOP Messaging Handling•Context:Context:Context:Context:

• Eight different message typesEight different message typesEight different message typesEight different message types• Two methods for each: read/writeTwo methods for each: read/writeTwo methods for each: read/writeTwo methods for each: read/write• Three different versions of GIOP Three different versions of GIOP Three different versions of GIOP Three different versions of GIOP

(and counting)(and counting)(and counting)(and counting)• Client/server applications only Client/server applications only Client/server applications only Client/server applications only

require a few of 48 methodsrequire a few of 48 methodsrequire a few of 48 methodsrequire a few of 48 methods•Problem:Problem:Problem:Problem:• MonolithicMonolithicMonolithicMonolithic ORBsORBsORBsORBs must have code to handle all casesmust have code to handle all casesmust have code to handle all casesmust have code to handle all cases

•Solution:Solution:Solution:Solution:• Apply Virtual Component pattern to factor out each methodApply Virtual Component pattern to factor out each methodApply Virtual Component pattern to factor out each methodApply Virtual Component pattern to factor out each method• Only two methods are required for typical server, two others Only two methods are required for typical server, two others Only two methods are required for typical server, two others Only two methods are required for typical server, two others

for typical client for typical client for typical client for typical client



ZEN’s Pluggable Object Adapters

•Solution: Solution: Solution: Solution: • Apply Virtual Component pattern to allowApply Virtual Component pattern to allowApply Virtual Component pattern to allowApply Virtual Component pattern to allow

pluggablepluggablepluggablepluggable POA (coarse grained control) POA (coarse grained control) POA (coarse grained control) POA (coarse grained control) done in TAO done in TAO done in TAO done in TAO

STDSTDSTDSTDPOAPOAPOAPOA

MINMINMINMINPOAPOAPOAPOA RTRTRTRT

POAPOAPOAPOA

•Context:Context:Context:Context:•Object Adapter maps client requests to server servantsObject Adapter maps client requests to server servantsObject Adapter maps client requests to server servantsObject Adapter maps client requests to server servants•Three types ofThree types ofThree types ofThree types of POAsPOAsPOAsPOAs::::•Standard POA: for nonStandard POA: for nonStandard POA: for nonStandard POA: for non----realrealrealreal----time applicationstime applicationstime applicationstime applications•Minimum POA: attempt to reduce memory footprintMinimum POA: attempt to reduce memory footprintMinimum POA: attempt to reduce memory footprintMinimum POA: attempt to reduce memory footprint•RealRealRealReal----time POA: ensures predictability required for realtime POA: ensures predictability required for realtime POA: ensures predictability required for realtime POA: ensures predictability required for real----time systemstime systemstime systemstime systems

•Problem:Problem:Problem:Problem:•Only servers or peers need an Only servers or peers need an Only servers or peers need an Only servers or peers need an Object Adapter, clients do not Object Adapter, clients do not Object Adapter, clients do not Object Adapter, clients do not need oneneed oneneed oneneed one•Even servers only need a few of Even servers only need a few of Even servers only need a few of Even servers only need a few of the features of a POAthe features of a POAthe features of a POAthe features of a POA



Fine Grain Architecture (cont.)•Behavior of the POA customized Behavior of the POA customized Behavior of the POA customized Behavior of the POA customized using Policies using Policies using Policies using Policies

•StrategizedStrategizedStrategizedStrategized POA PoliciesPOA PoliciesPOA PoliciesPOA Policies•Primary Components: •Do not depend on other POA components.•Thread, Lifespan, Activation •Secondary Components•Depend on Primary/Secondary Components• Id Assignment, Id Uniqueness, Servant Retention, Request Processing.

POACORE

POLICYFACTORY

ID

UNIQUENESS

SERVANT

RETENTION

LIFESPAN

REQUEST

PROCESSING



•Components strategized along usage scenarios

• Request Processing Policy strategized along usage scenarios• AOM Only Strategy•Default Servant Strategy•Servant Manager• Servant LocatorServant LocatorServant LocatorServant Locator• Servant ActivatorServant ActivatorServant ActivatorServant Activator

•Design enables addition of new Vendor specific options.•E.g use Data Base Manager option would require change only to the Base Strategy.

• Foot Print reduction•Only one component is associated with the POA based on the policies.



Traditional Architecture

SERVANT

POA AThread Strategy

Servant RetentionStrategy

Id UniquenessStrategy

Activation Strategy

Id AssignmentStrategyRequest

ProcessingStrategy

Lifespan Strategy

Retain Strategy

Active Object MapObject Id

Object Id

Object Id

SERVANT

SERVANT

Fine Grain Architecture

STDSTDSTDSTDPOAPOAPOAPOA

MINMINMINMINPOAPOAPOAPOA RTRTRTRT

POAPOAPOAPOACoarse Grain Architecture



ZEN’s Pluggable Transport Protocols•Context:•GIOP can run on many protocol

transports• E.g, TCP/IP, shared memory, SSL•20 to 30 classes may be required to

support all common transport protocols

•Problem:•Monolithic implementation may use if/switch statements•Or may choose only one transport (e.g., TCP/IP)•Solution:•Apply Virtual Component pattern, only load classes required•Both client and server need Transport and Address class•Server also needs Acceptor and Reactor classes•Client also needs Connector class•Only required classes are loaded specific to the transport being used



ZEN’s Pluggable ANY Handlers•Context:•ANY data type is useful for

generic services because it may hold any data type

•Problem:•Monolithic implementations must include methods to read and write each primitive data type, user-defined types, arrays, and sequences

•Solution:•Apply Virtual Component pattern to factor out all this code•It is loaded upon first use, only methods dealing with the specific type used are loaded



ZEN’s Pluggable IOR Parsers•Context:• IORs are CORBA’s powerful object pointers•May point to servant across the net in another process•CORBA supports various formats for IORs•Problem:•Monolithic implementation must include code to recognize format and parse, then handle each IOR format

•Solution:•Apply the Virtual Component pattern to factor out each IOR format handler•Each handler is loaded only when the particular format is encountered



ZEN’s Pluggable Object Resolvers•Context:•ORB::resolve_initial_references (string name) allows applications to get IOR for ORB objects•Examples include RootPOA, NameService,EventChannel

•Problem:•Monolithic ORB may use if statements to match name string or table lookup, all code for handling is resident

•Solution:•Apply the Virtual Component pattern to factor out handling of each string into a class•Class name is based on the object string, e.g., rootPOAResolver•Only load classes for names used



Other Pluggable ORB Services•Message Buffer Allocators•Allows different algorithms

to be plugged-in•CDR stream reader/writers•Vary with the endian of the

local machine•Little endian has one set of readers/writers•Big endian has a different set



Current Status•Functional Java ORB with POA, GIOP, IDL compiler•Interoperable with TAO the C++ ORB•Missing: COS Services, DII/DSI, etc.•Focusing on:•Factoring out more functionality from the ORB core to reduce footprint•Completing Real-time support utilizing RT Java features•Using Aspects for static custom configuration: Portable Interceptors



Performance Measurements•Testbed (comparing ZEN to JacORB)•On dual-CPU 1.7GHz Xenon (512Mb RAM)•Debian Linux 2.4.1, javac compiler, JDK 1.4 JVM•Two-Way call passing long, returning long•100,000 calls, using loopback (on same machine)•ZEN: Latest Version•JacORB: Version 1.4

(Latest version)

•Roundtrip Throughput:•ZEN: 1,295 calls/second•JacORB: 1,436 calls/second(TAO: ~8000 calls/second)

IDL Type long

0

200

400

600

800

1000

1200

1400

1600

100 500 1000 5000 10000

no of requests

calls

/sec

Jac ORBZEN



Memory Footprint Measurements•Memory Sizes (in KB)

ZEN JacORB TAO server: 2,539 3,186 2075client: 2,527 2,985 1567

•But Default JVM size: 2194KB!•Compare to:• libTAO size: 1259KB• libTAOPortable_Server size: 510KB

• (TAO Test compiled using gcc-2.91 and static libraries.)

•JVM Implementations of size 1.5MB currently available•Will make ZEN and TAO code size comparable

0

500

1000

1500

2000

2500

3000

3500

Server Client

Memory Footprint (in Kilobyes)

ZENJacORB TAO



Future Work•Research Issues•Utilizing RT Java features within the ORB for RT CORBA•Evaluation of performance of various pluggable ORB core services•Using aspects with reflection to custom generationORBs•Real-Time Dynamic Scheduling•Reflection: Dynamic reconfiguration, power management, etc.



Concluding Remarks• ZEN is a good start on a research platform for real-time,

embedded systems middleware developed using Java• Pluggable architecture is comparable in speed to monolithic

implementation, yet with smaller footprint• RT-CORBA: Dynamic scheduling is not yet standardized• RT-Java: No implementation available yet for testing• In the works: Distributed-RT Java (JSR)



URLs for Further Reference• ZEN web page:• http://www.zen.uci.edu

• JacORB web page:• http://www.jacorb.org

• RT-Java JSR:• 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 RT-Java JSR:• http://java.sun.com/aboutJava/communityprocess/jsr/

jsr_050_drt.html• AspectJ web page:• http://www.aspectJ.org

• JVM for embedded systems: (TAO Group)• http://tao-group.com/2/tao/index.html

Date post:	13-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

The Performance of ZEN: A Real Time CORBA ORB using Real ... · Klefstad, et al. Real Time CORBA...

Documents