[gclist] GCBench "benchmark" problem

[Boehm, Hans]

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.

Hans

> -----Original Message-----
> From: Florian Weimer [mailto:fw@deneb.enyo.de]
> Sent: Monday, May 07, 2001 3:16 PM
> To: Boehm, Hans
> Cc: 'gclist@iecc.com'
> Subject: Re: [gclist] GCBench "benchmark" problem
> 
> 
> "Boehm, Hans" <hans_boehm@hp.com> writes:
> 
> > Thus I propose to "fix" it by changing the final test to
> > 
> >  longLivedTree.left.right == null
> 
> Why can't you keep a copy of longLivedTree around in a volatile memory
> location?  Isn't this a fix instead of "fix"? ;-)
>