RFR: 8042243: Map shared archive to preallocated static address

[David Holmes]

Hi Ioi,

Thanks for the background. I understand this only applies to Linux but 
that is the reason it should be confined to Linux-specific files as much 
as possible. This wouldn't be the first time we introduced an os method 
that only had a non-trivial implementation on one platform.

Thanks,
David

On 7/05/2014 4:14 AM, Ioi Lam wrote:
> 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
>