RFR: 8204554: JFR TLAB tracing broken after 8202776

[Erik Österlund]

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
>