Fast class reloading

[David Holmes]

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 oracle.com>
> data: czwartek, czerwiec 3, 2010 3:22
> temat: Re: Fast class reloading
> do: Igor Adam Klimer <150043 at student.pwr.wroc.pl>
> kopia do: hotspot-runtime-dev at openjdk.java.net
> 
>> 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