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

[Vladimir Kozlov]

Since it is seen only in debug build it is not urgent. I agree to fix it in 12 update - I approved request.

Thanks,
Vladimir

On 2/28/19 7:14 AM, Langer, Christoph wrote:
> 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
>>>