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:33:49 GMT
Mikhail,

yes, we surely need support for such methods. In the current codebase we
will have only problems with not-successfully-resolved references from the
code. After lazy resolution is implemented - we'll also have problems with
long running methods.

There is no problem from the POV of JVMTI. If a method redefined is being
executed, it is allowed to run until finished, it is assigned a new
methodID, and old methodID is assigned for new version of this method.

Regards,
     Pavel.
On 5/2/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:

> 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.
>
>
> This is not true in Lazy Resolution mode. All lazy resolution helpers have
> at least 2 arg: enclosing class handle + cp-index.
>
> 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, I need some clarification too.
> Do you want support to redefine methods that are never exit ?
> Example:
> while(true) {
>       doSomething()
> }
>
>
>
>
>
> --
> Mikhail Fursov
>



-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

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