CDS, replace ArchiveRelocationMode?

Thomas Stüfe thomas.stuefe at gmail.com
Wed Nov 3 05:34:04 UTC 2021


Hi Ioi,

all valid points.

- "how would we place the blocker reservations if we don't know the
addresses beforehand": you are right in that a total random placement may
not be sufficient. Could be done for a different class of tests, simulating
densely populated address spaces. But too random for targeted CDS tests.
I'd say one would need to place the blocker reservations inside the ranges
we know we want to block, and that only works once we know those addresses.
E.g. when we have read the target base address from the archive. This could
also be used to place a blocker reservation in the mids of the archive
mapping process. But at some point, you don't win much in terms of code
complexity compared to today's solution. Though I'd argue it would still be
better than explicitly faking mapping errors, since you really test the
same code paths as the real mapping error.

- Forcing ASLR for CDS is an interesting point. Never occurred to me. And
yes, it would be ridiculous to use blocker reservations for that. You pay
for one reservation you already know will fail (but don't we do this now
too?). It would be better IMHO to separate these two concerns - testing and
ASLRing the CDS - and making the latter explicit with a public switch.

All these are just idle thoughts since I was looking at the reservation
code yesterday. Nothing I plan to do right away. Or maybe at all.

Thanks for your time!

..Thomas





On Tue, Nov 2, 2021 at 4:54 PM Ioi Lam <ioi.lam at oracle.com> wrote:

> I wonder how this will impact the tests. ArchiveRelocationMode is very
> easy to use in the tests. For "scattershot_into_range(address, len)", I
> image it will require the knowledge of where to do the "inconvenient
> reservation". Will that need to be handled by the test cases, or by some
> code inside the VM?
>
> Also, currently in debug builds, ArchiveRelocationMode makes it possible
> to map every region of the archive, and then pretend something fails at
> the end. This will trigger the clean up of all the mapped regions
> (including the very last mapped region. This may not be possible with
> "scattershot_into_range(address, len)".
>
> Plus, ArchiveRelocationMode can be used in product build (albeit a
> diagnostic option) to force relocation. So it can be used by people who
> prefer to always ASLR the CDS archive. It would be unnatural if this
> needs to be accomplished with an "inconvenient reservation".
>
> Thanks
> - Ioi
>
> On 11/2/21 8:36 AM, Thomas Stüfe wrote:
> > Hi,
> >
> > A small idea. I wonder whether we could reduce the complexity of CDS
> > reservation a bit and at the same time make testing more realistic by
> > replacing ArchiveRelocationMode with a test switch that, prior to any
> > initialization, populates the address space with "inconvenient"
> > reservations. Either targeted to some predefined areas or scattershot for
> > random tests.
> >
> > A function like "scattershot_into_range(address, len)" could be called
> even
> > between reserving the whole range and mapping the individual ranges, to
> > mimic reservation failures where "oops someone was faster than you".
> >
> > Such a feature could be reused in a number of places, and we could remove
> > the ArchiveRelocationMode switch and its handling. What do you think?
> >
> > Cheers, Thomas
>
>


More information about the hotspot-runtime-dev mailing list