From: Gergely K. <ger...@ma...> - 2009-12-12 00:09:38
|
Hi, I observed a problem with the way synchronized (or more accurately monitorenter and monitorexit) were implemented. The use of the @synchronized statement is problematic, because javac likes to emit multiple monitorexit's in try / catch branches for a single monitorenter in many different cases. So I took the following approach: - added an xmlvmLock and xmlvmUnlock method to the java_lang_Object category - these methods simply call [XMLVMLockRegistry lock: self]; and [XMLVMLockRegistry unlock: self]; respectively - XMLVMLockRegistry is a singleton instance which uses a dictionary to store the lock objects for each object which uses the synchronized facility. - now the monitorenter and monitorexit implementations are very straightforward, basically like this: _op1.o = _stack[_sp --].o; [_op1.o xmlvmLock]; _op1.o = _stack[_sp --].o; [_op1.o xmlvmUnlock]; My implementation is currently at a proof of concept level (it leaks lock objects currently), but it enabled me to go from ~1100 compile errors in the generated code to ~30 in our application. If you like this approach, I plan to submit this for inclusion after a bit more testing (hello world tests were successful). I also implemented a few missing opcodes in the xsl, but our private xmlvm branch is still at r666 of the xmlvm trunk. We will merge from trunk soon and then plan to start sending back our changes. We are implementing fair chunks of java.io and java.util (and java.lang along the way). Best Regards, Gergely -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 |