Request for review: JEP: GC Interface: Better isolation of GC implementations
erik.osterlund at oracle.com
Wed Nov 23 09:00:17 UTC 2016
Thanks for the updated webrev. I like what you are doing here. I think
it looks very ambitious and I like it. The current GC "interface" has
been in our fridge a bit too long and probably passed its expiry date by
I will commit to helping out with this GC interface. I have some ideas
involving GC barrier C++ templates. Thought I would share some thoughts.
The general theme is combining attributes such as build time attributes
(e.g. Shenandoah built or not), JVM runtime attributes (e.g. compressed
oops or not), access attributes (e.g. memory ordering constraints),
access GC attributes (e.g. is this a weak reference), possibly caller
contexts (e.g. is this called by GC or mutator), into a neat way for
users of the barriers, while providing best possible performance.
Instead these things tend to be split into different orthogonal concerns
There is currently a separate load acquire, one for volatiles, and
compressed oops is dealt with separately and write barriers separately
again. And the fact that Reference.get uses pre-write barriers because
they happen to be SATB marking barriers even though they have nothing to
do with actually writing gives me a horrible feeling. Yuck! In certain
cases like oop_iterate macros we try to catch single dynamic context
attributes such as whether compressed oops is used early to amortize
those barrier costs over multiple loads. But I would like to
(eventually) catch more such context info and hence want that context
decorating the barriers represented explicitly in a unified way using
templates. By enriching the barrier contexts, the aim is for the GC
interface to be more generic, be simple to use, while keeping the best
I will take your patch for a spin and see if I can add some template
magic in there. I hope you like the idea!
On 2016-11-21 12:26, Roman Kennke wrote:
> Hi Kirk,
> Thanks for yor feedback.
>> I have no official say in this but it the object is quite clear
>> spelled out and certainly is desirable. That said the spec is written
>> at a high enough level that it’s not clear about the complexity and
>> hence dangers/risks in (failing to ) identifying/isolating all the
>> touch points is spelled out.
> I added:
> "We may fail to identify and/or isolate all the touch points between GC
> and rest of the JVM."
> under Risks & Assumptions.
>> Also, should we comment on testing here? Will this work require a new
>> set of regression tests? Or, is that beyond the scope of this
> I am not sure. It may be possible and useful to test the GC interface
> by implementing a 'mock' GC and verifying its methods are called in all
> the right situations. Infact, a clean GC interface could actually help
> with testing all sorts of other JVM internals too. Problem is I don't
> know how complex such an effort would be, I have never done such sort
> of testing with C++. Any input from you folks on this topic would be
>> Kind regards,
>>> On Nov 15, 2016, at 7:02 PM, Roman Kennke <rkennke at redhat.com>
>>> Hi all,
>>> No comments on that one?
>>> I'd like to move it to 'submitted' if nobody objects.
>>> Am Dienstag, den 16.08.2016, 19:37 +0200 schrieb Roman Kennke:
>>>> Hi all,
>>>> I would like to ask for your opinion on the JEP draft:
>>>> It was born out of the discussion around JEP 291: Deprecate the
>>>> Concurrent Mark Sweep (CMS) Garbage Collector, and the
>>>> development of
>>>> the Shenandoah GC, both of which would benefit greatly from
>>>> better GC
>>>> Best regards, Roman
More information about the hotspot-gc-dev