copyright (c) 2005 [email protected] july 25-29, 200519th ecoop 2005, glasgow, uk 1 loosely-separated...

July 25-29, 2005 19th ECOOP 2005, Glasgow, UK 1Copyright (C) 2005 [email protected]

Loosely-separated “Sister” Namespaces in Java

Yoshiki Sato (Tokyo Tech., JapanCurrently, Mitsubishi Research Institute, Inc., Japan)

Shigeru Chiba (Tokyo Tech., Japan)

19th ECOOP 2005, Glasgow, UK July 25-29, 2005Copyright (C) 2005 [email protected]. 2

About This Talk…

Ironically calledthe version

barrier


barrier

The strict separation of Java namespacesScenario : inter-J2EE component communicationOrdinary 4 agonizing techniques

I will introduceSister namespace: A more sisterly namespace than ordinary standoffish one


The namespace design in Java is useful

Naming conflicts betweencomponents can be avoideddue to the separated namespace

Dynamically and individuallyupdated without restartingby recreating a new loader

component frameworkcomponent framework

components

loader

namespace

JVM, OS,…JVM, OS,…

deploy(install)

undeploy

Each class loader creates a unique namespaceThis design well fits with a component system

Each loader loads a component into its own namespaceA component-based application can be developed and then deployed per component

Tomcat, JBoss,Eclipse

Applets, Servlets, EJBs, Plug-ins

19th ECOOP 2005, Glasgow, UK July 25-29, 2005Copyright (C) 2005 [email protected] 4

Problem of the current design:the version barrier

The difficulty to communicate across namespacesDifferent versions are different types!!

Of course, they have no subtype relation

An object of one version can not be cast to the other version

J2EE platformJ2EE platform

c = session.getCache();Object o = cache.get(session);

Cart cart = (Cart) o;

OrderServletWAR1 WAR2

e.g.) online shopping

No cache!?

Cart Cart

EstimateServletc = session.getCache();

Cart cart = new Cart();cart.put(item);c.put(session, cart); cart throws ClassCastException


Why did the Java designers select this design ?

It guards JVMs against type-spoofing without runtime type checksType-spoofing may crash JVMs by accessing a non-existing member(Sun JDK1.1 had the similar security problem reported by Saraswat)

If the JVM does type checks with resolving members on every instance access, the version barrier is not needed

It is unacceptable for JavaBecause the Java design prefers high-performance

Cart c = (Cart) obj;

c.put(); c.remove(1); c.clear();


c.put(); c.remove(1); c.clear();

loader1 loader2

put()remove(int)clear()

put()remove(int)

Cart, WAR1 Cart, WAR2obj

Segmentation faultc.clear()

invoke m[resolve(“put”, “()V”)];invoke m[resolve(“remove”, “(I)V”)];invoke m[resolve(“clear”, “()V”)];

invoke m[resolve(“put”, “()V”)];invoke m[resolve(“remove”, “(I)V”)];invoke m[resolve(“clear”, “()V”)];

X clear()


Ordinary techniques for inter-component communications

WAR1 WAR2EAR

Cartdelegating

namespace

WAR1&2

Cart

Tightly-coupled components decrease the availability and the maintainability

WAR1

CartWAR2

Cartdelegating

I. Packaging into the same archiveCall-by-Reference using the Local Interface requires it

II. Delegating to the common parentThe classes are visible among all child loaders

III. Delegating to the receiverThe JBoss UCL is based on it

IV. Inter-process communicationCall-by-Value using the Serialization

WAR1

Cart

WAR2

Cart

Remote

call

Uniquely separated namespaces are combinedPerformance overheads caused by a remote call


Our motivation and Goal

The namespace designin Java is not so bad

But the version barrieris so bad…hmm

Our goal is relaxing the version barrierbetween compatible versions of a classOur challenges:

Reducing runtime type checks for type-safe instance accessesAvoiding tightly-coupled namespacesKeeping lazy class loading


Sister namespace

Sister namespaces can relax the version barrierbetween sibling namespacesexplicitly specified against class loaders by the programmers

Version barriers between the version compatible classes are automatically and silently relaxed

