[Fwd: JVM -instrumentanting the JDK classes]

[Paul Hohensee]

It would be more work than what's proposed, but if it were me I'd
consider adding a field to the object header (in the vm: see oop.hpp)
and access it from Java via an intrinsic like array length(). Use some
weird accessor name that isn't likely to be used for anything else.

Paul

Keith McGuigan wrote:
>
> 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!
>