[Fwd: JVM -instrumentanting the JDK classes]

[Keith McGuigan]

The JVM has some hardcoded expectations at to where to find fields in 
some of the critical classes.  I don't know that we have these 
assumptions listed anywhere (other than in the Hotspot source code: see 
JavaClasses::compute_hard_coded_offsets()).

If the addition of a field to a key class changes the location of a 
JVM-expected field, I would anticipate problems.  Because fields are 
(usually) grouped and put in runtime order by type, adding a new field 
at the end of a class in the source (or bytecode) probably won't 
guarantee is that it goes at the end at runtime and doesn't disturb the 
layout of known fields.

It looks like there is some logic in the class file parser (see the 
allocation_style code) that attempts to change allocation style for 
these classes, but I don't think it expects new fields.

--
- Keith

Paul Hohensee wrote:
> I've cc'ed hotspot-dev at openjdk.java.net, which is the place to ask.
> 
> Paul
> 
> Christine Flood wrote:
>>
>> I suppose he could use a tool like ASM to change the class 
>> dynamically, but I expect he will still get into trouble.
>>
>> Can anyone tell me definitively that this is a bad idea?
>>
>> I tried sending this to hs-chat, but apparently it is defunct.  Is 
>> there a better place to ask this question?
>>
>>
>> Christine
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> JVM -instrumentanting the JDK classes
>> From:
>> Mario Mendez-Lojo <marioml at ices.utexas.edu>
>> Date:
>> Mon, 17 Nov 2008 00:16:10 -0600
>> To:
>> Christine Flood <Christine.Flood at sun.com>
>>
>> To:
>> Christine Flood <Christine.Flood at sun.com>
>>
>>
>> Hi Christine,
>>
>> I'm Mario, one of Keshav's students at UT Austin. I have a question 
>> regarding some assumptions about the JVM & library classes.
>>
>> In order for our system to work, we need to change the code of the 
>> Java libraries - all of them. The changes imply adding a field 
>> (potentially two), and adding some code to the beginning and end of 
>> every method.
>>
>> Using Soot, I got to add the field and methods to the classes. 
>> However, there are exactly two classes (Object and String) that, when 
>> added a field, make the JVM crash on startup. I'm starting the Sun JVM 
>> with the parameter Xbootclasspath  pointing to the instrumented 
>> libraries.
>>
>> The question is: how safe our approach is? Even when the JVM is not 
>> crashing at startup, can I expect failures later on during runtime? 
>> Can you think about an alternative way of changing the behavior of the 
>> JDK classes in a less intrusive way?
>>
>> Thank you Christine!