RFR (S): 8191888: Refactor ClassLoaderData::remove_handle to use the Access API
erik.osterlund at oracle.com
Tue Nov 28 12:19:54 UTC 2017
That is a good question.
There is a description (written by a GC person, but still) for each
decorator in the access.hpp file where the decorators are declared. I
try to go in to some details there when you should and should not use a
decorator. If we find that the text might have been biased from a GC
perspective, we can update the comments.
The previous situation has been to use naked accesses, and then suddenly
a GC person jumps in moaning about the lack of explicit #if
INCLUDE_ALL_GCS if (UseG1) SATB barrier goo, or manual insertion of
post-write barriers if a CAS was successful. There was no good way of
knowing you had to manually insert these barriers, what barriers were
offered to shared code, or what their semantics were.
Now at least you have a set of decorators to choose from, with some
automatic verification if you select nonsense decorators, and
documentation in one place what they are used for and what they mean. So
if you do not know what you need, at least you can read the descriptions
and hopefully figure it out, which was impossible before.
Having said that, I believe things like Coleen's OopHandle and
PhantomOopHandle will build a layer on top of Access with possibly a few
less details exposed that are even simpler to use for the conservative
non-GC person that just wants the thing to work as simple as possible
and wants to stay as far away from GC land as possible, which is sane.
And if you feel uncertain, you can always loop me in any time, and I
will probably say "there's a decorator for that".
I hope this answers your question.
On 2017-11-28 07:59, David Holmes wrote:
> Hi Erik,
> Is there a non-GC person's guide to what the different forms of
> RootAccess<XXX> mean and when to use them? Or do we expect a GC person
> to always jump in to show where such things are needed? ;-)
> On 27/11/2017 7:06 PM, Erik Österlund wrote:
>> The ClassLoaderData::remove_handle() member function currently uses
>> explicit G1 SATB barriers to remove an oop from the root set, as
>> these handles are not necessarily walked by the GC in a safepoint.
>> Therefore G1 needs pre-write barriers.
>> This should now be modeled as a
>> RootAccess<IN_CONCURRENT_ROOT>::oop_store instead. This maps to
>> performing a pre-write SATB barrier with G1, but other GCs are free
>> to do other things as necessary.
More information about the hotspot-gc-dev