Incompatible classes can be also loaded into each own namespace if they are harmless to the other namespacesister1 sister2

parent

incompatible, but loaded

compatible, thus relaxed We aren’t nagging,

loosely-separated

by using protected ClassLoader(ClassLoader parent, ClassLoader sister)


Sister namespace

A sister relation is established only among the namespaces that have no parent-child relation

Our requirements are fulfilled Runtime type checks are reducedLazy class loading are keptTightly-coupled namespaces are avoided

sister1 sister2

parent

incompatible, but loaded

compatible, thus relaxed We aren’t nagging,

loosely-separated

All classes in sister namespaces satisfy bridge-

safety


Version compatibility

Version compatible changesThe differences that an instance can be securely accessed through another version of that class

Any static members (static methods, static fields,constructors, initializers ）

A body of instance members (instance methods)

Derived from the study of Java binary compatibilityIf the binary compatibility satisfied, a class can link preexisting binaries without recompiling.If the version compatibility satisfied, an instance rather than a class can work with the binary of another version

cart

Cart,WAR1Cart,WAR1 Cart,WAR2

cart


Only few instructions do runtime checks because of bridge-safety

The bridge-safety property is satisfied [Saraswat’97]An instance from the sister namespace must be

upcast to their supertype loaded by their common parent loader downcast to a variable of the corresponding class type

The version checker has only to work with the type checker All instances cross the version barrier through checkcast

The version checker implies no performance penalties unless instances are passed across the version barrier

WAR1

Cart

WAR2

Cart

System class loader

Object

cache.put(cart) (Cart)cache.get(…)

checkcast

if LHS is a subtype of RHS trueelseif LHS is not a subtype of RHS falseend

if LHS is a sister type of RHS && LHS is version compatible with RHS

Version check algorithm

Regular type-check algorithm


Sister loader constraints can delay version checks

The version checker requires eager class loadingUntrusted instances may relay an incompatible instance

As a field, a method return, and a method argument value All relayed classes must be eagerly loaded and then verified for winnin

g the trust of the relaying instance

The constraints for the non-loaded classesThe version checker recursively verifies version compatibilityWhile recording the constraints for the non-loaded classes

Sister namespacesSister1

LoadedLoadedNon-loadedNon-loaded

Sister2

class CartCart { ProductMapProductMap map = null; ProductListProductList getProducts() {…} void putProduct(ProductProduct product) {…}}




cart


Sister loader constraints can delay version checks

The version checker verifies<Cart, SN1> can trust <Cart, SN2>

<Cart, SN1> is version compatible with <Cart, SN2> <ProductMap, SN1> can trust <ProductMap, SN2> <ProductList, SN1> can trust <ProductList, SN2> <Product, SN1> can trust <Product, SN2>

Casting <Cart, SN1> to <Cart, SN2> succeedsIf both loaded, the sister loaders verify

<ProductMap, SN1> can trust <ProductMap, SN2> <ProductList, SN1> can trust <ProductList, SN2>

Sister loaderconstraints

Newconstraints

Sister namespacesSister1


LoadedLoadedNon-loadedNon-loaded

Sister2


cart


hold fields and function pointers to a corresponding method body

Schema compatible loading

The instances may have schema inconsistenciesThe layout of TIBs(type information block) may not be identical

The TIBs of both versions are updated to be compliant with each other when both versions are loaded

The corresponding members share the same index into the TIBAll members can be correctly accessed without any checks

Cart, WAR1put()remove(int)clear()

Cart, WAR2remove(int)clear()put()

clearremove

put

putclear

remove

tib[2]

tib[0]tib[1]

clearremove

put

clear

putremovecompatible


Implementation on the IBM Jikes RVM

The extensions to the JRVMJava API

GNU Classpath libraries

Sister loader1. Examines version compatibility2. Performs schema compatible loading3. Verifying sister loader constraints

Version checker1. Version checks2. Verifying sister loader constraints

Class and object(TIB) representations An identifier of a sister relation Sister’s superclasses and interfaces

TIB

fieldTIB

status

Object

superinterfaces

Class

vmethod

type

sister’s super sister’s interface

type ID

static membersister

[Java.lang.ClassLoader]protected ClassLoader(ClassLoader parent, ClassLoader sister)


Related work

Dynamic software updates and evolution

Most of the previous researches regarded the version barrier as a temporal boundary between old and new components

HotSwap Sun JDK1.4 JPDA (JDK1.5 java.lang.instrument)Dynamic Java Classes [Malabarba00ECOOP]Dyamic Classes [Hjalmtysson98USENIX]

The spatial version barrier among multiple components, where an older version remains after a new version is loaded

Reclassifying object [Drossopoulou01ECOOP]Wide classes [Serrano99ECOOP]Type-based hotswap [Duggan01ICFP]Dynamic typing language (CLOS, Self, Smalltalk)

Explicit type changing semantics


Concluding remarks

The design and implementation of loosely-separated “sister” namespaces in Java

Melts the Java’s strong types only at the joint of componentsWe are now formalizing and proving the type soundnessIt could adopt to the dynamic AOP system, which is for not DI + AOP but DI x AOP

Our experimental results showThe baseline overhead was negligible

-5~5% running the SpecJVM98 on the modified JRVM

The version check overheads are not so severe 1st : 1,000~4,000 % 2nd : 160% using the results of 1st


The End

Thank you for your attentions !!

If any questions, please ask me “clearly” and “slowly”


Compatibility with JIT compilers

Canceling JIT compilationsOptimizing JITs transform a virtual method to a static oneSuch a devirtualized and maybe inlined method call does not correctly refer to a method declared in a sister version

Recent JITs cancel devirtualization efficiently by rewriting or replacing an inlined code when a new sister loaded


Inlined_put();Inlined_remove(1);Inlined_clear();


Inlined_put();Inlined_remove(1);Inlined_clear();



Cart, WAR1 Cart, WAR2obj

Devirtualized and maybe inlined


Eager notifications of version incompatibility

The incompatibility errors are eagerly thrownVersion checkingOr, class loading

The linker is no use for the sister classes that have already linked with a call site

Unlike the binary compatibility checks in JavaLike the loader constraint scheme

Sister namespaces

class Cart { ProductMap map = null; ProductList getProducts() {…} void putProduct(Product product) {…}}

class Cart { ProductMap map = null; ProductList getProducts() {…} void putProduct(Product product) {…}}

cartLoaded Version Incompatible


memoQ) Why did you use “sister” as the name?

