RFR: 8042243: Map shared archive to preallocated static address

[Ioi Lam]

All we need is to store two variables (base and size) and use them if 
the define a suitable range. So the code is completely platform agnostic.

We found this useful for Linux only for the standard JDK platforms, but 
maybe when people port to other platforms they would find this useful as 
well?

Thanks
- Ioi


On 5/7/14, 2:55 AM, David Holmes wrote:
> 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
>>