RFR: 8204554: JFR TLAB tracing broken after 8202776

[Erik Österlund]

Hi,

StefanK says this looks good, but is unavailable for emailing right now. 
One more review to go.

Thanks,
/Erik

On 2018-06-07 16:57, Erik Österlund wrote:
> 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
>>
>