[Doradus]

Actually, synchronization is not an escape. Objects can be stack-allocated in methods that do synchronization.

[chrisseaton]

Yes I know - so why did you bring it up as an example of something that can prevent EA?

[Doradus]

(Whoops, I've misunderstood you twice. I think my other reply answered the wrong question. Let me try again.)

I didn't say synchronization can prevent EA. I said that calling a finalizer on an application thread can defeat the mutual exclusion that would usually be guaranteed by Java's locking. If the app thread holds a monitor when the finalizer is called, that would usually make the finalizer block until the app exits the monitor. If they're on the same thread, that becomes a recursive monitor enter on the same thread, which doesn't block.

Even if you and I solve this particular problem, these are only the problems that occurred to me off the top of my head. With these kinds of subtle, thorny issues lurking around every corner, I wouldn't expect JIT development teams to give this any real attention unless there's some workload where it matters.

[These are my personal opinions, not those of my employer.]

[Doradus]

I must have misunderstood you. You made a statement that I parsed as follows:

"If (this stuff isn't escaping) then (the JIT can prove that it isn't using a lock)."

That is logically equivalent to:

"If not (the JIT can prove that it isn't using a lock) then not (this stuff isn't escaping)."

Hence, I was explaining that using a lock doesn't count as an escape. But apparently I just misunderstood your meaning?