RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947
david.holmes at oracle.com
Thu Dec 14 02:52:17 UTC 2017
On 14/12/2017 12:05 PM, Xueming Shen wrote:
> David, Martin,
> webrev has been updated to fix the test directly.
That seems to me to be invalidating the whole point of the test, which
was a regression test for 6896617 to check that the optimizations put in
place actually get applied. ??
But I'll leave that up to the compiler guys to decide.
> Assume I would need hotspot guys' help to review and push into hs repo?
You'll need to fix in both jdk/hs and jdk/jdk as the breakage is now in
both. Fix one and import to the other.
But I still suggest adding the test to ProblemList.txt now so that this
isn't broken in JDK 10 fork, then fix the actual test at a more
leisurely pace in jdk/hs.
But again I'll defer to compiler folk.
> On 12/13/17, 4:52 PM, Martin Buchholz wrote:
>> It would add more confusion to a something that's already difficult to
>> understand. It's OK as a temporary measure, but I don't think we want
>> product code just to enable tests in hotspot. Can the hotspot folks
>> modify their test, perhaps making this code part of the test?
>> On Wed, Dec 13, 2017 at 4:01 PM, Xueming Shen <xueming.shen at oracle.com
>> <mailto:xueming.shen at oracle.com>> wrote:
>> Please help review the change for JDK-8193479
>> issue: https://bugs.openjdk.java.net/browse/JDK-8193479
>> webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev
>> The internal interface ArrayEn/Decoder for ISO8859_1 has been removed
>> because it is no longer used by StringCoding class, but it appears
>> it is
>> being used by hotspot Test6896617.java to verify the SSE instructions
>> on x86. The proposed change here is to simply restore the internal
>> ArrayEn/Decoder for ISO8859_1 to avoid blocking hotspot testing
>> for now.
More information about the core-libs-dev