Request for review: 7110428 Crash during HeapDump operation
David Holmes
david.holmes at oracle.com
Fri Nov 11 06:18:53 UTC 2011
Hi Poonam,
I've cc'ed GC-dev as this is more their area. It seems very wasteful to
potentially ensure_parsability and also do a full GC. And the check for
the active GC_Locker is somewhat arbitrary as it could change the
instant you've queried it.
It seems to me that a more complete solution here would enable
collect_as_vm_thread to indicate whether or not GC occurred. Which in
turn requires that do_full_collection report that info - a RFE that is
already noted in the G1 code at least:
void G1CollectedHeap::do_full_collection(bool clear_all_soft_refs) {
// do_collection() will return whether it succeeded in performing
// the GC. Currently, there is no facility on the
// do_full_collection() API to notify the caller than the collection
// did not succeed (e.g., because it was locked out by the GC
// locker). So, right now, we'll ignore the return value.
bool dummy = do_collection(true, /* explicit_gc */
clear_all_soft_refs,
0 /* word_size */);
}
David
-----
On 11/11/2011 3:20 PM, poonam.bajaj at oracle.com wrote:
> Hi,
>
> Can I get a couple of reviews for this change:
>
> CR 7110428: Crash during HeapDump operation
> http://monaco.sfbay.sun.com/detail.jsf?cr=7110428
>
> The crash happens when VM thread traverses the heap during heapdump
> operation and it finds the heap in non-parseable state. The heap can be
> left in non-parseable state if due to some reason GC is skipped and we
> didn't call ensure_parsability() either before dumping the heap. The
> solution is to always call ensure_parsability() In
> VM_HeapDumper::doit(), whether or not a GC is requested before the heap
> dumping.
>
> http://cr.openjdk.java.net/~poonam/7110428/webrev.00/
>
>
> Thanks,
> Poonam
>
>
More information about the hotspot-gc-dev
mailing list