RFR(S) 8243506 SharedBaseAddress is ignored by -Xshare:dump
Ioi Lam
ioi.lam at oracle.com
Wed May 6 16:55:58 UTC 2020
On 5/6/20 1:51 AM, Thomas Stüfe wrote:
>
>
> On Wed, May 6, 2020 at 10:14 AM Ioi Lam <ioi.lam at oracle.com
> <mailto: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?
Hi Thomas,
The current JDK-head behavior is, during -Xshare:dump:
1. Allocate shared space at SharedBaseAddress specified by user (or
0x800000000 if unspecified)
2. If #1 fails, allocate shared space at an OS-picked address
3. Relocate archive to 0x800000000, then write to disk
The new behavior with my patch is the same with #1 and #2, but:
3. If #1 fails, relocate archive to SharedBaseAddress, and then write to
disk.
>
> (Btw, is there a way to display the header information in a jsa? I
> tried -XX:+PrintSharedArchiveAndExit but this did not produce much info.)
You can kind of get more info like this, but I filed
https://bugs.openjdk.java.net/browse/JDK-8244540
$ java -XX:+PrintSharedArchiveAndExit -Xlog:cds*=debug
[0.002s][info][class,path] opened: /jdk2/bld/jem/images/jdk/lib/modules
[0.007s][info][cds ] Archive was created with UseCompressedOops =
1, UseCompressedClassPointers = 1
[0.007s][debug][cds ] Reserved archive_space_rs
[0x0000000900000000 - 0x0000000900b31000] (11735040) bytes
[0.007s][debug][cds ] Reserved class_space_rs [0x0000000900b31000
- 0x0000000940b31000] (1073741824) bytes
[0.007s][info ][cds ] Mapped static region #0 at base
0x0000000900000000 top 0x0000000900003000 (MiscCode)
[0.007s][info ][cds ] Mapped static region #1 at base
0x0000000900003000 top 0x00000009003e5000 (ReadWrite)
[0.007s][info ][cds ] Mapped static region #2 at base
0x00000009003e5000 top 0x0000000900b31000 (ReadOnly)
[0.007s][info ][class,path] Expecting BOOT
path=/jdk2/bld/jem/images/jdk/lib/modules
[0.007s][info ][class,path] Expecting -Djava.class.path=
[0.007s][info ][class,path] checking shared classpath entry:
/jdk2/bld/jem/images/jdk/lib/modules
[0.007s][info ][class,path] ok
[0.007s][info ][cds ] CDS archive was created with max heap size =
16096M, and the following configuration:
[0.007s][info ][cds ] narrow_klass_base = 0x0000000900000000,
narrow_klass_shift = 3
[0.007s][info ][cds ] narrow_oop_mode = 1, narrow_oop_base =
0x0000000000000000, narrow_oop_shift = 3
[0.007s][info ][cds ] The current max heap size = 16096M,
HeapRegion::GrainBytes = 8388608
[0.007s][info ][cds ] narrow_klass_base = 0x0000000900000000,
narrow_klass_shift = 3
[0.007s][info ][cds ] narrow_oop_mode = 1, narrow_oop_base =
0x0000000000000000, narrow_oop_shift = 3
[0.007s][info ][cds ] CDS heap data relocation delta = 0 bytes
[0.007s][info ][cds ] Trying to map heap data: region[4] at
0x00000007bf800000, size = 507904 bytes
[0.007s][info ][gc,cds ] Mark closed archive regions in map:
[0x00000007bf800000, 0x00000007bf87bff8]
[0.007s][info ][cds ] Trying to map heap data: region[6] at
0x00000007bf000000, size = 335872 bytes
[0.007s][info ][gc,cds ] Mark open archive regions in map:
[0x00000007bf000000, 0x00000007bf051ff8]
[0.007s][debug][cds,vtables] Copying 14 vtable entries for ConstantPool
[0.007s][debug][cds,vtables] Copying 40 vtable entries for InstanceKlass
[0.007s][debug][cds,vtables] Copying 40 vtable entries for
InstanceClassLoaderKlass
[0.007s][debug][cds,vtables] Copying 40 vtable entries for
InstanceMirrorKlass
[0.007s][debug][cds,vtables] Copying 40 vtable entries for InstanceRefKlass
[0.007s][debug][cds,vtables] Copying 14 vtable entries for Method
[0.007s][debug][cds,vtables] Copying 41 vtable entries for ObjArrayKlass
[0.007s][debug][cds,vtables] Copying 41 vtable entries for TypeArrayKlass
archive is valid
Thanks
- Ioi
>
> 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
>
>
>
>
>
>
>
>
More information about the hotspot-runtime-dev
mailing list