RFR: 8199946: Move load/store and encode/decode out of oopDesc

[Stefan Karlsson]

Thanks Coleen,

I've uploaded new webrevs with the latest changes:

http://cr.openjdk.java.net/~stefank/8199946/webrev.03.delta
http://cr.openjdk.java.net/~stefank/8199946/webrev.03

StefanK

On 2018-03-23 17:05, coleen.phillimore at oracle.com wrote:
> 
> http://cr.openjdk.java.net/~stefank/8199946/webrev.02/src/hotspot/cpu/arm/nativeInst_arm_64.cpp.udiff.html 
> 
> http://cr.openjdk.java.net/~stefank/8199946/webrev.02/src/hotspot/cpu/arm/relocInfo_arm.cpp.udiff.html 
> 
> 
> I think the include should be oops/compressedOops.inline.hpp in these.
> 
> Besides my confusion over whether RawAccess<>::oop_load and store decode 
> the oop or not in the gc code, this looks really good to me.  It's nice 
> to encapsulate the compressedOops code now.
> 
> Thanks,
> Coleen
> 
> 
> 
> On 3/22/18 12:01 PM, Stefan Karlsson wrote:
>> Hi,
>>
>> This patch needs Erik's change to the LoadProxies:
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-March/021504.html 
>>
>>
>> to build on fastdebug.
>>
>> Here's a rebased patch:
>> http://cr.openjdk.java.net/~stefank/8199946/webrev.02/
>>
>> Thanks,
>> StefanK
>>
>> On 2018-03-21 18:27, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to get rid of the oopDesc::load/store 
>>> functions and to move the oopDesc::encode/decode functions to a new 
>>> CompressedOops subsystem.
>>>
>>> http://cr.openjdk.java.net/~stefank/8199946/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8199946
>>>
>>> When the Access API was introduced many of the usages of 
>>> oopDesc::load_decode_heap_oop, and friends, were replaced by calls to 
>>> the Access API. However, there are still some usages of these 
>>> functions, most notably in the GC code.
>>>
>>> This patch is two-fold:
>>>
>>> 1) It replaces the oopDesc load and store calls with RawAccess 
>>> equivalents.
>>>
>>> 2) It moves the oopDesc encode and decode functions to a new, 
>>> separate, subsystem called CompressedOops. A future patch could even 
>>> move all the Universe::_narrow_oop variables over to CompressedOops.
>>>
>>> The second part has the nice property that it breaks up a circular 
>>> dependency between oop.inline.hpp and access.inline.hpp. After the 
>>> change we have:
>>>
>>> oop.inline.hpp includes:
>>>    access.inline.hpp
>>>    compressedOops.inline.hpp
>>>
>>> access.inline.hpp includes:
>>>    compressedOops.inline.hpp
>>>
>>> Thanks,
>>> StefanK
>