RFR: 8189171: Move GC argument processing into GC specific classes

Roman Kennke rkennke at redhat.com
Thu Oct 12 19:59:43 UTC 2017


I'm posting it to both hotspot-runtime-dev and hotspot-gc-dev because it 
touches both areas (i.e. the GC interface).

Currently, all GC related argument processing is done in arguments.cpp, 
littering it with #ifdef INCLUDE_ALL_GCS and all sorts of GC specific 
methods etc.

In order to have a cleaner GC interface, I propose to move all that code 
into GC specific classes under their GC specific directories.

Since at this point in time we haven't created the XXXHeap subclasses 
yet (and cannot, before having set up all the flags and arguments), I 
propose to create a GC interface of which we create an instance as soon 
as we have selected a GC, and then do argument processing there.

This 'GC' interface is, at this point, meant as a sort of GC factory 
interface. With this patch, it will only do argument processing. Later I 
plan to add heap creation to it (which is currently done in 
universe.cpp, with INCLUDE_ALL_GCS stuff and all the if (UseBlahGC) .. 
else if .. else branch chains. My current prototype in the jdk10 sandbox 
also provides servicabilty support classes and some more stuff, but we 
should decide later where to put this.

I broke out some code paths into gc_factory.cpp (i.e. not in gc.cpp). 
Those are all the code paths that select GC, create the right instances, 
etc, in other words, the code paths that need to know about all GCs. 
Ideally, this should be the only file that needs to know about all the 
GCs. (Suggestions for improvement are welcome of course.)

I tested this by running hotspot_gc jtreg tests, with normal fastdebug 
and no-precompiled configurations. Everything passes fine.

http://cr.openjdk.java.net/~rkennke/8189171/webrev.00/ 
<http://cr.openjdk.java.net/%7Erkennke/8189171/webrev.00/>

Opinions?

Roman




More information about the hotspot-gc-dev mailing list