JDK7 loop compilation bugs ?
Jan Goyvaerts
mbien
fixed, they just wait for the next update release.
using a .0 release in production on the first day is almost never a
good idea - doesn't matter what SW you are using. I am using jdk7 for
dev for a long time already and experienced only in one ea build JVM
related stability issues so far. so... don't panic - nothing unusual
with this release :)
On Jul 29, 11:41 am, Jan Goyvaerts <java.arti...@gmail.com> wrote:
> I don't mean to minimize Oracle's effort nor discredit Lucene in any way...
>
> It seems JDK7 is not usuable for Lucene at the moment. But looking to the
> blog entry underneath, it looks like it might impact quite a lot of other
Jan Goyvaerts
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Michael Barker
Mark Derricutt
-XX:-UseLoopPredicate
I'm getting tired already of seeing many sites ranting about this bug without mentioning the work around described in the actual Oracle bug tickets.
The tests that actually uncovered the problems were only written last month:
https://issues.apache.org/jira/browse/LUCENE-3079
I've not looked at the tests/patches yet but I'm curious as to what they're doing that managed to uncover this problem, and just how likely it is to hit in normal day-to-day code that no other tests fails/hit it.
Mark
Jess Holle
(even if it were only hours prior to the release) -- without making
-XX:-UseLoopPredicate
the default.
It's better not to release on time than to release something that
customers don't trust.
Having to add JVM options just to get a JVM to work correctly is a
non-starter. That's the sort of thing I expect from IBM JVMs -- and
detest them for. The default mode of the JVM should be correct and
stable -- with -XX:+UseLoopPredicate, etc, allowing those most desperate
for speed to live dangerously on their own time.
Stuart McCulloch
> Yes, but you can work around it by using:
>
> -XX:-UseLoopPredicate
>
> I'm getting tired already of seeing many sites ranting about this bug without mentioning the work around described in the actual Oracle bug tickets.
>
> The tests that actually uncovered the problems were only written last month:
>
> https://issues.apache.org/jira/browse/LUCENE-3079
>
> I've not looked at the tests/patches yet but I'm curious as to what they're doing that managed to uncover this problem, and just how likely it is to hit in normal day-to-day code that no other tests fails/hit it.
That's the problem with a lot of JIT bugs - it can be hard to say what other applications might encounter it, often it just seems like bad luck.
Back in January I debugged an infinite loop on a remote server. I tracked it down to a simple method involving an array and a counter, but couldn't see any way the loop could ever happen. Turns out the c2 JIT in 1.6.0_23 left out an increment instruction when it compiled the method :/ The workaround was to replace:
members = views[viewIndex++].members( clazz ); // this was the increment that the JIT left out
with:
members = views[viewIndex].members( clazz );
viewIndex++;
Unfortunately reducing this to a simple test class was impossible, since any change to the surrounding methods (which were also relatively simple) made the problem go away. I filed a bug report via bugs.sun.com and got a review number (1965196) but never heard anything since then - hopefully they fixed it!
JIT/JVM crashes I don't mind because at least you know there's been a problem, it's the silent bugs (such as missing/incorrect instructions) that scare me.
That said, this was the first JIT bug I'd encountered in many years...
--
Cheers, Stuart
> Mark
>
>
>
> On 30/07/2011, at 1:10 AM, Michael Barker wrote:
>
>> It's annoying, I was hoping to drop it into our CI environment next week...
>>
>>
>
Kirk
Regards,
Kirk