harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject [drlvm][jvmti] RedefineClasses.
Date Tue, 01 May 2007 16:56:31 GMT
Hello, community (and esp. JIT gurus).

I've started thinking about and sketching RedefineClasses functionality for
DRLVM JVMTI implementation.

There still exist several questions I haven't found answers for.

Questions number one.

JVMTI specification for RedefineClasses allows to replace class' constant
pool with new one.
But methods of old "version" of a class, being executed at the moment of
redefinition are allowed to complete normally.
The question of which constant pool they should address during their
execution can be sorted out in two ways:
1) Reference to constant pool should be stored inside the method and all
symbolic references from instructions should be directed into the linked
constant pool. This provides some complexities in terms of interface to
execution engines. Method identification should be passed along with class
identification and constant pool entry index.
2) (This what I started to play with) During redefinition old and new
constant pools should be merged, creating "common" constant pool, and then
bytecodes should be remapped to point to this merged version. The one of the
problems here is that "merged" constant pool size can exceed 16-bits
allocated for constant pool indexes in bytecode instructions. This could be
solved by parsing bytecodes on VM side and then provide per-instruction
access for interested parties. Bytecode parsing is required anyway to
compare old and "redefined" method bytecodes to determine if they are
equivalent or not. This also would allow to merge all bytecode parsing code
in one place. But this approach has significant disadvantage of influencing
plenty of the code (verifier, interpreter, and two JITs).

Question number two...

...which is related to the first one.
There is a way to find out if the method is being executed at the moment.
All stacks of all theads should be inspected to find out what methods they
are executing and compare these methods to the method being redefined. The
way is the long one. Could someone think of something more elegant than this

With the best regards,
Pavel Pervov,
Intel Enterprise Solutions Software Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message