Request for review: JEP: GC Interface: Better isolation of GC implementations

[Erik Österlund]

Hi Roman,

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 
a bit.

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 
instead.

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 
possible performance.

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!

Thanks,
/Erik

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
>> document?
> 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
> appreciated.
>
> Roman
>
>
>> Kind regards,
>> Kirk
>>
>>> On Nov 15, 2016, at 7:02 PM, Roman Kennke <rkennke at redhat.com>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> No comments on that one?
>>>
>>> I'd like to move it to 'submitted' if nobody objects.
>>>
>>> Roman
>>>
>>> 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:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8163329
>>>>
>>>> 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
>>>> isolation.
>>>>
>>>> Best regards, Roman