A) Using the notion of “sister”, we can imagine a more soft and friendly sibling relation than brother.

Q) How do you deal with the co-variant and contra-variant problems?

A) There is no sub-typing relation between sister versions of a class type, that is, one is neither the other’s supertype nor subtype. So the co-variant and contra-variant problems are not need to be regarded.

Q) What is the difference from the loader constraint scheme?

A) The loader constraint scheme rather strenghthens the version barrier, while our work relax the version barrier

Q) OODB?A) In the object database community, several schema evolution techniques such as schema or class versioning have been studied. Using the object databases is a workable alternative.Q) Why not the performance overheads are severe?A) We think the overheads are not so severe compared to the inter-component communication. Just for a reference, we measured the costs of the inter-component communication. We transported 400KB files over network and it spent 3 million times larger than checkcastQ) Why not a sister relation is allowed between a parent-child? The bridge-safety property is not satisfied for all the classes. What could be wrong?

A) Since all classes included in the parent are visible for the child class loaders, the instances can be passed without the checkcast operation, by using just an assignment operation.


pronunciation

SeparatelyViolateInconsistenciesIncompatibilityExamineIdentificationDetermineAlternativeSimultaneously

SpatialCause


About This Talk…


barrier


barrier

The strict separation of Java namespacesScenario : inter-J2EE component communication

Our goalRelaxing the version barrier

while still allowing type-safe instance accesses with negligible performance penalties in regular execution

Melting the strong types only at the joint of namespaces (components)

I will introduceSister namespace: A more sisterly namespace than ordinary standoffish one


Ordinary techniques for inter-component communications

I. Packaging into the same archiveUsing the Local Interface introduced by EJB 2.0 requires itIt enables using Call-by-Reference on the local communication

II. Delegating to the common parentThe classes loaded by a loader areavailable for that all child loadersThe WAR components can share the same version loaded for the EAR

