RFR (S) 8219712: code_size2 is too small on new Skylake CPUs

[Langer, Christoph]

Hi,

I've pushed Ralf's fix today after running it through the submit repo.

As it seems to relate to JDK-8214074 (Optimize Ghash using AVX instructions) and this one is in jdk12, I guess it is quite urgent to bring this fix to jdk12 as well. We see the assertion in debug builds. And in the opt builds, I guess the memory would potentially be overwritten. How would you assess the urgency?

Best regards
Christoph

> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> David Holmes
> Sent: Dienstag, 26. Februar 2019 22:33
> To: Schmelter, Ralf <ralf.schmelter at sap.com>; HotSpot Open Source
> Developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs
> 
> Hi Ralf,
> 
> webrev.1 looks good.
> 
> Thanks,
> David
> 
> On 27/02/2019 1:50 am, Schmelter, Ralf wrote:
> > Hi David,
> >
> >> I agree with Matthias: can this be a DEBUG_ONLY change?
> >
> > code_size2 is the size of the BufferBlob which is allocated to contain the
> "stub routines 2" created by StubGenerator. And in the debug build we
> check via assertions, that we don't overwrite the buffer. In the optimized
> version, we would later just overwrite part of the stub routines. So making it
> DEBUG_ONLY defeats the purpose of the change.
> >
> >> Further is the problem with 32-bit and 64-bit or only 64-bit? Your
> > change affects 32-bit.
> >
> > Since I only build the 64bit VM, I've changed the webrev:
> http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/
> > It should now only increase the 64 bit version.
> >
> > In the end, it would be nice if the initial BufferBlob size could be more
> generous and then later adjusted to the really needed space, since it is really
> not easy to get a tight upper bound reliably, with it being dependent on the
> OS, GC, CPU features and other flags.
> >
> > Best regards,
> > Ralf
> >