From nicolas.geoffray at gmail.com Thu Dec 1 13:15:43 2011 From: nicolas.geoffray at gmail.com (Nicolas Geoffray) Date: Thu, 1 Dec 2011 22:15:43 +0100 Subject: [vmkit-commits] Breaking change for openjdk Message-ID: Will, I plan on submitting this patch that I know will break openjdk. Basically, I'm changing the way we intern strings to call a Java method defined in the classlib. For GNU Classpath, it's easy, it just calls VMString::intern. I don't know if OpenJDK has a Java implementation that can be called directly. Note that calling VMString::intern comes pretty early in the game: the first time a string is created in J3, it will call it. An easy fix for the openjdk port is to set JavaUpcalls::internString to NULL. The Jnjvm::constructString method will then not attempt to intern the string and call a Java method. Of course that is not spec compliant, because some strings must be interned, but at least it should not crash on you. The rationale behind that change is that the current implementation did not really work and was adding unneeded complexity on top of vmkit (more or less adding C++ weak references). It was also storing Java objects into a std::map, and I'd like to avoid that. Will, let me know if the change and my intermediate fix proposal is ok with you. Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: intern.patch Type: text/x-patch Size: 13921 bytes Desc: not available URL: From nicolas.geoffray at gmail.com Thu Dec 1 13:19:43 2011 From: nicolas.geoffray at gmail.com (Nicolas Geoffray) Date: Thu, 1 Dec 2011 22:19:43 +0100 Subject: [vmkit-commits] FatLock assertion failure? In-Reply-To: References: Message-ID: Thanks Will for debugging the problem! Indeed, I commented the releasing of the fat lock and it worked without any crashes. That's great news because it looks like we nailed it. The bad news though is that if we don't release a fat lock, it will never be able to get used again. Even worst is if we need to keep a pointer to the associated object. The lock will just keep that object alive forever. If it helps, I'm ok with submitting a change that basically comments out the release of a FatLock. When I'll have time, I'll investigate more at which point do we have a race. Cheers, Nicolas On Thu, Dec 1, 2011 at 12:49 AM, Will Dietz wrote: > On Tue, Nov 29, 2011 at 10:01 AM, Nicolas Geoffray > wrote: > > Hi Will, > > > > On Tue, Nov 29, 2011 at 3:59 PM, Will Dietz > wrote: > >> > >> Hi, > >> > >> On both runtimes, I'm seeing the following assertion occur > >> periodically (unpredictably, same code sometimes tickles it other > >> times not) > >> > >> j3: /home/will/vmkit-svn/lib/vmkit/CommonThread/ObjectLocks.cpp:305: > >> bool vmkit::FatLock::acquire(gc *): Assertion `obj->header & > >> ThinLock::FatMask' failed. > > > > That's because you have too many cores :).... That's a lame answer. The > real > > answer is that there is a bug somewhere in the locking implementation. I > > also experience in on my desktop machine (8 cores), but never on my > laptop > > (2 cores). > > Nicolas > > > > Thanks! > > Inspired by your response, I looked into this a bit and seem to have a > bit more on the issue: > > The problem occurs when we try to deflate a fat lock back to a thin > lock--there's a race on the object headers that makes the guard (that > wants to be "does anyone have a pointer to this lock anywhere") unsafe > (ObjectLocks.cpp:278-279). Indeed (from my limited understanding of > the literature, gulp) this seems to be a tricky problem in general and > not just a bug of this implementation. > > Given this, and that we probably want locks to work on SMP machines > (well, I sure do! :D), it seems we have at least two solutions: > > * Implement a more complicated locking solution ("tasuki" locks?). > * Disallow deflating of fat locks altogether. I've done this locally > to great success--a lot of mysterious crashes/assertion failures are > now gone. Downside is potential performance hit in terms of locking > overhead and lock resource utilization. > > I'm inclined to suggest we just go with the latter, and put the former > on the TODO list... but of course it's up to you, and I'm curious what > your thoughts on all this are :). > > Thanks! > > ~Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.geoffray at lip6.fr Thu Dec 1 14:00:42 2011 From: nicolas.geoffray at lip6.fr (Nicolas Geoffray) Date: Thu, 01 Dec 2011 22:00:42 -0000 Subject: [vmkit-commits] [vmkit] r145637 - /vmkit/trunk/www/releases/index.html Message-ID: <20111201220042.4DFAE2A6C12D@llvm.org> Author: geoffray Date: Thu Dec 1 16:00:42 2011 New Revision: 145637 URL: http://llvm.org/viewvc/llvm-project?rev=145637&view=rev Log: vmkit release 0.30. Modified: vmkit/trunk/www/releases/index.html Modified: vmkit/trunk/www/releases/index.html URL: http://llvm.org/viewvc/llvm-project/vmkit/trunk/www/releases/index.html?rev=145637&r1=145636&r2=145637&view=diff ============================================================================== --- vmkit/trunk/www/releases/index.html (original) +++ vmkit/trunk/www/releases/index.html Thu Dec 1 16:00:42 2011 @@ -27,6 +27,10 @@