ttyLocker and other locks

[Tom Rodriguez]

Resending, again ...

On Feb 21, 2011, at 6:48 PM, John Rose wrote:

> On Feb 21, 2011, at 2:23 PM, Tom Rodriguez wrote:
> 
>> Anyway, I'm out of good ideas to fix this other than removing the ttyLocker.  I actually think the ttyLocker itself is the problem.  It really only exists to encourage our output to be emitted more nicely than we get without it.  PrintOptoAssembly in particular produces fairly horrid interleaving when running with multiple compilers.  Narrowing the lock to just a single dump call doesn't help since the Compile_lock is acquired inside the dump call.  Vladimir suggested having a ttyUnlocker like construct that we could place before the lock of Compile_lock to release the lock if it was held and then reacquire it. That's fairly ugly but I'm all out of pretty I think.
> 
> The ttyUnlocker is a good idea.  Here's why:  ttyLocker not only encourages the system to keep related output together, but it also inserts (into the hotspot.log) markup which shows which threads are emitting which output, when output is interleaved.  Not only will ttyUnlocker limit the interleaving of output from multiple threads, but it will also cause the interleaving to be properly marked.

It feels like a hack but it's the only way to resolve this in a simple way.  I don't think it would be easy to make the CI always cache the types in a way which would avoid lookup in this case.  The shared information in the CI has to form a closed graph and adding in all the types of the fields seems likely to expand the number of things we share in an unknown fashion.

Anyway, here's the review of that fix.

http://cr.openjdk.java.net/~never/7021531

7021531: lock ordering problems after fix for 6354181
Reviewed-by:

After the fix for 6354181 we may acquire the Compile_lock while
printing and we may be holding the tty lock.  In general there isn't
an easy way to avoid acquiring this lock during printing so the fix
I've ended up with a conditional ttyUnlocker that releases the lock
when we acquire the Compile_lock.  I didn't modify the others since
they don't currently seems problematic.  Tested with PrintOptoAssembly
on 64 bit that originally showed the problem.

tom

> 
> -- John