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

[Thomas Stüfe]

On Tue 5. May 2020 at 21:45, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:

> Hi Ioi,
>
> thanks for fixing this!
>
> Not a full review yet, just a remark inline.
>
>
> On Tue, May 5, 2020 at 8:42 PM Ioi Lam <ioi.lam at oracle.com> 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).
>>
>
> Good!
>
>
>>
>>    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.
>>
>>
> Why would someone need this at runtime?
>
>
>>    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.
>>
>>
> But if the default address is taken the OS (or the platform layer in the
> VM, see the aarch64 code) will choose a proper placement for the CDS+class
> space. What could be gained from manually interfering with that process? We
> already have to pay the relocation costs, so we gain nothing performance
> wise.
>
> The problem I have with honoring SharedBaseAddress at runtime is twofold:
> - it increases the complexity of the reservation. One more configuration
> option to test.
> - it gives the user ample opportunity to shoot himself in the foot.
> Examples:
>   -> User specifies an address which puts CDS/class space in the way of
> the sbrk, on platforms where that matters. You may get malloc OOMs out of
> the blue. The platform code is aware of this and usually deals with it.
>   -> You bypass the optimal cds placement done by the platform and either
> specify a base address which does not work at all or which does not allow
> the best CompressedKlassPointer encoding possible on the platform. See also
> the discussions about better CompressedKlassPointer encoding on
> aarch64-dev, and we may do something similar on ppc.
>   -> More subtle: a user who misinterprets the option may specify it
> always. I bet you this option finds its way as "optimization technique"
> into any number of blogs :) but by specifying it at runtime you always pay
> for the relocation cost. Even if the primary address baked into the archive
> were free and would work just fine.
>
> I think if the user wants a different placement for cds+class space, he
> should regenerate the archives anew.
>
> 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.
>>
>>
> is this any different from -XX:ArchiveRelocationMode=0 ?
>
>

I meant = 1, sorry.


>> 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
>>
>
> Thank you!
>
> ..Thomas
>