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

[Thomas Stüfe]

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 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