Agreed, and furthermore our code is definitely not doing any weaving or reflection skullduggery that could break that "final".
No, no special GC options. Except being launched via JNI, I believe it's a pretty straightforward JVM argument list: just classpath and a handful of "-D" options. But I should double check that... A JIT re-ordering bug is a scary thought. I'd think that this problem would be seen more widely if that were the case. Chris -----Original Message----- From: Dan Creswell [mailto:[email protected]] Sent: Thursday, September 22, 2011 8:54 AM To: [email protected] Subject: Re: What can cause IllegalMonitorStateException from inside a synchronized block? final Object muxLock = new Object(); I believe that should mean muxLock cannot change.... On 22 September 2011 14:29, Sim IJskes - QCG <[email protected]> wrote: > On 22-09-11 14:38, Sim IJskes - QCG wrote: >> >> On 22-09-11 14:32, Sim IJskes - QCG wrote: >>> >>> On 22-09-11 14:04, Christopher Dolan wrote: >>>> >>>> It's quite reproducible, but only in integration not in isolation >>>> (yet). It was discovered as a hang in QA, then after several >>>> reproductions, someone attached a debugger and found that surprising >>>> exception. >>>> >>>> We've discovered that switching from Sun Java 1.6 back to 1.5 makes >>>> it go away. >>>> >>>> One noteworthy fact I've since learned (and it's obvious from the >>>> stacktrace in retrospect): this is a C++ thread and the root of the >>>> Java stack comes from C++ via JNI. In theory that shouldn't matter, >>>> right? But that's sure has a suspicious smell to me. >>> >>> I guess the exception is created JNI side. >> >> Are you using special garbage collector options? Can you try without? >> >> Gr. Sim >> >> > > Just to be sure. muxLock is garantueed to be constant during the execution > of this code is it? No other thread assigning some other instance to it? > > Gr. Sim > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >
