RFR: 8140257: Add support for "gc service threads" to ConcurrentGCThread

[Derek White]

I'm working on a new webrev, so please hold off on reviewing.

Some offline comments from Kim suggest trying another approach. Any 
other approach :-) He rightly pointed out the poor match between the new 
code and ConcurrentMarkSweepThread is pretty ugly.

Two other options I'm looking at are either having 
ConcurrentMarkSweepThread not subclass from ConcurrentGCThread, or (more 
likely) refactor ConcurrentMarkSweepThread to use the common termination 
protocol instead of doing it's own thing. The approach of adding an 
intermediate class that handles the common code being factored out was 
rejected in review comments for "8138920".

  - Derek

On 2/26/16 11:56 AM, Derek White wrote:
> *Background*:
> ConcurrentGCThread provides incomplete support for an initialization 
> and termination protocol for GC threads, so missing parts are 
> duplicated in almost all subclasses.
>
> *Fix*:
> Move duplicated run(), and stop() methods up from subclasses 
> ConcurrentG1RefineThread, ConcurrentMarkThread, G1StringDedupThread, 
> and G1YoungRemSetSamplingThread to ConcurrentGCThread, as well as 
> declare virtual methods run_service() and stop_service.
>
> Note that ConcurrentMarkSweepThread is the odd-ball subclass. It 
> implements it's own termination protocol, it provides it's own run() 
> and stop() methods, and does not use run_service() and stop_service().
>
> *Bug*: https://bugs.openjdk.java.net/browse/JDK-8140257
> *Webrev*: http://cr.openjdk.java.net/~drwhite/8140257/webrev.01/
>
> *Tests*: jprt, Aurora "nightly" run (I think this is OK)
> http://aurora.ru.oracle.com/faces/Batch.xhtml?batchName=1325690.VMSQE.adhoc.JPRT 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160226/b46ec001/attachment.htm>