C2 compiler bug closed as incomplete
Julien Nicoulaud
julien.nicoulaud at gmail.com
Thu Jun 5 12:20:11 UTC 2014
Hi,
The bug is still present on 8u20 b17.
I managed to reproduce it on 8u20 b17 fastdebug with TracePartialPeeling
on, the logs are here:
https://dl.dropboxusercontent.com/u/62997/JDK-8038985/8u20-b17.zip
Regards,
Julien
2014-06-05 1:55 GMT+02:00 Vladimir Kozlov <vladimir.kozlov at oracle.com>:
> Hi Julien,
>
> Thank you for additional information. I added it to 8038985 bug report.
> So it look likes something went wrong in loop opts.
> I pointed in the bug report that it could be related to 8039050. It was
> fixed in jdk8u20 b12. I see that you tested 8u20 b05. Can you download and
> test latest 8u20 b17?
>
> Also, if you know how to build Hotspot JVM yourself, you can 'hg clone'
> latest sources from http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/ and
> build 'fastdebug' JVM. It has a lot of asserts which will help identify the
> problem. Just replace libjvm.so in jdk/jre/lib/amd64/server.
>
> Regards,
> Vladimir
>
>
> On 6/4/14 2:34 AM, Julien Nicoulaud wrote:
>
>> Hi,
>>
>> Here are some more tests as asked on the JIRA issue:
>> -XX:-PartialPeelLoop : no crash
>> -XX:-LoopUnswitching : still crashes
>> -XX:-SplitIfBlocks : still crashes
>> -XX:LoopUnrollLimit=0 : no crash
>> -XX:-RangeCheckElimination : still crashes
>>
>> => so it looks like PartialPeelLoop is the cause of the crash.
>>
>> I also tried these tests:
>> -XX:-PartialPeelAtUnsignedTests : no crash
>> -XX:+TracePartialPeeling : no crash
>> -XX:-BackgroundCompilation : no crash
>> -XX:+TracePartialPeeling -XX:CICompilerCount=8 : no crash
>>
>> It looks like a concurrency issue in PartialPeelLoop, but I can't find a
>> way to reproduce it when logging is on.
>>
>> Regards,
>> Julien
>>
>>
>> 2014-04-11 11:39 GMT+02:00 Julien Nicoulaud <julien.nicoulaud at gmail.com
>> <mailto:julien.nicoulaud at gmail.com>>:
>>
>>
>> Hi all, thanks for your answers.
>>
>> I did some further testing and here is the results:
>> - JDK 8u20-b05 : still crashes, but not always - logs at
>> https://dl.dropboxusercontent.com/u/62997/JDK-8038985/8u20-b05.zip -
>> core dump at
>> https://dl.dropboxusercontent.com/u/62997/JDK-8038985/8u20-
>> b05/core.16369.tar.bz2
>> - JDK 8u0 with -XX:-EliminateAutoBox : still crashes, but not
>> always - logs at
>> https://dl.dropboxusercontent.com/u/62997/JDK-8038985/8u0-
>> no-EliminateAutoBox.zip
>>
>> Also, since the crash always seems to occur when inlining Trove's
>> TCustomHashMap (http://trove.starlight-systems.com/) into my code, I
>> tried to:
>> - Upgrade Trove from 3.0.3 to 3.1a1 (from
>> https://bitbucket.org/robeden/trove/downloads) => still crashes
>> - Replace Trove by other hash map implementations => no crash
>>
>> Regards,
>> Julien
>>
>>
>> 2014-04-07 22:04 GMT+02:00 Christian Thalinger
>> <christian.thalinger at oracle.com
>> <mailto:christian.thalinger at oracle.com>>:
>>
>>
>>
>> On Apr 7, 2014, at 2:39 AM, Volker Simonis
>> <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>> wrote:
>>
>> > Really seems like a duplicate of
>> > https://bugs.openjdk.java.net/browse/JDK-8032566 "8032566:
>> Crash in
>> > JIT when running Scala compiler (and compiling Scala std lib)"
>> > although that one should have been fixed in jdk8 b127. On the
>> other
>> > hand it was not really fixed - just worked around by switched
>> off
>> > autoboxing by default (you can double check with
>> > -XX:-EliminateAutoBox).
>> >
>> > Maybe the problem also appears even with autoboxing switched
>> off?
>> >
>> > By the way, JIT replay data doesn't help without access to
>> the involved classes.
>>
>> Right. We would need the classes extracted from the core file.
>> Also I’ve moved the replay and hs_err data into files and
>> attached them to the bug report because the bug was unreadable
>> before.
>>
>> >
>> > Regards,
>> > Volker
>> >
>> >
>> >
>> > On Sun, Apr 6, 2014 at 8:55 AM, Ivan Krylov
>> <ivan at azulsystems.com <mailto:ivan at azulsystems.com>> wrote:
>> >> bcc: discuss at openjdk.java.net <mailto:discuss at openjdk.java.
>> net>
>> >> cc: hotspot-compiler-dev at openjdk.java.net
>> <mailto:hotspot-compiler-dev at openjdk.java.net>
>>
>> >>
>> >>
>> >> Hi Julien,
>> >>
>> >> Hotspot-compiler-dev is the right alias from discussing C2
>> crashes. In the meantime may you can try the current the latest
>> EA build like 8u20 b05 [1]?
>> >>
>> >> Thanks,
>> >>
>> >> Ivan
>> >>
>> >> [1] - https://jdk8.java.net/download.html
>> >>
>> >> On 05 Apr 2014, at 13:57 , Julien Nicoulaud
>> <julien.nicoulaud at gmail.com <mailto:julien.nicoulaud at gmail.com>>
>>
>> wrote:
>> >>
>> >>> Hi all,
>> >>>
>> >>> I don't know if it's the right place to discuss this, but
>> here is my issue :
>> >>>
>> >>> I reported a VM crash in C2 compilation, but it was closed
>> as incomplete
>> >>> with the following comment "We need a clear instructions
>> how to reproduce
>> >>> the problem".
>> >>>
>> >>> I clearly explained in the report I could not provide a
>> simple,
>> >>> self-contained test case to reproduce the bug, and I
>> provided hs_err and
>> >>> JIT replay log file instead.
>> >>>
>> >>> So what am I supposed to do in this case ? Debug it myself
>> ? Or are there
>> >>> another options so I can provide useful debug output ?
>> >>>
>> >>> Here is the bug report:
>> >>> https://bugs.openjdk.java.net/browse/JDK-8038985
>> >>> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8038985
>> >>>
>> >>> Regards,
>> >>> Julien Nicoulaud
>> >>>
>> >>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140605/75ba5d87/attachment.html>
More information about the hotspot-compiler-dev
mailing list