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

[Roman Kennke]

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
>