Fast class reloading
David.Holmes at oracle.com
Wed Jun 2 18:43:03 PDT 2010
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.
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 ;)
> 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."
More information about the hotspot-runtime-dev