RFR(S) 8243506 SharedBaseAddress is ignored by -Xshare:dump

Calvin Cheung calvin.cheung at oracle.com
Mon Jun 1 18:05:15 UTC 2020


Hi Ioi,

The updated webrev (including .v03-delta) looks good to me.

thanks,

Calvin

On 5/28/20 5:14 PM, Ioi Lam wrote:
> 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