Tightly-coupled components decrease the availability and the maintainability

WAR1 WAR2EAR

Cartdelegating

namespace

WAR1&2

Cart


Ordinary techniques for inter-component communicationsIII. Delegating to the receiver (JBoss UCL )

A collection of UCLs acts as a single class loader, which places into a single namespace all the classes to be loadedAll classes are loaded into the sharedrepository and managed by it

Uniquely separated namespaces are combined

IV. Inter-process communication (Call-by-Value)It uses the Serialization API to exchange objects between different components through a byte streamTypical J2EE platforms adopt this approach as the last resort

Performance overheads caused by a remote call

WAR1

Cart

WAR2

Cart

Remote

call

WAR1

CartWAR2

Cartdelegating


Sister namespace can relax the version barrier

We aren’t nagging, loosely-separated

The design of sister namespacesNamespaces except the parent and child can be sistersThe version barrier between the version compatible classes are silently and automatically relaxed in the sister namespace

Runtime type checks for type-safe instance accesses are reducedEach sister needn’t mind the other’s loading of incompatible but harmless classes

All classes in the sister namespace satisfy bridge-safety

sister1 sister2parent

incompatible, but loadable

compatible, so exchangeable


Sister namespace

Version barriers between the version compatible classes in sister namespaces are automatically relaxed

Explicitly specified against class loadersEstablished among namespaces that have no parent-child relation

Our requirements are fulfilled Runtime type checks are reducedLazy class loading are keptIncompatible classes are loaded into each namespace if harmless to the other namespace

All classes in sister namespaces satisfy bridge-

safety

sister1 sister2

parentincompatible, but loaded

compatible, thus relaxed

We aren’t nagging, loosely-separated


Sister namespace

Sister namespaces can relax the version barrier between the sibling namespaces pairing in advance

Only secure instances can be assigned to the variable of the sister version of that class typeThe programmers explicitly specified sister relations:

protected ClassLoader(ClassLoader parent, ClassLoader sister)

Cart,WAR1Cart,WAR1

WARLoader(EAR, WAR1)

Cart,WAR2cart

1. Version compatibility

3. Sister loader constraints4. Schema compatible loading2. Version checker

EARLoader()

WARLoader(EAR)


Version checker

The version checker, an extension to the built-in type checker, is what relaxes the version barrier

Checks the sister relation and the version compatibilityOnly several instructions require dynamic type checking(instanceof, checkcast, invokeinterface, athrow)Other instructions are statically typed (invokevirtual, getfield, etc.)

This implies no performance penalties as long as the version checks are not performed

if LHS is a subtype of RHS trueelseif LHS is not a subtype of RHS falseend

if LHS is a sister type of RHS && LHS is version compatible with RHS trueelse falseend

Regulartype check algorithm

Version check algorithm


Is the version checker enough for detecting an incompatible class?

YES, because of the design of sister namespacesNo parent-child relationship between any sister namespaceThe common parent namespace always exists among sisters (The top-level namespace is created by the bootstrap loader)

Bridge-safety property is satisfied [saraswat’97]An instance from the sister namespace must be

upcast to their supertype loaded by their common parent loader downcast to a variable of the corresponding class type

WAR1

Cart

WAR2

Cart

EAR bootstrapbootstrap

checkcast(version check)

Cachecache.put(cart);

(Cart)cache.get(…);


Concluding remarks

Sister namespaceThe design and implementation of loosely-separated Java namespacesMelts the strong types only at the joint of componentsIt could adopt to the dynamic AOP system, which is for not DI + AOP but DI x AOP

Our experimental results showThe baseline overhead was negligible

-5~5% running the SpecJVM98 on the modified JRVM

Loading costs depend on the number of declared members 13~67% overheads for loading 72～ 1,548 classes

The version check overheads are not so severe 1st : 1,000~4,000 % 2nd : 160% using the results of 1st

JDOM, Crimson, jaxen, dom4j, SAXON,XT, XercesJ1, 2, XalanJ

copyright (c) 2005 [email protected] july 25-29, 200519th ecoop 2005, glasgow, uk 1 loosely-separated...

Documents