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
|
