On line 868 of src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp the code reads:

  char* hint = (char*)(Linux::initial_thread_stack_bottom() -
                       (JavaThread::stack_guard_zone_size() + page_size));
  char* codebuf = os::attempt_reserve_memory_at(page_size, hint);

This relies on Linux::initial_thread_stack_bottom() returning non-NULL (unconditionally). However Linux::initial_thread_stack_bottom() is only initialized in Linux::capture_initial_stack() when NOT being launched via a java launcher post JDK-8199717. This results in pointer arithmetic wrapping around, which is undefined behavior.

With an instrumented JVM one can notice this runtime error:

src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: pointer index expression with base 0x00000000 overflowed to 0xffffb000

And indeed, when running with -Xlog:os=info on x32 Linux we see this:

bin/java -Xlog:os=info -version 2>&1 | grep 'CS limit NX'
[0.002s][info][os] [CS limit NX emulation work-around, exec code at: 0xffffb000]
bin/java -Xlog:os=info -version 2>&1 | grep 'CS limit NX'
[0.002s][info][os] [CS limit NX emulation work-around, exec code at: 0xffffb000]
bin/java -Xlog:os=info -version 2>&1 | grep 'CS limit NX'
[0.002s][info][os] [CS limit NX emulation work-around, exec code at: 0xffffb000]

On JDK 8u this looks like:

$ java -XX:+PrintMiscellaneous -XX:+Verbose -version 2>&1 | grep 'CS limit NX'
[CS limit NX emulation work-around, exec code at: 0xffb21000]
$ java -XX:+PrintMiscellaneous -XX:+Verbose -version 2>&1 | grep 'CS limit NX'
[CS limit NX emulation work-around, exec code at: 0xff76d000]
$ java -XX:+PrintMiscellaneous -XX:+Verbose -version 2>&1 | grep 'CS limit NX'
[CS limit NX emulation work-around, exec code at: 0xff95e000]