RFR: 8065331: Add JVM trace events for failed allocations

[Erik Helin]

On 2015-04-09, Marcus Larsson wrote:
> On 04/08/2015 06:09 PM, Erik Helin wrote:
> >On 2015-04-08, Marcus Larsson wrote:
> >>On 04/08/2015 05:13 PM, Erik Helin wrote:
> >>>On 2015-04-08, Marcus Larsson wrote:
> >>>>Hi again,
> >>>>
> >>>>During offline discussions with Erik Helin we decided to skip the gc-attempt
> >>>>counter altogether, since this information had little value. Also, as the
> >>>>"Collect for allocation" event would always be accompanied by the (already
> >>>>existing) garbage collection events, this event is unnecessary and has been
> >>>>removed as well. Instead, to see allocations pending a particular GC, one
> >>>>can look at "Allocations requiring GC" events preceding the garbage
> >>>>collection event sent for that GC.
> >>>>
> >>>>New (significantly smaller) webrev:
> >>>>http://cr.openjdk.java.net/~mlarsson/8065331/webrev.02/
> >>>Looks good to me, Reviewed.
> >>>
> >>>Thanks,
> >>>Erik
> >>Thank you Erik!
> >Just had a quick look at the patch file and found this:
> >
> >@@ -210,7 +210,7 @@
> >  class VM_CollectForMetadataAllocation: public VM_GC_Operation {
> >   private:
> >    MetaWord*                _result;
> >-  size_t                   _size;     // size of object to be allocated
> >+  size_t                   _size;        // size of object to be allocated
> >
> >Why did you change the indentation of the comment?
> 
> It's a left-over from the larger patch that I seem to have missed. I will
> remove it before pushing. Thanks for catching it!

Ok, good, thanks.

Erik

> Marcus
> 
> >Thanks,
> >Erik
> >
> >>Marcus
> >>
> >>>>Thanks,
> >>>>Marcus
> >>>>
> >>>>
> >>>>On 04/02/2015 02:55 AM, Marcus Larsson wrote:
> >>>>>Hi Jon,
> >>>>>
> >>>>>Thank you for looking at this.
> >>>>>
> >>>>>The way I intended the gc count information to be useful is to indicate if/when allocations keep failing. Problematic allocations would then have a gc count higher than 1. It's not really critical that this is the exact total, as it's just an indication, so a partial GC count could work I guess. If you think it would be better I can take a look at how I can reduce the CR by being less precise with this counter.
> >>>>>
> >>>>>Thanks,
> >>>>>Marcus
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: jon.masamitsu at oracle.com
> >>>>>To: hotspot-gc-dev at openjdk.java.net
> >>>>>Sent: Wednesday, 1 April, 2015 4:44:30 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> >>>>>Subject: Re: RFR: 8065331: Add JVM trace events for failed allocations
> >>>>>
> >>>>>Marcus,
> >>>>>
> >>>>>These changes are rather extensive and the CR is rather thin
> >>>>>on details.  How will the GC count information be useful?
> >>>>>Is it critical that it be the total GC count for failed allocation?
> >>>>>Could some partial GC count that does not require such
> >>>>>extensive changes be almost as useful?
> >>>>>
> >>>>>Thanks.
> >>>>>
> >>>>>Jon
> >>>>>
> >>>>>On 3/30/2015 3:54 PM, Marcus Larsson wrote:
> >>>>>>Ping!
> >>>>>>
> >>>>>>----- Original Message -----
> >>>>>>From: marcus.larsson at oracle.com
> >>>>>>To: hotspot-gc-dev at openjdk.java.net
> >>>>>>Sent: Tuesday, 24 March, 2015 7:35:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> >>>>>>Subject: RFR: 8065331: Add JVM trace events for failed allocations
> >>>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>Please review the following patch adding new trace events for allocations requiring GC, and GCs triggered by allocation. See the JEP for a description of these two new events.
> >>>>>>
> >>>>>>CR:
> >>>>>>https://bugs.openjdk.java.net/browse/JDK-8065331
> >>>>>>
> >>>>>>Webrev:
> >>>>>>http://cr.openjdk.java.net/~mlarsson/8065331/webrev.00/
> >>>>>>
> >>>>>>JEP:
> >>>>>>https://bugs.openjdk.java.net/browse/JDK-8060092
> >>>>>>
> >>>>>>Tests:
> >>>>>>jprt, jtreg
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Marcus
>