RFR: 8274527: Minimal VM build fails after JDK-8273459

[Scott Gibbons]

On Wed, 29 Sep 2021 23:41:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The broken was observed when
> 
> (gdb) bt
> #0  MacroAssembler::align (this=0x7ffff0025b98, modulus=32) at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/macroAssembler_x86.cpp:1182
> #1  0x00007ffff67fc6c5 in MacroAssembler::kernel_crc32 (this=0x7ffff0025b98, crc=0x7, buf=0x6, len=0x2, table=0x1, tmp=0xb)
>     at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/macroAssembler_x86.cpp:6911
> #2  0x00007ffff69a3555 in StubGenerator::generate_updateBytesCRC32 (this=0x7ffff5e9c900) at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp:6532
> #3  0x00007ffff69a589b in StubGenerator::generate_initial (this=0x7ffff5e9c900) at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp:7583
> #4  0x00007ffff69a6801 in StubGenerator::StubGenerator (this=0x7ffff5e9c900, code=0x7ffff5e9c9c0, all=false)
>     at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp:7909
> #5  0x00007ffff697fa21 in StubGenerator_generate (code=0x7ffff5e9c9c0, all=false) at /home/jvm/jiefu/docker/jdk/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp:7919
> #6  0x00007ffff69a6c13 in StubRoutines::initialize1 () at /home/jvm/jiefu/docker/jdk/src/hotspot/share/runtime/stubRoutines.cpp:223
> #7  0x00007ffff69a790d in stubRoutines_init1 () at /home/jvm/jiefu/docker/jdk/src/hotspot/share/runtime/stubRoutines.cpp:366
> #8  0x00007ffff672044d in init_globals () at /home/jvm/jiefu/docker/jdk/src/hotspot/share/runtime/init.cpp:119
> #9  0x00007ffff69fb39f in Threads::create_vm (args=0x7ffff5e9ce10, canTryAgain=0x7ffff5e9cd33) at /home/jvm/jiefu/docker/jdk/src/hotspot/share/runtime/thread.cpp:2827
> #10 0x00007ffff6787879 in JNI_CreateJavaVM_inner (vm=0x7ffff5e9ce68, penv=0x7ffff5e9ce70, args=0x7ffff5e9ce10)
>     at /home/jvm/jiefu/docker/jdk/src/hotspot/share/prims/jni.cpp:3616
> #11 0x00007ffff6787a72 in JNI_CreateJavaVM (vm=0x7ffff5e9ce68, penv=0x7ffff5e9ce70, args=0x7ffff5e9ce10)
>     at /home/jvm/jiefu/docker/jdk/src/hotspot/share/prims/jni.cpp:3704
> #12 0x00007ffff79b8141 in InitializeJVM (pvm=0x7ffff5e9ce68, penv=0x7ffff5e9ce70, ifn=0x7ffff5e9cec0)
>     at /home/jvm/jiefu/docker/jdk/src/java.base/share/native/libjli/java.c:1459
> #13 0x00007ffff79b4f39 in JavaMain (_args=0x7fffffffb1a0) at /home/jvm/jiefu/docker/jdk/src/java.base/share/native/libjli/java.c:411
> #14 0x00007ffff79bba79 in ThreadJavaMain (args=0x7fffffffb1a0) at /home/jvm/jiefu/docker/jdk/src/java.base/unix/native/libjli/java_md.c:651
> #15 0x00007ffff779cea5 in start_thread () from /lib64/libpthread.so.0
> #16 0x00007ffff72c19fd in clone () from /lib64/libc.so.6
> 
> 
> In this case, modulus=32 and CodeEntryAlignment=16.
> 
> So this assert shouldn't be added in `align` since we may use it (modulus > CodeEntryAlignment) in highly optimized hand-crafted assembly code.
> 
> Thanks.
> Best regards,
> Jie

Hi, Jie.  With a value of 16 for `CodeEntryAlignment`, there is no way to ensure that the address of the byte following the `align(32)` is, in fact, 32-byte aligned.  This is the exact case that I found that caused me to file the bug.  I would suggest you verify this with an `assert` following your `align(32)` verifying that the alignment is correct.  I think you'll discover that it will be unaligned ~50% of the time.

This is because `align()` uses the **_offset_** from the beginning of the segment to determine the number of `nop`s to emit.  If the segment has the starting address 0xXXXXXX10 (16-byte aligned), `align(32)` will calculate the `offset()` and align the pc to a multiple of 32 bytes from this starting address.  This means that the address after the `align(32)` has the possibility of being 0xXXXXXX30 about half the time.

I would suggest that if you absolutely require 32-byte alignment, you take a similar path that I took for 64-byte alignment.  That is, to create `align32()` and have it call `align(32, pc())`.  This will ensure (for stub code) that the alignment is correct.

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

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