RFR (XXS): 8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get

Igor Veresov iggy.veresov at gmail.com
Fri Jul 26 14:59:34 PDT 2013


On Jul 26, 2013, at 2:00 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> 
>>>> The code dereferences src_klass (line 2301), which is of type T_OBJECT. The value of src_klass is read from memory of type T_ADDRESS. The result of the move seems to have the type of the first argument, so it would seem that if it's T_ADDRESS no decompression is going to happen and the deference is going to be problematic. Or does it work differently?
>>> 
>>> Why would there be no decoding?  As mentioned above the logic of decoding klass pointers is all in LIR_Assembler::mem2reg.  Maybe we should also change this, though:
>>> 
>>> -      LIR_Opr src_klass = new_register(T_OBJECT);
>>> +      LIR_Opr src_klass = new_register(T_ADDRESS);
>>> 
>> 
>> It probably should be T_METADATA? It can't be T_ADDRESS because it wouldn't be exposed in register maps for GC.
> 
> By register maps you mean oop maps?  The read is the G1 pre-barrier code and is only used for a type check. It doesn't live beyond that point.
> 

You're right it doesn't, the T_ADDRESS will work in the given context. However T_METADATA is the type properly describing the value, also in case someone decides to move things around it will be GC-safe. It also makes places like that easier to find.  But T_OBJECT seems to be incorrect, since it may get spilled and be in the frame for a longer time and GC will consider it to be an object on the heap, which it is not.

Either way with T_ADDRESS or T_METADATA here the code looks good.

Thanks!
igor




More information about the hotspot-compiler-dev mailing list