[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8218734: SA: Incorrect and raw loads of OopHandles
From:       Jini George <jini.george () oracle ! com>
Date:       2019-02-14 17:23:42
Message-ID: 2a1b75dd-6b87-9a1d-98a7-385bd8d96877 () oracle ! com
[Download RAW message or body]

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;

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

This looks good to me otherwise.

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
[prev in list] [next in list] [prev in thread] [next in thread]