RFR (S): 8191888: Refactor ClassLoaderData::remove_handle to use the Access API
david.holmes at oracle.com
Tue Nov 28 21:28:42 UTC 2017
On 28/11/2017 10:19 PM, Erik Österlund wrote:
> Hi David,
> 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 comments serve as a reference, but I think we may lack a "tutorial".
:) As I think someone commented earlier re the Access API, how do I know
that, for example, IN_CONCURRENT_ROOT applies when I have no idea what
may or may not be scanned during safepoint ??
But that's OT.
> 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