[gclist] GCBench "benchmark" problem

[Boehm, Hans]

> From: Manoj Plakal [mailto:plakal@cs.wisc.edu]
> Boehm, Hans wrote (Mon, May 07, 2001 at 03:32:20PM -0700) :
> > That's another possible approach.  But one of the redeeming 
> values of such a
> > toy benchmark is that it can be ported across languages.  I 
> don't know how
> > to say "volatile" in Scheme or a number of other languages. 
>  And some Java
> > implementations seems to ignore "volatile" completely, since it's
> > potentially expensive to implement correctly and I don't know of any
> > implementations that actually handle it correctly.  See
> > http://www.cs.umd.edu/~pugh/java/memoryModel/ for more 
> details than you ever
> > wanted to know on the Java issues.
> > 
> > Just making it a globally visible statically allocated 
> variable would help.
> > But I was afraid it might have more of an impact on 
> implementations that
> > currently do the right thing.
> 
> 	How about printing out the pointer value or using the
> 	pointer to compute the return value of the procedure?
> 
> 	That might be a portable way of preventing the optimizer 
> 	from removing it.
> 
That's basically what all of the current attempts to keep the pointer live
do.  The problem is that printing out the pointer itself is not portable to
languages like Java and Scheme that hide the existence of pointers.
Comparing the pointer to null is not sufficient, since the test can
sometimes be resolved statically.  In Java, you could print or return tha
hash code of the object, but does that port to other languages?  It's
probably also too easy to move the hash code computation up in the code.

I think that leaves dereferencing the pointer (a few times to foil a
potential static points-to analysis), which was my proposed solution ...

Hans