RFR: 8042243: Map shared archive to preallocated static address
ioi.lam at oracle.com
Tue May 6 18:14:50 UTC 2014
The C code in HotSpot is platform-independent, and will take no effect
if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace().
Since the code inside HotSpot is pretty small, we could always leave it
in (compiled unconditionally for both 32-bit and 64-bit) and push the
platform-dependent decision to the JDK layer.
The need for this fix is only for 32-bit VMs, where ASLR would more
easily cause address conflicts with the predefined SharedBaseAddress
(see globals.hpp). On 64-bit VM, mapping failure due to ASLR is very rare.
The fix is based on the idea that a variable defined in the BSS section
of the main executable is not randomized on some platforms:
static char staticSharedSpace[32*1024*1024];
so far, we found this is true only in Linux. (And perhaps Solaris as
well, but since we only supported 64-bit on Solaris, I didn't
On MacOS and Windows, the BSS section of the main executable is also
randomized, so this fix will not reduce mapping failures.
On 5/5/14, 7:59 PM, David Holmes wrote:
> Hi Yumin,
> For something that only addresses one platform this adds a lot of
> platform specific code to a bunch of shared files. Are there plans to
> extend this to other platforms? Otherwise can we make this more
> platform agnostic? Perhaps move the os specific code to the os class?
> Seems the changes in filemap.cpp and metaspace.cpp could easily be
> factored into an os method that returns a boolean to indicate whether
> there is a fixed mapping.
> And perhaps define set_static_shared_space in the os class and always
> expose it via jni.cpp. Actually, why are we exposing this via jni.cpp
> rather than jvm.cpp? This is not part of the JNI interface to the VM.
> On 6/05/2014 9:15 AM, Yumin Qi wrote:
>> Hi, Please have codereview for
>> 8042243: Map shared archive to preallocated static address
>> webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8042243
>> Summary: Mapping shared archive (jsa) some time fail due to ASLR
>> (Address space layout randomization) on 32bit Linux platforms. To solve
>> we come up with mapping shared archive to preallocated static space
>> since with Linux and the GCC compiler, the BSS section in the main
>> executable is not randomized, instead, the variable address in the BSS
>> section is fixed at build time. The tests also showed the extra 32M
>> space will NOT affect java memory setting though it seems 32M virtual
>> address space always allocated no matter it is used or not (If
>> -XX:ShareBaseAddress supply alternative address for dumping, the static
>> address will be ignored.) Note the changes is for 32 bit Linux only.
>> Tests: JPRT, manual test for archive sharing.
More information about the hotspot-runtime-dev