RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory [v2]

[Aleksey Shipilev]

> 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.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Maintain the body/header initialization order

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1343/files
  - new: https://git.openjdk.java.net/jdk/pull/1343/files/bca31060..8200d894

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=00-01

  Stats: 18 lines in 1 file changed: 9 ins; 9 del; 0 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