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

[Ioi Lam]

On 5/5/20 10:58 PM, Thomas Stüfe wrote:
> Hi Ioi,
>
> <snip>
>
>>
>
>     Hi Thomas,
>
>     Actually, the placement chosen by the OS under this circumstance
>     may not be "proper".
>
>     Let me first start explain why currently we always write the
>     archive at 0x800000000.
>
>     (The bug description should be more clear -- it's not a bug to
>     always write to 0x800000000. That was intentional. The bug is now
>     there's no way to specify an address other than 0x800000000 --
>     unless you edit globals.hpp and rebuild the JDK).
>
>     During JDK-8231610 (Relocate the CDS archive if it cannot be
>     mapped to the requested), my biggest concern was this:
>
>     When we build an official release build on Linux, perhaps once in
>     a blue moon 0x800000000 is unavailable. But do we want to ship an
>     official JDK  with a default CDS archive whose base address
>     happened to be picked randomly on the specific host that built the
>     JDK? We have never tested against such an address. It's not a
>     "proper" address as we don't know whether it will even work on the
>     huge variety of hosts used by our users. So this is a black swan
>     event -- it mostly likely won't happen, but it might. If it does
>     happen, it has unknown negative impact (e.g., the default CDS
>     archive may not work in half of the machines in the world). How do
>     we handle it?
>
>     We have tested with 0x800000000 millions of times, and it has
>     worked for many JDK releases, so it seems safer to always release
>     a JDK that uses this base address.
>
>     We could detect the black swan event during the JDK build, and
>     regenerate the archive until we get 0x800000000. But if the chance
>     of this happening is very low, how do we test our Makefile logic,
>     and what if the build keeps spinning and never gives us 0x800000000?
>
>     So, the decision in JDK-8231610 was to always relocate the archive
>     to 0x800000000 before writing it. (We test this functionality with
>     "-Xshare:dump -XX:ArchiveRelocationMode=1" in our regression
>     tests). This ensures that the black swan event never happens
>     during the JDK build.
>
>
> Oh, I see. This is a valid concern.
>
>     ===============
>
>     I agree that your concerns below are valid. The question is -- do
>     we need to provide a method to specify an address different than
>     0x800000000?
>
>     If the answer is unclear, I think we can shelf this fix until
>     someone actually complains :-)
>
>
> Sorry, that was not my intention. I still think the part of your patch 
> which processes SharedBaseAddress at dump time is valuable. And then 
> you could run the official builds always 
> with SharedBaseAddress=0x800000000, right? I was only debating its use 
> at runtime.
>
> I also had a more close look at the patch and I do not think it 
> conflicts that much with the cds reservation rework, especially if we 
> leave the runtime part out.
>

Sorry I wasn't clear: -XX:SharedBaseAddress takes effect only when 
dumping the base archive with -Xshare:dump. In all other cases, the 
value specified in the command-line is ignored. E.g.:

$ java -XX:SharedBaseAddress=0x900000000 -Xshare:dump
$ java -XX:SharedBaseAddress=0xa00000000 -Xshare:on -Xlog:cds=debug -version
<....>
[0.006s][info ][cds] Mapped static  region #0 at base 0x0000000900000000 
top 0x0000000900003000 (MiscCode)
[0.006s][info ][cds] Mapped static  region #1 at base 0x0000000900003000 
top 0x00000009003e5000 (ReadWrite)
[0.006s][info ][cds] Mapped static  region #2 at base 0x00000009003e5000 
top 0x0000000900b31000 (ReadOnly)
<....>

At run-time, the archive is mapped to 0x900000000, i.e., the value 
specified at dump time.

Similarly, when dumping the dynamic archive, the -XX:SharedBaseAddress 
in the command-line is ignored. The dynamic archive will always use the 
same base address as the static archive.

$ java -XX:SharedBaseAddress=0x12345678 -XX:ArchiveClassesAtExit=foo.jsa 
-Xlog:cds=debug com.sun.tools.javac.Main
<....>
[0.381s][debug  ][cds] Shared file region (mc )  0:   101736 bytes, addr 
0x0000000900b31000 file offset 0x00001000 crc 0x35d9ce44
[0.383s][debug  ][cds] Shared file region (rw )  1:  1165992 bytes, addr 
0x0000000900b4a000 file offset 0x0001a000 crc 0xb21138a0
[0.385s][debug  ][cds] Shared file region (ro )  2:  1806840 bytes, addr 
0x0000000900c67000 file offset 0x00137000 crc 0xf9b26f24
[0.386s][debug  ][cds] Shared file region (bm )  3:    48072 bytes, addr 
0x0000000000000000 file offset 0x002f1000 crc 0xb6f25c5e

> <snip>
>
>>         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=1 ?     
>>     [edited]
>
>     In practice there's not much difference, except that
>     ArchiveRelocationMode is a diagnostic flag.
>

Actually,  ArchiveRelocationMode is an option for the run time, so if 
you want the random address mapping, you have to remember to use it 
every time you launch a VM.

In contrast, if you build an archive with -XX:SharedBaseAddress=0 at 
dump time, then at run-time, this archive will always map to an random 
address without specifying any extra VM flags. So this makes things more 
manageable.

Thanks
- Ioi