RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed

Kim Barrett kim.barrett at oracle.com
Mon Mar 30 01:28:01 UTC 2015


On Mar 28, 2015, at 12:31 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On Mar 27, 2015, at 4:22 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> That's my only question and it is for my education so you can
>> consider this a complete 2nd review.
> 
> Well, there may be further changes.  Thomas and Bengt wondered if excluding typeArrays
> allocated before the start of the in-progress concurrent mark might matter.  I’ve been looking
> at a way to still allow that.
> 
> Though maybe the version that has been reviewed is good enough, and the possible further
> improvement can be done as followup work?  Bengt and Thomas?

Another round on this.

In the previous version we disallowed eager reclaim of any humongous
objects that were allocated prior to the current snapshot when
concurrent marking was in progress.  As noted, there was some concern
(private email with Thomas and Bengt) that this would result in more
headroom being needed because some humongous objects that were
previously reclaimed now would not be.

This time we allow pre-snapshot humongous typeArrays to be candidates
for reclaiming.  However, we now ensure that such objects won't ever
be added to the mark stack.  We accomplish this by filtering out all
typeArrays from the mark stack; rather than pushing them we
immediately perform the "scan", which for typeArray objects amounts to
just doing some bookkeeping and checking task limits.

The addition of typeArray filtering in front of the mark stack is
rather far away from the place that is requiring it.  I'm not entirely
happy with this coupling, and would be OK with not going this extra
step.

The cost of the pre-filtering of the mark stack is small, and some of
it may be recovered by avoiding the cost of moving the filtered
objects through the mark stack, and by doing less work on the filtered
objects than would otherwise be needed. Aurora GC performance tests
show mostly insignificant differences, with a few small improvements
compared to the baseline that has bug 8069367.

[While I was at it, I simplified the conditionalization of
deal_with_references for _CHECK_BOTH_FINGERS_, eliminating some code
duplication.]

CR:
https://bugs.openjdk.java.net/browse/JDK-8069367

Webrev:
http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03/

Incremental webrev:
http://cr.openjdk.java.net/~kbarrett/8069367/webrev.03.incr/

Testing:
Hand testing
JPRT
Aurora Ad-hoc GC Nightly using G1
Aurora GC perf test using G1.




More information about the hotspot-gc-dev mailing list