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