TLAB Refills for x86
martin.doerr at sap.com
Tue Dec 5 12:59:35 UTC 2017
ok. Thanks for the explanation.
From: Robbin Ehn [mailto:robbin.ehn at oracle.com]
Sent: Dienstag, 5. Dezember 2017 13:52
To: Doerr, Martin <martin.doerr at sap.com>; Thomas Schatzl <thomas.schatzl at oracle.com>; JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
Subject: Re: TLAB Refills for x86
On 2017-12-05 13:12, Doerr, Martin wrote:
> 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,
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas Schatzl
> Sent: Dienstag, 5. Dezember 2017 12:07
> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: Re: TLAB Refills for x86
> On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
>> Hi all,
>> The TLAB and the inline contiguous allocations handling are different
>> each architecture. On certain architectures, TLAB is never actually
>> refilled (ref: https://bugs.openjdk.java.net/browse/JDK-8190862).
>> The idea behind the implementation for x86 is to separate TLAB usage
>> contiguous allocations in eden space.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
>> 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.
More information about the hotspot-dev