ttyLocker and other locks

[John Rose]

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.

-- John