This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Fibonacci and performance
- To: "'green at redhat dot com'" <green at redhat dot com>, "Boehm, Hans" <hans_boehm at hp dot com>, tromey at redhat dot com, Java Discuss List <java at gcc dot gnu dot org>
- Subject: RE: Fibonacci and performance
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Mon, 30 Apr 2001 17:41:02 -0700
> From: Anthony Green [mailto:green@redhat.com]
> This is very similar to how we currently deal with class
> initialization for
> static variable references. So most of the infrastructure
> already exists
> (ChangeLog entry appended).
>
> One difference is that the class initialization flag in my change is a
> method local, not file static as you suggest. The advantage
> is that the
> compiler will automagically optimize out redundant
> _Jv_InitClass calls in a
> given method. I don't think this will happen if we use a
> volatile file
> static. Perhaps combining the two techniques would work well.
>
Isn't there a fundamental problem here? The testing of the "initialized"
flag may not be reordered with respect to variable references, and hence
should be treated as volatile (and possibly requiring a memory barrier) by
the back end. But if it's treated as volatile, you can't optimize out
redundant tests?
Somehow the backend should know that the flag may asynchronously change to
true, but it can't ever change back to false. Is there a way of telling it
that? Is there some other facility I missed?
Hans