RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory [v4]
David Holmes
dholmes at openjdk.java.net
Tue Mar 16 09:15:20 UTC 2021
On Fri, 5 Mar 2021 16:04:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 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 `ThreadLocalAllocBuffer::allocate`:
>>
>> if (UseTLAB) {
>> result = (oop) THREAD->tlab().allocate(obj_size);
>> }
>>
>> ...which actually does mangle the object space in debug builds:
>>
>> inline HeapWord* ThreadLocalAllocBuffer::allocate(size_t size) {
>> invariants();
>> HeapWord* obj = top();
>> if (pointer_delta(end(), obj) >= size) {
>> // successful thread-local allocation
>> #ifdef ASSERT
>> // Skip mangling the space corresponding to the object header to
>> // ensure that the returned space is not considered parsable by
>> // any concurrent GC thread.
>> size_t hdr_size = oopDesc::header_size();
>> Copy::fill_to_words(obj + hdr_size, size - hdr_size, badHeapWordVal);
>> #endif // ASSERT
>> // This addition is safe because we know that top is
>> // at least size below end, so the add can't wrap.
>> set_top(obj + size);
>>
>> invariants();
>> return obj;
>> }
>> return NULL;
>> }
>>
>> So if we do `+ZeroTLAB` in debug builds, Zero skips initializing the object body, and gets scrambled memory for newly allocated object. Then everything breaks.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>
> - Refactor TLAB allocation code a bit
> - Adjust for the fact ThreadLocalAllocBuffer can mangle object space
> - Merge branch 'master' into JDK-8256732-zero-zerotlab-broken
> - Merge branch 'master' into JDK-8256732-zero-zerotlab-broken
> - Maintain the body/header initialization order
> - 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory
Marked as reviewed by dholmes (Reviewer).
src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1817:
> 1815: // - if TLAB is pre-zeroed, we can skip this path
> 1816: // - in debug mode, ThreadLocalAllocBuffer::allocate mangles
> 1817: // this area, and we still need to initialize it
That still sounds like a bug to me.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1343
More information about the hotspot-runtime-dev
mailing list