RFR(xxxs): 8245707: Increase Metaspace reserve alignment

Thomas Stüfe thomas.stuefe at gmail.com
Wed May 27 05:42:28 UTC 2020


Hi Ioi,

On Wed, May 27, 2020 at 7:04 AM Ioi Lam <ioi.lam at oracle.com> wrote:

> Hi Thomas,
>
> If (UseLargePages && UseLargePagesInMetaspace) is true, then
> _reserve_alignment will be 4*os::large_page_size(). Is this what you want?
>
>
No :) That is why I limited this to cases where the page size is 4K.

However I see that on Windows this would still land us at 4*allocation
granularity instead, so 256K. I'll change that.


> Or, do you want to do the *4 only when large page is not used?
>
>
Only if page size is 4K. The reason is that I want to trip over
anyone asserting and calculating alignment (eg. CDS) but not trigger any
tests which do test things like memory counters - on some of our platforms
we have 64K and I don't want to adjust a bunch of tests.


> Why did you choose *4? Would *2 also accomplish what you want?
>
>
*2 would also be acceptable. I'll post an update.

Thanks! ..Thomas


> Thanks
> - Ioi
>
> On 5/25/20 10:57 PM, Thomas Stüfe wrote:
> > Hi all,
> >
> > may I have reviews for this tiny change:
> >
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8245707
> > webrev:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8245707-increase-metaspace-reserve-alignment/webrev.00/webrev/
> >
> > One of the motivations behind JDK-8243392 was to decouple CDS reservation
> > alignment from metaspace alignment and prevent misuse of metaspace
> reserve
> > alignment outside metaspace. This is needed since with the upcoming new
> > metaspace (JDK-8221173) its reserve alignment requirement will be much
> > higher than CDS alignment.
> >
> > For the time being, until JDK-8221173 finds its way into jdk mainline, we
> > should increase metaspace reserve alignment in jdk mainline to trigger
> any
> > remaining illegal uses of metaspace reserve alignments and to prevent new
> > ones from creeping in.
> >
> > All CI tests at SAP went through successfully, so at the moment we seem
> to
> > be clean.
> >
> > Thanks, Thomas
>
>


More information about the hotspot-runtime-dev mailing list