RFR: 8224974: Implement JEP 352

[Andrew Dinn]

On 31/07/2019 12:40, Aleksey Shipilev wrote:
> On 7/31/19 1:29 PM, Andrew Dinn wrote:
>> I have an update regarding the change to the computation of the
>> CPU_FLUSH flag. After posting the new webrev I built a debug version
>> with the change that tests the clflush bit on x86_64. It crashed when
>> the assert is reached in VM_Version::supports_cpuflush:
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (src/hotspot/cpu/x86/vm_version_x86.hpp:978),
>> pid=29597, tid=29602
>> #  assert((_features & ((uint64_t)(0x20000000000ULL))) != 0) failed:
>> clflush should be available
>>
>> So, it seems the clflush bit is not set on my x86_64 box even though I
>> am able to execute clflush quite happily.
>>
>>   "Toto, it looks like we are no longer in Antarctica."
>>
>> So, I will revert this change (in the next webrev).
> 
> But wait, that might mean the clflush is indeed not available, by either hardware or software
> switch? I believe some security mitigations disable clflush. Linux kernel, for example, has
> "noclflush" option to do this. Ignoring the cpu bit and emitting clflush anyway might circumvent
> that mitigation then?
Ok, so investigating further I have found out what is wrong here.
Significanlty, I get this result when I look at /proc/cpuinfo.

[root at localhost ~]# cat /proc/cpuinfo | grep flush | head -1
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 *clflush* dts acpi mmx fxsr sse sse2 ...

So, the  hardware does flag support for clflush. In which case why does
the assert in supports_clflush fail?

Well, the failure happened during the build process so I didn't
(couldn't) debug it. I disabled the assert in supports_cpuflush() in
order to allow the build to complete and then ran up the resulting JVM
inside gdb to check what was going on. The problem is that with my patch
supports_cpuflush() is called from Assembler::clflush() and the latter
is called from icache_x86.cpp very early during bootstrap (I think this
is neded to flush the flush routine used to flush the code cache).
Anyway, the call happens so early that it precedes the call to
VM_Version::get_processor_features which sets up the _features mask
tested by the assert.

So, I think the only option is to remove the assert from the x86_64
version of supports_cpuflush from Assemmbler::cpu_flush and instead add
an assert in get_processor_features that CPU_FLUSH is set on x86_64.
However, by that stage on x86_64 we will already have called clflush
and, in the case where the assert might actually fail, we may not reach
there because we have tripped up with an illegal instruction error.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander