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 <[EMAIL PROTECTED]> wrote:
On 5/2/07, George Timoshenko <[EMAIL PROTECTED]> 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
