RFR: 8042235: redefining method used by multiple MethodHandles crashes VM

KEVIN WALLS kevin.walls at oracle.com
Mon Jan 12 22:22:00 UTC 2015

Hi Serguei -

Thanks oops yes I seem to have mishandled that part, I'll change it.

Unfortunately I think I still have the wierd constantpoolcache crash I 
mentioned in the email just now, gotta keep looking at that and then 
I'll update the webrev including this finalizer setup call.


On 12/01/2015 19:50, serguei.spitsyn at oracle.com wrote:
> Hi Kevin,
> src/share/vm/prims/jvm.cpp
>   645     new_obj = instanceKlass::register_finalizer(instanceOop(new_obj_oop), CHECK_NULL);
> The above looks incorrect.
> The new_obj() must be used in stead of the new_obj_oop.
> Thanks,
> Serguei
> On 12/17/14 7:48 AM, KEVIN WALLS wrote:
>> Hi,
>> This is a request for review of a backport to 7u of 8042235. There 
>> are a few changes from the original, hence the request here.
>> On JDK7 this is not a crash, but we run the wrong method, i.e. 
>> invocation through a MethodHandle invokes the old version of the 
>> method, if it has been redefined.
>> The test is different also: in jdk8 we have the ASM library, and can 
>> visit methods and bytecodes.  Here in 7, I wrote a non-bytecode aware 
>> byte replacer method, and replaced some literal bytecode sequence 
>> with another.   As we're crafting a method that we will rewrite, we 
>> can do something that avoids use of the constant pool (which we 
>> haven't actually understood in this trivial rewriter), so we rewrite 
>> some simple arithmetic, and from the result of the method it's 
>> obvious whether we are running the correct code.
>> Coleen: thanks for your earlier hints on oop / obj_field vs. 
>> address_field.
>> bug
>> https://bugs.openjdk.java.net/browse/JDK-8042235
>> webrev
>> http://cr.openjdk.java.net/~kevinw/8042235/webrev.00/
>> Thanks
>> Kevin

More information about the hotspot-runtime-dev mailing list