RFR (S): 8076463: Add logging for the preserve CM referents task

Thomas Schatzl thomas.schatzl at oracle.com
Thu Feb 25 16:18:41 UTC 2016


Hi Jon,

On Thu, 2016-02-25 at 07:56 -0800, Jon Masamitsu wrote:
> Thomas,
> 
> Why did you decide to move preserve_cm_referents() out of
> process_discovered_references()?  The work done in
> preserve_cm_referents() has to be performed before it
> is safe to do the work in process_discovered_references()
> so it seems safer to call preserver_cm_referents() at
> the beginning of preserve_discovered_references().

  - to preserve the kind-of pattern in the methods that do some
parallel work.

I am kind of trying to all make them look like:

void G1CollectedHeap::some_phase(G1ParScanThreadStateSet*
per_thread_state) {
  cur_time = get_current_time_stamp();

  do_work();

  log_duration(cur_time);
}

to at some point change the first and last line into a scoped object,
or probably better move the scoped object out of the method call.

So that the code (maybe) looks like:

{
  ScopedObjectForTiming x();
  do_x(per_thread_states);
}

{
  ScopedObjectForTiming y();
  do_y(per_thread_states);
}

[...]

Also, the code then also corresponds more to the logging, having every
log line at "top level" without any nesting.

- preserve cm referents is kind of reference processing part 0 to me
(if process_discovered_references is part 1 as described in the comment
in line g1CollectorPolicy.cpp:4500). Similar to reference enqueuing it
seems (and needs) to be a completely separate phase of what
process_discovered_references() does.

- looking at existing code, we already split out the reference
enqueueing into an extra method to be called in the
post_evacuate_collection_set() method (I know that there is a
dependency with the Clear CT phase right now, but I am kind of mulling
over completely removing it after some... other changes).

If you think it is still better to call preserve_cm_referents() within
process_discovered_references(), I will change it.

Thanks,
  Thomas



More information about the hotspot-gc-dev mailing list