RFR: 8218734: SA: Incorrect and raw loads of OopHandles

[Stefan Karlsson]

Hi Jini,

On 2019-02-14 18:11, Jini George wrote:
> Hi Stefan,
>
> Other than the getAddressField to getField change and the comments by 
> Erik, I just have a couple of nits to add.
>
> 1. This line in VMOopHandle.java can be removed:
>
> 31 import sun.jvm.hotspot.runtime.VMObjectFactory;

Done.

>
> 2. The copyright year for some of the files need updation.

Sure.

>
> This looks good to me otherwise.

Thanks for reviewing.

StefanK

>
> Thanks,
> Jini.
>
>
> On 2/11/2019 2:09 PM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to fix the resolving of oops inside the (VM) 
>> OopHandles.
>>
>> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8218734
>>
>> Before this patch the OopHandle::_obj was assumed to be located at 
>> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and 
>> ClassLoaderData::_class_loader) without the required load barrier for 
>> ZGC. I've added a new class VMOopHandle (The SA already has a 
>> OopHandle), which handles the resolving (load or load + barrier).
>>
>> The OopHandle type is grouped under the Oops section in 
>> vmStructs.cpp. It's not an oop, so I added a newline to separate it 
>> out from the rest. Any suggestion of a better location in that file?
>>
>> Tested with the jtreg tests in serviceability/sa + patches to make 
>> ZGC usable with the SA's hprof dumping.
>>
>> Thanks,
>> StefanK