Transcript Remote Pointcut - A Language Construct for Distributed AOP

Negligent Class Loaders for Software
Evolution
Yoshiki Sato, Shigeru Chiba
(Tokyo Institute of Technology and
Japan Science and Technology Corp)
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
1
Java class loaders are great!!
 How do you implement dynamic AOP or reflection ?
 It should be easy if using class loaders
loader = new CustomClassLoader(…);
byte[] modifiedclass = translator.compose(“Product”, “Logging”);
Class c = loader.load(modifiedClass);
Product p = (Product) c.newInstance();
1.
Creating a custom class loader
2. Putting the logging functionality on the Product class using a translator
3. Loading the modified version of the Product class
Finally, we can get an instance of the new Product class
Common mistake!!!
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
2
Java class loaders are useless!!
 This is wrong implementation
 Two Product classes are loaded as different classes
 The system class loader loads one class file
 The CustomClassLoader loads another
They have the same name but are not compatible
loader = new CustomClassLoader(…);
byte[] modifiedclass = translator.compose(“Product”, “Logging”);
Class c = loader.load(modifiedClass);
Product p = (Product) c.newInstance(); ClassCastException
 Some experts may define the Product class as an interface
 But it is troublesome, slow and inflexible
We want to enable such a cast operation
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
3
The version barrier forbids this cast
 The version barrier is an obstacle to software evolution
 as well as the restricted ability for reloading a class
 Different versions of a class is not compatible in Java
 Those are separately loaded by distinct class loaders
 An instance can not be assigned to a variable of another
version of a class
loader1
product
old
product
Jun 14, 2004
new
incompatible
RAM-SE'04 Workshop, Oslo,
Norway
Version barrier
(i.e. namespace)
loader2
4
Why did the Java designer select this ?
 The version barrier guards JVMs against typespoofing without runtime type checks

Type-spoofing may crash JVMs by accessing an illegal memory
space (Sun JDK1.1 had the similar problem reported by Saraswat)
loader1(http://aaa/B.jar)
Product
getName()
getPrice()
loader2(http://xxx/Y.jar)
Product
Product p = (Product) c.newInstance();
p getName()
int price = p.getPrice();
p.getPrice()
Segmentation fault
 If the JVM does type checks on every instance access, the version
barrier is not needed
 It is unacceptable for Java
 Because the Java design prefers high-performance
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
5
Proposal:
Negligent Class Loader (NCL)
 The NCL can relax the version barrier among
the sibling loaders pairing in advance
1. Allows changing the class schema securely
2. Needs additional runtime checks but minimum
3. Negligent in updating instances
Parent class loader
Elder
NCL
An instance can be assigned
to a variable of the version of
the pairing loader
Jun 14, 2004
product
RAM-SE'04 Workshop, Oslo,
Norway
product
Younger NCL
6
Proposal:
Negligent Class Loader (NCL)
 The NCL can relax the version barrier among
the sibling loaders pairing in advance
1. Allows changing the class schema securely
 Adding, deleting and changing a method
 Not allowed weakening the access restriction
 Not allowed changing the class hierarchy
2. Needs additional runtime checks but minimum
3. Negligent in updating instances
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
7
Proposal:
Negligent Class Loader (NCL)
 The NCL can relax the version barrier among
the sibling loaders paired in advance
1. Allows changing the class schema securely
2. Needs additional runtime checks but minimum
 Compliant schema updates at class liking time
 The additional type checks for the NCL are needed only
when an explicit cast operator is executed
3. Negligent in updating instances
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
8
Proposal:
Negligent Class Loader (NCL)
 The NCL can relax the version barrier among
the sibling loaders paired in advance
1. Allows changing the class schema securely
2. Needs additional runtime checks but minimum
3. Negligent in updating instances
 The NCL doesn’t change the class versions of existing
instances
 Multiple class versions of instances coexist in a single
namespace without using an interface
 An instance keeps the initial version of the class as long
as it works properly
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
9
Changing the class schema securely
(TIB: type information block)
 The TIBs of both versions are updated to be compliant
with each other when a new version is loaded
 The corresponding methods share the same index into the TIB
 A TIB entry of a missing method is filled up with a SHF
(secure handling function) e.g. RuntimeException
caller
code
Old
1 a()
2 b()
object
Jun 14, 2004
a
b
TIB
Compliant schema
updates 1 a() Old
2
A new version
is loaded
b()
a
b
3
1
c() New
a()
a
SHF
c
SHF
RAM-SE'04 Workshop, Oslo,
10
compatible
Norway
Additional runtime checks
 Only runtime checks by checkcast is extended
 Different versions of the class are compatible between the
pairing NCLs (relaxed version barrier)
 Other instructions such as invokevirtual, getfield and astore
are not extended because of the bridge-safe property
An instance from the pairing NCL must be
 upcast to their supertype loaded by their common parent loader
 downcast to a variable of the corresponding type
Object obj =
(Product) obj;
Product p = checkcast
Jun 14, 2004
Elder NCL
RAM-SE'04 Workshop, Oslo,
Norway
Parent CL
c.newInstance();
Younger NCL
11
Two approaches for runtime evolution
 Dealing with instances of multiple versions of a class
 Negligent Class Loaders
 Runtime instrumentation of running programs




Sun JDK1.4 JPDA (JDK1.5 java.lang.instrument)
Dynamic Java Classes [Malabarba00ECOOP]
PROSE2 [Popovicci03ECOOP]
Steamloom [Bockisch04AOSD]
Most of
previous
work
 Recompiling a new version of a class definition
 And invalidating an old version of a class definition
It implies performance penalties and spoils runtime
optimizations by a JIT compiler
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
12
Conclusions
 We are currently implementing our approach on IBM
Jikes RVM 2.3.2
 Future directions



Evaluating performance overheads
Handling fields and arrays of multi-versioned class
The proof of type safety and Java security architecture
Extensibility
Jun 14, 2004
Our goal
Dynamic typing
CLOS,Smalltalk,Ruby
-> flexible but slow
Static typing
Java,C#,C++
Runtime
Workshop, Oslo,
-> fastRAM-SE'04
but inflexible
Norway
overhead
13
Difficult issues
 The existing fields must not be decreased in the new
version and only a private field can be added into the
new version
 Because an entry of a field table is generally not a function
but just an element of arrays
 The SHF can not be invoked at a field access by being
inserted into a field table
 Inlining methods must be invalidated
 Because it is not executed by referring the function tables
with the specified method index
 An instance can not be handled keeping its own version
Jun 14, 2004
RAM-SE'04 Workshop, Oslo,
Norway
14