RFR: 8042243: Map shared archive to preallocated static address

[Ioi Lam]

So backgrounds:

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 
investigate further).

On MacOS and Windows, the BSS section of the main executable is also 
randomized, so this fix will not reduce mapping failures.

- Ioi

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.
>
> Thanks,
> David
>
> 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.
>>
>> Thanks
>> Yumin