RFR: 8204554: JFR TLAB tracing broken after 8202776

[Erik Österlund]

Hi Roman,

Thanks for the review.

/Erik

On 2018-06-07 17:11, Roman Kennke wrote:
> Looks good. Go!
>
> Thanks,
> Roman
>
>> Hi Roman,
>>
>> Thanks for the review.
>> StefanK thought it would be nicer to move the outside of TLAB path into
>> a new function. So I did that. Hope you agree that is a good idea. If
>> you want to override that behaviour you can still override
>> obj_allocate_raw.
>>
>> Full webrev:
>> cr.openjdk.java.net/~eosterlund/8204554/webrev.01/
>>
>> Incremental webrev:
>> cr.openjdk.java.net/~eosterlund/8204554/webrev.00_01/
>>
>> Checked again that tests pass now, and it passes.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-06-07 16:41, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>>> The recent allocation path modularization (8202776) broke JFR TLAB
>>>> sampling. This was discovered in tier 5 testing.
>>>>
>>>> The problem is that there was previously an early exit TLAB path, that
>>>> should not run the tracing code when not returning NULL, and a
>>>> mem_allocate call that should run the tracing code when not returning
>>>> NULL. However, these paths were joined in a virtual member function,
>>>> making them look the same to the tracing code, which caused the non-TLAB
>>>> tracing code to be run on TLAB allocations as well.
>>>>
>>>> The solution I propose is to move the TLAB tracing code into the new
>>>> virtual member function. It seems that whatever GC overrides this code,
>>>> should also decide what to do about the tracing code there anyway.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8204554/webrev.00/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8204554
>>>>
>>>> I have run failing tests locally to verify they have been fixed with the
>>>> proposed patch. I am now running hs-tier1-3 as well, but am waiting for
>>>> the results.
>>> This looks good to me. Thank you!
>>>
>>> Roman
>>>
>