This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Fibonacci and performance




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]