harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm][jvmti] RedefineClasses.
Date Thu, 03 May 2007 05:30:12 GMT
In current codebase "merged" constant pool will cause many problems for
interpreter and one problem for JIT - if call to "throw_linking_exception"
stub is compiled into some method. As you may remember it contains immediate
value of constant pool index of a referenced class.

Also, Mikhail noted new functionality currently being implemented - lazy
resolution. It will also be heavily affected with constant pool merging.

Regards,
    Pavel.
On 5/2/07, George Timoshenko <george.timoshenko@gmail.com> wrote:

> 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.
>
>
> George.
>
>
> 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
> >>
> >>
> >
> >
>
>


-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

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