RFR: 8042243: Map shared archive to preallocated static address
Yumin Qi
yumin.qi at oracle.com
Tue May 6 04:46:17 UTC 2014
David,
Thanks for the review.
On 5/5/2014 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.
>
Let me rethink and reorganize the code.
> 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.
I think I can use JVM_LEAF, other entries all call to get current
JavaThread which is not available at the time this function called since
VM is not init'ed. But using this entry is dangerous too.
verify_stack_alignment() will be called in JVM_LEAF_BASE, it won't have
effect since it is empty function for debug version. It may become
problematic in future I think, so i decided to have a plain JNI function
so put it in jni.cpp. This function is more like a private function.
Thanks
Yumin
>
> 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
More information about the core-libs-dev
mailing list