RFR (S): JDK-8027440: DefNew does not log heap change information when a promotion failure occurs

[Tao Mao]

looks good in general.

Could you make the regex pattern check more verbose?

say,

- Matcher stdoutMatcher = Pattern.compile("\\[GC .Allocation 
Failure.*K->.*K., .* secs\\]", Pattern.MULTILINE).matcher(stdout);
+ Matcher stdoutMatcher = Pattern.compile("\\[GC .Allocation 
Failure.*K->.*K\\(.*K\\), .* secs\\]", Pattern.MULTILINE).matcher(stdout);


On 11/1/13 2:03 PM, Bengt Rutisson wrote:
>
> Hi Tao,
>
> On 11/1/13 6:53 PM, Tao Mao wrote:
>> Hi Bengt,
>>
>> Thank you for looking at this.
>>
>> Can you explain why, in this particular case, the used heap size got 
>> larger after GC?
>
> It is because of the way the used value is calculated. The used value 
> for the DefNew generation is implemented as:
>
> size_t DefNewGeneration::used() const {
>   return eden()->used()
>        + from()->used();      // to() is only used during scavenge
> }
>
> Where, for both eden and from, used() is implemented as:
>
>   size_t used() const            { return byte_size(bottom(), top());
>
> Since we got a promotion failure the top value is not reset. There are 
> still objects in the eden and from spaces. This means that the used 
> value after the GC is whatever we managed to promote plus the full 
> young gen (except the to space). This is more than the used before the 
> GC, since that was just what was already in the old gen plus the full 
> young gen.
>
> This is the same behavior as with the other collectors.
>
> Thanks,
> Bengt
>
>>
>> Thanks.
>> Tao
>>
>> On 11/1/13 8:50 AM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Can I have a couple of reviews for this small change?
>>>
>>> http://cr.openjdk.java.net/~brutisso/8027440/webrev.00/
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8027440
>>>
>>> DefNew was not printing the heap change information when a promotion 
>>> failure occured. Before this change the logging for a DefNew 
>>> collection that got promotion failure looked like this:
>>>
>>> [GC (Allocation Failure) , 0.0543440 secs]
>>>
>>> After my change it looks like:
>>>
>>> [GC (Allocation Failure)  81920K->120831K(120832K), 0.0620180 secs]
>>>
>>> Thanks,
>>> Bengt
>