Enhanced Class Redefinition JEP

[Thomas Wuerthinger]

Jon,

The underlying implementation changes from merging the constant pools of 
the old and the new class version to performing a heap iteration that 
swaps pointers. However, this change is not visible to users of the 
class redefinition API. The behavior in terms of effects observable 
through the JVMTI interface stays the same (for example in the case that 
a modified method is active on the stack).

We do not yet have performance comparison numbers between the old and 
the new algorithm. However, if the heap iteration turns out to be a 
bottleneck, we can implement a workaround where the iteration is not 
necessary when only method bodies are swapped.

- thomas


On 7/29/2011 10:29 AM, Jon Masamitsu wrote:
> Thomas,
>
> From the JEP Description section
>
> "The behavior of the current mechanism that swaps method bodies is 
> unaffected."
>
> As I recall some of the class redefinition in your implementation 
> requires
> doing a heap iteration (scan and update similar to a full GC)
> to update references to redefined classes.
> Does the statement above from the description mean that in your
> implementation the swapping method bodies does not require the
> heap iteration?  I think the current implementation in hotspot does
> not require such an iteration.
>
> Jon
>
>
>
>
> On 7/27/2011 3:03 PM, Thomas Wuerthinger wrote:
>> Hi all,
>>
>> find attached a JDK Enhancement-Proposal (JEP) for enhancing 
>> HotSpot's class redefinition capabilities. The proposed features 
>> include adding/removing methods and fields as well as adding 
>> supertypes. The JEP includes links to a prototype implementation and 
>> technical publications about the approach.
>>
>> Regards,
>> Thomas Wuerthinger