locks on X86

Wed Mar 14 16:36:00 GMT 2001

Jeff Sturm wrote:
> > This wont help for code which uses a
> > synchronized block inside the method rather than the synchronized modifier, but
> > presumably the modifier is a common case. There is a speed-size tradeoff of
> > course, but synchronizing first gives a lot more opportunity for optimizations
> > without inlining (synchronizing once for consecutive calls to the same object,
> > moving synchronization out of a loop, etc).
>> Method inlining would also give opportunities to merge synchronization,
> or even elminate it if the compiler can prove that an object is not shared
> with other threads. I'm not sure if either is a legal optimization
> though.

Hans pointed out in a private mail that Java allows you to override a synchronized
method with an implementation that is NOT synchronized, so synchronizing at the call
site wouldn't work, at least for virtual methods.
But as far as I can figure it would be perfectly reasonable to do synchronization
elimination when methods are inlined, or perhaps when calling non-virtuals. Even if
there are side-effects between, say, two synchronizations, it doesn't seem to be
problem to hold the lock across it because monitors are recursive. We'd have to be a
bit careful because there are possible performance implications of holding a lock
for longer than intended, but I don't think theres anything illegal about it because
there are no guarantees that a lock will actually be given to a different waiting
thread even if there is non-synchronized code between exiting and re-entering a
monitor?
regards
 [ bryce ]