RFR (XXS): 8048085: Aborting marking just before remark results in useless additional clearing of the next mark bitmap
bengt.rutisson at oracle.com
Mon Jul 7 13:44:36 UTC 2014
On 2014-07-07 14:46, Thomas Schatzl wrote:
> Hi all,
> can I have reviews for the following minor performance fix noticed
> during work on JDK-8038423 (G1: Decommit memory within the heap)?
> The situation is that when a full GC aborts concurrent marking, the
> concurrent mark thread needlessly clears the next mark bitmap again
> (concurrently this time) in ConcurrentMark::abort().
> The fix is to skip this phase in this case.
> An alternative, always keeping this phase but not doing this bitmap
> clear at Full GC abort (JDK-7098512) would be possible. However doing
> that would make JDK-8048084 (sending out reviews soon) much harder as we
> would need to keep track of regions that have become unavailable.
> This change also does not change anything about duration of Full GC. So
> I would prefer to postpone JDK-7098512.
A couple of minor comments:
The comment in ConcurrentMark::abort() for the bitmap clearing was
always misleading (as stated in JDK-7098512). Would maybe be good to
update it now to explain why it is really needed.
What do you think about asserting that the bitmap is clear in
ConcurrentMarkThread::run() if cm()->has_aborted() ?
> JPRT, running a lot of adhoc-test runs as part of the 8038423 changes.
More information about the hotspot-gc-dev