RFR: 8138920: Refactor the sampling thread from ConcurrentG1RefineThread
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Oct 21 08:51:27 UTC 2015
Hi,
On Tue, 2015-10-20 at 15:56 -0400, Derek White wrote:
> 4th Webrev for review please:
>
> This version includes the cleanups suggested by Per.
>
> RFE: JDK-8138920 Refactor the sampling thread from
> ConcurrentG1RefineThread
>
> Webrev: http://cr.openjdk.java.net/~drwhite/8138920/webrev.04/
>
> jprt: waiting for results (which might take a long time given current
> jprt status).
>
> Thanks for looking!
Looks good overall. Some minor comments:
- I am okay with deferring the move of the sample thread to another CR.
Is there a CR for that already?
- the comment for ConcurrentG1Refine::sampling_thread() might need some
elaboration.
- also add some description of the purpose of the new
G1YoungListSampleThread class. I am okay with the name, it could be more
specific like G1YoungRemSetSamplingThread. I will let you decide whether
to keep it.
- please rename
ConcurrentMarkThread::handle_adaptive_young_list_length() to something
more meaningful. The method delays the current thread so that the next
expected pauses observe the MMU. (I think it is really good to extract
this into a method!)
So something like observe_mmu() or delay_thread_to_keep_mmu() would be
imo more appropriate. These are just suggestions I came up within a few
seconds though...
- please also add some description of what these new methods do if not
really obvious. E.g. that handle_adaptive_young_list_length() method
does not qualify for obvious :) I saw that the change fixes existing
comments, but they are few and far between.
Thanks for handling this issue,
Thomas
More information about the hotspot-gc-dev
mailing list