TLAB Refills for x86

Doerr, Martin martin.doerr at
Tue Dec 5 12:59:35 UTC 2017

Hi Robbin,

ok. Thanks for the explanation.

Best regards,

-----Original Message-----
From: Robbin Ehn [mailto:robbin.ehn at] 
Sent: Dienstag, 5. Dezember 2017 13:52
To: Doerr, Martin <martin.doerr at>; Thomas Schatzl <thomas.schatzl at>; JC Beyler <jcbeyler at>; hotspot-dev at
Subject: Re: TLAB Refills for x86

Hi Martin,

On 2017-12-05 13:12, Doerr, Martin wrote:
> Hi,
> the interpreter change looks good to me (except the comment change).
> I've taken a look at C1 and C2 compilers.
> C2 already does it as desired: It either uses TLAB or shared eden allocation (if supported).
> Unfortunately, the C1 implementation in c1_Runtime1_x86/sparc still contains a path "try_eden" when TLAB allocation fails. (Also see MacroAssembler::tlab_refill). I think this should be adapted as well. Would you agree?

The flag FastTLABRefill will be obsoleted in JDK 11 and we can then start removing (after Dec 14) the functionality.
In 10 we turned FastTLABRefill off by default and deprecated it. (FastTLABRefill was only actually on when using non-G1 and for C1 only)
This will be handled in a separate enhancement 'removing dead code'.

This (interpreter tlab refills) will not make 10, instead targeted for 11.
So in 11 we are aiming for a consistence behavior in all (not looked at gral) 'compilers'.



> Best regards,
> Martin
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at] On Behalf Of Thomas Schatzl
> Sent: Dienstag, 5. Dezember 2017 12:07
> To: JC Beyler <jcbeyler at>; hotspot-dev at
> Subject: Re: TLAB Refills for x86
> Hi,
> On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
>> Hi all,
>> The TLAB and the inline contiguous allocations handling are different
>> for
>> each architecture. On certain architectures, TLAB is never actually
>> never
>> refilled (ref:
>> The idea behind the implementation for x86 is to separate TLAB usage
>> to
>> contiguous allocations in eden space.
>> Bug:
>> WebRev:
>> Does anyone see any issues with this webrev?
> I only see a slight issue with the new comment on how it works: the
> first time I read it, it seemed to me that step 1+2 are inclusive, not
> exclusive as is implemented (there is step 4 which explains that it is
> exclusive retroactively). But maybe it's just me.
> Looks good otherwise.
> Thomas

More information about the hotspot-dev mailing list