Hotspot crash compiling sun.invoke.util.ValueConversions::identity (original) (raw)

Eirik Bjørsnøs eirbjo at gmail.com
Mon Mar 2 15:16:51 UTC 2015

Vladimir,

I have an hs_err file ready with a corresponding core dump file (176MB).

I'll zip these up and send a download link to you off-list.

Let me know if there is a better way to manage these files. Should we have a Jira issue to track progress?

Thanks, Eirik.

On Mon, Mar 2, 2015 at 4:01 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

Eirik,

Thanks for the report! As a first step, I'd like to see corresponding hotspot crash log (hserrpid*.log). It seems you stepped on a bug in invokedynamic implementation (lambdas are translated into indy calls on bytecode level) which happens when it is initialized too early in VM lifecycle (e.g. java agent premain). I'd be grateful for a stand-alone test case (focus on premain method logic) or steps how to reproduce it myself. Best regards, Vladimir Ivanov On 3/2/15 4:10 AM, Eirik Bjørsnøs wrote:

Ladies and gentlemen, Last week, some of the world's brightest, most capable and all round good looking Java developers gathered in Crested Butte, Colorado for the Winter Tech Forum (WTF) 2015 [1]. Wednesday was Hackathon Day, and a group of us decided to embark the adventure of creating a live Java code coverage engine called Skybar [2]. We made good progress and by the afternoon we knew we'd have something good to show at the 8pm showcase. So we confidently headed over to Ryce Asian Bistro [3] at 17:30 for a nice team dinner. Luckily we went easy on the saké, because when we came back to finalise our demo, we found that Hotspot had crashed: # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x000000012a6d61e6, pid=10738, tid=18691 [..] Compiled method (c2) 152453 1542 4 sun.invoke.util.ValueConversions::identity (2 bytes) Shock, horror! Our demo was just minutes away, would we be able to present? Our team immediately went into debugging mode: Could we reproduce without using our -javaagent? No. Was the crash consistently reproducible? Kind of, but we had to stress test our code. Was there a any consistency in the hserr reports? Yes, it seemed to always involve lambda expressions in out agent code. The team decided we had to remove all lambdas from our agent code in the hope that would improve the situation. And it did! At 7:50 PM, we had a stable build and ran out to make it to the presentations. Skybar was very well received. Our demo worked. Nothing crashed. Applause and shouts of "Ship it!" was heard from the audience. It was good times. We headed over to the Princess Wine Bar [4] for some celebratory drinks. The team is continuing our work on Skybar. But we miss our lamdas, and we want them back! To achieve this, we need help from the Hotspot team. On our side, we are willing to work with you try to make reproducible test cases and collect any other useful information. What would be the best next step in saving Lambas on Agents? We would love to help out fixing this. Should we file an issue somewhere and upload our hserr file(s)? On behalf of the Skybar team - Eirik, [1] http://www.mindviewinc.com/Conferences/JavaPosseRoundup/ [2] https://github.com/WinterTechForum/skybar [3] http://www.ryceasianbistro.com [4] https://www.facebook.com/princesswinebar

More information about the hotspot-compiler-dev mailing list