RFR: 8065331: Add JVM trace events for failed allocations

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Thu Apr 9 08:24:45 UTC 2015


Looks good!

Thanks,
/Jesper

Erik Helin skrev den 9/4/15 09:33:
> 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
>>


More information about the hotspot-gc-dev mailing list