From: Tim Wilkinson (tim@transvirtual.com)
Date: Wed Jan 13 1999 - 14:51:58 EST
Note that GCJ stores the lock pointer in the object (just after the dtable
pointer). Okay this increases the size of each object a little but saves on that
hash lookup. I was going to do this to integrate GCJ at some point anyhow,
though I could modify GCJ to not do this if preferred.
Tim
> concern synchronization.
>
> The idea is that if you lock something using an address, then there's
> no point in having to find the lock again when unlocking the beast.
> Instead of writing:
>
> lockMutex(centry);
> unlockMutex(centry);
>
> you'd much rather write:
>
> iLock* lock = lockMutex(centry);
> unlockMutex(lock);
>
> The real win, however, will come from applying this technique to Java code.
>
> This is possible because MONITOR_ENTER and MONITOR_EXIT always occur in pairs.
> However, it will require changes to the JIT to store the address of the
> lock returned from MONITOR_ENTER somewhere, presumably on the stack.
>
> Another, even more frequent case are synchronized methods; which may be
> even easier to handle than general MONITOR_ENTER/EXIT pairs.
>
> Anyway, that's another medium-sized project to look forward to.
>
> - Godmar
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:41 EDT