From Martin.Buchholz at Sun.COM Fri Jun 8 00:10:41 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Fri, 08 Jun 2007 00:10:41 -0700 Subject: 6307490: (spec thread) Thread.State or related doc should clarify valid Message-ID: <466900F1.9030108@sun.com> I've come to suspect that this bug: 6307490: (spec thread) Thread.State or related doc should clarify valid notifyAll behavior http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307490 belongs to the hotspot runtime team. Could someone evaluate that? Y'all are invited to take ownership. Thanks, Martin From David.Holmes at Sun.COM Fri Jun 8 04:47:55 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 08 Jun 2007 21:47:55 +1000 Subject: 6307490: (spec thread) Thread.State or related doc should clarify valid In-Reply-To: <466900F1.9030108@sun.com> References: <466900F1.9030108@sun.com> Message-ID: <466941EB.5080100@sun.com> I've updated the CR. The current behaviour (which as of Java 6 is uniform across all platforms) of reporting WAITING is definitely a violation of the current spec - which states: public static final Thread.State BLOCKED Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or *reenter a synchronized block/method after calling Object.wait.* David Holmes Martin Buchholz said the following on 8/06/07 05:10 PM: > I've come to suspect that this bug: > > 6307490: (spec thread) Thread.State or related doc should clarify valid > notifyAll behavior > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307490 > > belongs to the hotspot runtime team. > Could someone evaluate that? > Y'all are invited to take ownership. > > Thanks, > > Martin From Lev.Serebryakov at Sun.COM Fri Jun 15 06:18:39 2007 From: Lev.Serebryakov at Sun.COM (Lev Serebryakov) Date: Fri, 15 Jun 2007 17:18:39 +0400 Subject: [BUG FIX] dtrace_object_alloc might not be reached in function, TemplateTable::_new() of AMD64 In-Reply-To: <5d649bdb0704191201j420846dpe6f37cd5ff05d757@mail.gmail.com> References: <462784D3.7050600@sun.com> <5d649bdb0704191201j420846dpe6f37cd5ff05d757@mail.gmail.com> Message-ID: <467291AF.3020709@sun.com> Neo Jia wrote: > Are you going to create an item in the bug database to track this problem? Sorry for long silence. I'm going to vacations for one week now and I'll process you patch right after that. -- // Lev Serebryakop From twisti at complang.tuwien.ac.at Fri Jun 22 08:02:50 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Fri, 22 Jun 2007 17:02:50 +0200 Subject: is vmSymbols::java_lang_InvalidClassException() valid? Message-ID: <1182524570.3368.16.camel@localhost.localdomain> Hi! While looking at the sun/misc/Unsafe code, I noticed that getBaseAndScale in unsafe.cpp throws a java/lang/InvalidClassException. As I've never heard of that one I did a quick find and the only one found is: ./j2se/src/share/classes/java/io/InvalidClassException.java Another quick grep showed that this exception is thrown in some places in the hotspot code. So, is this correct? Maybe this exception is not thrown with Java code but with a printf... just mentioning it. - twisti From David.Holmes at Sun.COM Sat Jun 23 03:19:28 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 23 Jun 2007 20:19:28 +1000 Subject: is vmSymbols::java_lang_InvalidClassException() valid? In-Reply-To: <1182524570.3368.16.camel@localhost.localdomain> References: <1182524570.3368.16.camel@localhost.localdomain> Message-ID: <467CF3B0.4000809@sun.com> Hi Christian, The other places in the hotspot code where it is thrown are legacy methods: // JVM_AllocateNewObject and JVM_AllocateNewArray are unused as of 1.4 and so never called. (Hotspot sill has a bit of legacy baggage here and there.) The unsafe code however calls getBaseAndScale via arrayBaseOffset and arrayIndexScale, which appear to be used within Unsafe.java itself. I didn't have time to see if those parts of Unsafe are themselves no longer called. I even tried a quick search of 1.3 and couldn't find java.lang.InvalidClassException. It would have to have been a non-public class, possibly a LinkageError subclass, to disappear. Interesting. Perhaps the library folk would know the history here. Cheers, David Holmes Christian Thalinger said the following on 23/06/07 01:02 AM: > Hi! > > While looking at the sun/misc/Unsafe code, I noticed that > getBaseAndScale in unsafe.cpp throws a java/lang/InvalidClassException. > > As I've never heard of that one I did a quick find and the only one > found is: > > ./j2se/src/share/classes/java/io/InvalidClassException.java > > Another quick grep showed that this exception is thrown in some places > in the hotspot code. > > So, is this correct? Maybe this exception is not thrown with Java code > but with a printf... just mentioning it. > > - twisti >