RFR(S) 8243506 SharedBaseAddress is ignored by -Xshare:dump
Ioi Lam
ioi.lam at oracle.com
Fri May 29 00:14:52 UTC 2020
Hi Calvin,
Thanks for the review. I've fixed the problems you pointed out below.
I also rebased the patch on top of Thomas's JDK-8243392: Remodel
CDS/Metaspace storage reservation. I reorganized the validation code of
SharedBaseAddress to check for platform validity and address space
wrap-around.
SharedBaseAddressOption.java is updated to enable WhiteBox which is
required since JDK-8243947.
http://cr.openjdk.java.net/~iklam/jdk15/8243506-SharedBaseAddress-ignored.v02/
http://cr.openjdk.java.net/~iklam/jdk15/8243506-SharedBaseAddress-ignored.v02-delta/
Thanks
- Ioi
On 5/11/20 8:56 PM, Calvin Cheung wrote:
> Hi Ioi,
>
> Just couple of minor comments:
>
> metaspaceShared.cpp:
>
> 336 // We don't want any valid object to be at the very of the archive.
>
> " ... the very of ..." -> "... the very bottom of..." ?
>
> SharedBaseAddressOption.java:
>
> 77 // a top archive specified in the base archive position
> 78 run2(topArchiveName, baseArchiveName,
>
> It looks like the order of the top and base archives are not reversed.
>
> Because the topArchiveName is used for dumpBaseArchive in line 65 and
> the order of the archives specified for dump2 (line 70) are the same
> as above (line 78). So the topArchiveName actually refers to the base
> archive?
>
> thanks,
>
> Calvin
>
> On 5/5/20 11:40 AM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8243506
>> http://cr.openjdk.java.net/~iklam/jdk15/8243506-SharedBaseAddress-ignored.v01/
>>
>>
>> -XX:SharedBaseAddress was essentially ignored due to a bug in
>> JDK-8231610 [1].
>>
>> This fix will enhance both the flexibility and security of CDS.
>>
>>
>> After this fix, -XX:SharedBaseAddress=N will have the following effect:
>>
>> N != 0
>>
>> CDS archive written with a base address of N. If -XX:SharedBaseAddress
>> is not specified, we will use a default address (0x8_00000000 on
>> 64-bit OS).
>>
>> At run time, we will first attempt to map the CDS archive at N. If
>> this
>> fails (the OS doesn't have enough contiguous free space at N), we will
>> map the CDS archive at a suitable location picked by the OS.
>>
>> Specifying a non-default address could be useful:
>> - for diagnosing purposes
>> - if the default address is already occupied for some reason on your
>> environment, but you have another location that's always free.
>>
>> N == 0
>>
>> At run time, the CDS archive will always be mapped to an address
>> selected by the OS.
>>
>> This is useful for improved security -- on OSes that support ASLR
>> (Address
>> Space Layout Randomization), the address of the archived metaspace
>> objects
>> will be randomized on every run to make attacks more difficult.
>>
>>
>> I have added checks to make the code more robust in handling
>> arbitrary values
>> of N. See new tests in
>> cest/hotspot/jtreg/runtime/cds/SharedBaseAddress.java,
>> and MetaspaceShared::initialize_dumptime_shared_and_meta_spaces().
>>
>>
>> Thanks
>> - Ioi
>>
>> ------
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231610
>> Relocate the CDS archive if it cannot be mapped to the requested
>> address
More information about the hotspot-runtime-dev
mailing list