This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Fibonacci and performance
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Fibonacci and performance
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Tue, 1 May 2001 16:51:28 -0400 (EDT)
- cc: "'tromey at redhat dot com'" <tromey at redhat dot com>, "'green at redhat dot com'" <green at redhat dot com>, Java Discuss List <java at gcc dot gnu dot org>
On Tue, 1 May 2001, Boehm, Hans wrote:
> I'm confused. Is the method-local flag static? I had assumed so.
It's an automatic variable, unless I'm badly mistaken.
But now that I'm looking closer, I see emit_init_test_initialization()
does something like:
int m_l_f = (klass->state >= JV_STATE_DONE);
if (!m_l_f) {
_Jv_InitClass(...);
m_l_f = 1;
}
That could be a problem. It would be fine if m_l_f were initialized to
zero.
> I claim that (at least on something with more than 8 registers) the compiler
> should usually transform
>
> if (! m_l_f) { _Jv_InitClass (...); m_l_f = true; }
> x = s_f;
> ... x ...
>
> to something like
>
> x = s_f;
> if (! m_l_f) { _Jv_InitClass (...); m_l_f = true; x = s_f; }
> ... x ...
Nice example, thanks.
> Probably the more important issue is hardware reordering. Treating m_l_f as
> volatile deals with that issue on Itanium, but it's not sufficient on Alpha.
I think Java volatile is sufficient, but not C volatile. Unfortunately
gcj doesn't currently do anything for volatile. (There was once a PR to
that effect.) For that matter the backend is ignorant of synchronization.
GCC doesn't have any way to describe memory barrier, etc. instructions in
the machine description.
Jeff