RFR (M): 8086053: Address inconsistencies regarding ZeroTLAB
zoltan.majo at oracle.com
Mon Jan 11 13:37:33 UTC 2016
On 01/11/2016 02:11 PM, Zoltán Majó wrote:
> Yes, that is a good idea. I added a test that launches the VM with all
> flag combinations and also with different GCs. I did the same what the
> test does to reproduce the original failure.
> Here is the updated webrev:
The test contains and unnecessary @library tag and package import. The
year in the copyright statement must be changed as well (to 2016).
Here is the webrev with those changes:
Sorry for the noise.
Thank you and best regards,
> The newly added test passes on all supported platforms.
> Thank you and best regards,
>> On 08.01.2016 12:06, Zoltán Majó wrote:
>>> please review the patch for 8086053.
>>> Problem: With ZeroTLAB enabled, the GC is supposed to zero-fill
>>> newly allocated TLAB regions. With ZeroTLAB disabled, the
>>> interpreter and compiled code should assume the responsibility to
>>> zero-fill newly allocated regions.
>>> Currently, the handling of the ZeroTLAB flag shows some
>>> inconsistencies between the GC and the compilers. These
>>> inconsistencies lead to newly allocated regions not being filled
>>> with zeros.
>>> Solution: Address the following:
>>> - With -XX:+FastTLABRefill, C1-compiled code refills the TLAB
>>> without notifying the GC. As a result, the newly allocated TLAB is
>>> not initialized with zero. Add TLAB initialization code to C1.
>>> - With -XX:+ZeroTLAB, the C2 compiler skips zero-initialization of
>>> newly allocated objects/arrays even if TLAB allocation is disabled.
>>> Add stricter conditions to C2 on when to skip filling objects/arrays
>>> with zero.
>>> - local testing (linux_x86_64) of failing test case with
>>> -XX:+UseG1GC and -XX:+UseSerialGC;
>>> - JPRT;
>>> - all hotspot tests on all platforms affected by the change using
>>> all combinations of +/-UseTLAB and +/-ZeroTLAB.
>>> Thank you and best regards,
More information about the hotspot-compiler-dev