harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Timoshenko <george.timoshe...@gmail.com>
Subject Re: [drlvm][jvmti] RedefineClasses.
Date Wed, 02 May 2007 06:05:17 GMT
Hello Pavel, Egor, community.

I understand what Egor has wrote.
But the idea of constant pool usage in a method is not clear for me.

Managed code does not work with constant pool at runtime, right?
All cp indexes were processed when the method was compiled.

If we are talking about objects (and their fields) creating the merged 
pool of fields should not be affected by indexes and their 16-bit limit.
The patching is needed here (Egor wrote about it) to substitute old 
links with new "redefined" fields/methods addresses.

Pavel, could you please clarify how the merged constant pool is supposed 
to be used.


Pavel Pervov wrote:
> Egor,
> thank you for your prompt answer, but it looks like I wasn't clear enough
> describing my concerns.
> AFAIU, your answer is related to the second approach with constant pools.
> If I'm right, then there still exists the problem of merged constant pool
> being too long, and indexes in it exceeding 16-bit limit. This will require
> to provide per-instruction interface (as opposed to bytecode array access
> interface) to bytecode consumers. This, in turn, will require rewriting 
> main
> loops of verifier and interpreter, and bytecode preprocessing in both JITs.
> This is what I'm afraid of first of all.
> The rest should be implemented exactly in the way you've described. The 
> only
> generalization here is that "GC STW" is not required, we can just suspend
> all threads right in RedefineClasses implementation.
> Regards,
>    Pavel.
> P.S. Specification says though that "Threads need not be suspended". But I
> currently have no idea on how to achieve class and method replacement
> atomically without suspending other threads.
> On 01 May 2007 21:52:30 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
>> On the 0x2C9 day of Apache Harmony Pavel Pervov wrote:
>> > 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).
>> There should be nothing tricky in it for JIT. You get the new
>> bytecode, ask JIT (via EM) to recompile, then patch vtables and
>> call-sites. Then ask to recompile all methods that inlined the one you
>> have the new bytecode for, and do patching for them. Jitrino.JET does
>> not inline, it is blindingly easy. Jitrino.OPT reports all it has
>> inlined into VM via CompiledMethodLoadEvent, so you have all necessary
>> info.
>> Thus, no changes for JITs that I can see.
>> And this scheme does not need to detect if a method is running, new
>> methods will be executed as soon as the patching finishes, old code
>> will be executing up to the end with no problem.
>> The only trick is to free the allocated memory for compiled code and
>> stuff when the method is not on any of the stacks. GC stop-the-world
>> time is ideal for this.
>> > 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
>> > one?
>> we can instrument the method before running it the first time, then
>> detecting is faster, but for an extra space/time cost of executing the
>> method. Some profilers do so.
>> -- 
>> Egor Pasko

View raw message