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

Wed May 6 08:51:12 UTC 2020

On Wed, May 6, 2020 at 10:14 AM Ioi Lam <ioi.lam at oracle.com> wrote:

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

Are you sure? Are you talking about what your patch does or what already
happens in jdk-head? In jdk-head I see the archive at run time always
mapped to 0x800000000, regardless of what the SharedBaseAddress I gave at
dump time. At dump time I see we reserve the dump space at
SharedBaseAddress, but then we relocate to default base before writing the
dump, no?

(Btw, is there a way to display the header information in a jsa? I
tried  -XX:+PrintSharedArchiveAndExit but this did not produce much info.)

>
> 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.
>
>
Ah, I see. This may be useful.

Cheers, Thomas

> Thanks
> - Ioi
>
>
>
>
>
>
>
>
>