JDK-8193518 : C2: Vector registers sometimes corrupted at safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-12-14
  • Updated: 2020-08-06
  • Resolved: 2017-12-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 11
10 b37Fixed 11Fixed
Related Reports
Relates :  
Description
The logic that computes Compile::_max_vector_size actually only keeps the max vector size of the last loop processed by loop optimizations. A method with multiple loops, the last of which uses shorter vectors than the others, can then be registered as not requiring vectors to be saved on a safepoint which causes corruptions of the vector registers.
Comments
I've just noticed that the test was never pushed. I'll add it to my fix for JDK-8249608.
06-08-2020

I will sponsor it.
15-12-2017

The results for webrev.01 look good (not yet fully finished though). [~neliasso], could you please take care of sponsoring? I'm on vacation now.
15-12-2017

The new TestVectorsNotSavedAtSafepoint.java fails on all platforms with "java.lang.OutOfMemoryError: Java heap space". I think this is due to the GarbageProducerThread allocating thousands of Objects: java.lang.OutOfMemoryError: Java heap space at TestVectorsNotSavedAtSafepoint$GarbageProducerThread.run(TestVectorsNotSavedAtSafepoint.java:54)
15-12-2017

http://cr.openjdk.java.net/~roland/8193518/webrev.00/
15-12-2017

ILW = Incorrect execution due to corrupted vector registers, reproducible but rare, disable vectorization = HMM = P2
14-12-2017