RE: implementing escape analysis

[Paul Biggar <pbiggar at cs dot tcd dot ie>]

On Thu, 2006-02-16 at 12:28 -0800, Boehm, Hans wrote:
> Whether or not you can remove locks based on escape analysis is very
> dependent on the details of the language thread semantics or memory
> model.  Whether it matters is highly dependent on the usage model.
> 
> In Java 1.5 and later, you can remove synchronizations on thread-local
> objects.  According to the pre-1.5 spec, you generally could not, since
> such synchronization still had memory ordering implications.  This may
> not have been understood in a 1999 paper.

Ah. I'm probably reading the 1999 paper you refer to (if it's either
Whaley/Rinard or Choi/Gupta/et al). I'll need to check this out.

> With pthreads, I believe you technically cannot eliminate locking on
> thread-locals, at least in all contexts, for very subtle reasons.
> (Actually, according to the straightforward interpretation, you can't.
> If you look more closely, you almost can, but not quite.  If you really
> want to know, see
> http://www.hpl.hp.com/techreports/2005/HPL-2005-217.pdf, particularly
> section 6 and footnote 10.)

I had a feeling this would be a thorny issue. In the likely case that it
doesn't work, it may be possible to raise warnings on the issue (maybe
the code has non-thread-local objects and never does any
synchronization, or vice-versa). Just an idea.

> I think synchronization elimination is important for Java, since a lot
> of the library implicitly synchronizes, whether you want it to or not.
> I'm not convinced this is a positive feature.  This is mostly not a
> problem with the C/C++ libraries, with the notable exception of things
> like putc() in stdio.  Thus I'm not really sure to what extent the
> benefit here really carries over between languages.
> 
> There are similar issues with stack allocation.  C/C++ code tends to
> stack allocate itself if it's easy.  Java code can't.

I have seen (and written) C++ code which deliberately allocates method
local objects on the heap because it's easier than dealing with having
the constructor being run immediately upon declaration, as they would if
allocated on the stack. I don't know how often it happens in real life,
though.

> It makes sense to me to do this in a language independent way if it's
> not much harder.  If it is much harder, I don't know ...

> Hans


Paul



-- 
--
Paul Biggar
pbiggar@cs.tcd.ie