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]
Other format: [Raw text]

Re: question about -fno-optimize-static-class-initialization


Tom Tromey wrote:

>
>Hans> How easy is it to determine whether a call to _Jv_AllocObject
>Hans> may have to initialize the class?  I guess that's a different
>Hans> issue.  But it's the last major problem that needs to be solved
>Hans> if want the compiled code to call the garbage collector's
>Hans> allocator directly, and I think that would be a significant
>Hans> performance win.
>
>We could have a new way to allocate an object that never calls the
>initializer.  The compiler would always generate calls to this, and
>then we would hoist the initializer call into the caller.  I think
>these calls are already conditional so we only call them once per
>method (at least if the optimization is enabled).
>
Yes, I don't think this would be unreasonable given we already do it for 
static field access etc. We also want to emit initialization calls so 
that they look something like _Jv_InitClass already does, ie

if (local_init_flag_for_class == false && __builtin_expect (class->state 
== JV_STATE_DONE, false))
  {
    _Jv_InitClass (class);
    local_init_flag_for_class = true;
  }

Which I think we still dont do in most cases.

Also, the problem with using a local to keep track of the initialized 
state of a class is that it potentially doesn't work across inlined 
calls (ie the inlined function uses a different local, so constant 
propogation cant eliminate the initialization check/call), so maybe they 
should be something like:


if (__builtin_expect (class->state == JV_STATE_DONE, false))
  {
    _Jv_InitClass (class);
    class->state == JV_STATE_DONE;
  }

As long as the compiler can understand that class->state is "const" 
after InitClass is called, it ought to then be able to eliminate 
additional calls even if they occur in an inlined function.

Or, perhaps once we get tree based inlining, we can run a rudundant 
class initialization elimination pass after the inlining is done and 
avoid this issue.

regards

Bryce



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