Fast class reloading

David Holmes David.Holmes at
Wed Jun 2 18:49:09 PDT 2010


I think you are assuming the parts of the VM you need to modify are Java 
classes - hence your idea is to first modify those classes, within the 
existing limitations, to allow you to remove the limitations. But the VM 
is C/C++ code not Java - you can't use an agent to modify the VM.


David Holmes said the following on 06/03/10 11:43:
> Igor,
> An agent can't "modify the VM". The agent can only do what the VM lets 
> it - via the JVM TI API defined for agents.
> David
> Igor Adam Klimer said the following on 06/03/10 11:40:
>> Yes, I understand the limitations of an agent. However, it should be 
>> possible to modify the VM (within the limitations imposed on the 
>> agents) *using* the agent. So in summary: I want to use a "vanilla" 
>> agent to modify the VM (that's the part where I'm afraid if an agent 
>> is not too limited - because, like you said, we can basically only 
>> change method bodies) so that the limitations no longer apply. This 
>> would mean that users could use a standard VM that would get 
>> "augmented" by the (then still unmodified) agent, so that reloading of 
>> classes would be possible.
>> If my idea still doesn't make sense to you, then it's either really 
>> stupid or really unorthodox ;)
>> Regards,
>> Igor Klimer
>> ----- oryginalna wiadomość -----
>> od: David Holmes <David.Holmes at>
>> data: czwartek, czerwiec 3, 2010 3:22
>> temat: Re: Fast class reloading
>> do: Igor Adam Klimer <150043 at>
>> kopia do: hotspot-runtime-dev at
>>> Igor Adam Klimer said the following on 06/02/10 23:16:
>>>>> An agent can only use functionality exposed by the VM and 
>>> there is
>>>>> no VM functionality in existence to do what you want. This has to
>>>>> be supported by the VM (after which it could be exposed to agents).
>>>> Yes, but from what I understood an agent can also modify the VM's
>>>> classes - so the idea was to exploit that (eh, "exploit" has a bad
>>>> sound to it ;)) and modify the VM so that it does include the
>>>> functionality we need. Does this idea seem reasonable to you? Of
>>>> course, it would be hard to maintain such "patches", but it would
>>>> take the burden of installing a custom VM from the users.
>>> That's exactly what I said above. First you have to add the 
>>> functionality you want to the JVM, then you need to make that 
>>> functionality available to the agent. Your users will still need your 
>>> customized VM.
>>> At present class JVMTI class redefinition is limited in ways that 
>>> don't meet your list of requirements:
>>> "The redefinition may change method bodies, the constant pool and 
>>> attributes. The redefinition must not add, remove or rename fields or 
>>> methods, change the signatures of methods, change modifiers, or 
>>> change inheritance."
>>> David

More information about the hotspot-runtime-dev mailing list