[15] RFR (L): 7175279: Don't use x87 FPU on x86-64

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Dec 19 18:34:25 UTC 2019


On 12/19/19 10:15 AM, Vladimir Ivanov wrote:
> Thanks for the feedback, Vladimir.
> 
>> c1_CodeStubs.hpp - I think it should be stronger than assert to catch it in product too (we can do check in product 
>> because it is not performance critical code).
> 
> Do you prefer to see guarantee/fatal instead?
> 
> Frankly speaking, even the assert doesn't look warranted enough.
> I put it there mainly to validate my own changes. I could have introduced ConversionStubs for x86-64 as well, but 
> decided to simplify the implementation.
> 
> Considering x86-32 is the only consumer, I'd prefer to have ConversionStub x86_32-specific instead and completely hide 
> it from other platforms, but it requires putting more #ifdefs in shared code which I don't like either.
> 
> So, if you see a value in having a runtime check in product binaries there, I'll put it there.

Make ConversionStub x86_32-specific only if possible. From what I see it is only LIR_OpConvert in c1_LIR.hpp we have to 
deal with. I actually can't see how it could be only 32-specific. Hmm?

Vladimir K

> 
>> c1_LinearScan.cpp - I think IA64 is used for Itanium. For 64-bit x86 we use AMD64:
>>
>> https://hg.openjdk.java.net/jdk/jdk/file/cfaa2457a60a/src/hotspot/share/utilities/macros.hpp#l456 
> 
> Yes, you are right. Good catch! :-)
> 
> Best regards,
> Vladimir Ivanov
> 
>> On 12/17/19 4:50 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/7175279/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-7175279
>>>
>>> There was a major rewrite of math intrinsics which in 9 time frame which almost completely eliminated x87 code in 
>>> x86-64 code base.
>>>
>>> Proposed patch removes the rest and makes x86-64 code x87-free.
>>>
>>> The main motivation for the patch is to completely eliminate non-strictfp behaving code in order to prepare the JVM 
>>> for JEP 306 [1] and related enhancements [2].
>>>
>>> Most of the changes are in C1, but there is one case in template interpreter (java_lang_math_abs) which now uses 
>>> StubRoutines::x86::double_sign_mask(). It forces its initialization to be moved to StubRoutines::initialize1().
>>>
>>> x87 instructions are made available only on x86-32.
>>>
>>> C1 changes involve removing FPU support on x86-64 and effectively make x86-specific support in linear scan allocator 
>>> [2] x86-32-only.
>>>
>>> Testing: tier1-6, build on x86-23, linux-aarch64, linux-arm32.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8175916
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8136414
>>>
>>> [3] http://hg.openjdk.java.net/jdk/jdk/file/ff7cd49f2aef/src/hotspot/cpu/x86/c1_LinearScan_x86.cpp


More information about the hotspot-runtime-dev mailing list