RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory

Aleksey Shipilev shade at openjdk.java.net
Fri Nov 20 10:14:21 UTC 2020


Looks like memory is badly initialized when `-XX:+ZeroTLAB` is specified.

Manifests like this:

$ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/memoryinitialization/ZeroTLABTest.java

command: main -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest
reason: User specified action: run main/othervm -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest
Mode: othervm [/othervm specified]
elapsed time (seconds): 0.098
configuration:
STDOUT:
Error occurred during initialization of VM
java.lang.NullPointerException
at java.lang.System.getProperty(java.base/System.java:836)

The cause is simple: Zero calls this method:

            if (UseTLAB) {
              result = (oop) THREAD->tlab().allocate(obj_size);
            }

...which says:

  // Allocate size HeapWords. The memory is NOT initialized to zero.
  inline HeapWord* allocate(size_t size);
So if we do `+ZeroTLAB`, then Zero skips zeroing the object body, and gets bad uninitialized memory for non-zeroed TLAB. Since `ZeroTLAB` is "false" by default, I believe just doing the object body initialization unconditionally is fine.

-------------

Commit messages:
 - 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory

Changes: https://git.openjdk.java.net/jdk/pull/1343/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256732
  Stats: 19 lines in 1 file changed: 10 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1343.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1343/head:pull/1343

PR: https://git.openjdk.java.net/jdk/pull/1343


More information about the hotspot-runtime-dev mailing list