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: need to focus on java performance?


>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:

Bryce> Finding the method's address is easy enough, but what about the
Bryce> address of the atable entry containing the pointer to the method?
Bryce> Thats what needs to be patched. Also, patching all the callers for a
Bryce> given class at once would mean we can drop all the unneeded
Bryce> trampolines, saving memory.

Well, one idea would be to put the address of the atable into the
trampoline itself.  The trampoline function could initialize the
class, rewrite the atable entry, and then forward the call.  (This is
more or less what my jit does.)

Now that I've said my bit, I think this thread is going off in the
weeds a bit.  As Andrew said in a different message, a big problem is
not that we don't know what to do -- this thread proves we can
generate ideas -- but that we don't have the time to implement it all.

To me this says that a good approach would be first to understand our
biggest problems, and then tackle them in order of expected payoff.

E.g, applying that to this sub-thread -- I don't think we have a good
idea how expensive these class initialization checks really are.  We
know that it would be better if they cost zero, but what savings could
we reasonably expect?


I don't want to stop idea generation, of course.  And debating it and
whatnot is fine.  At the same time, often these threads generate a lot
of discussion and no concrete results.  I'd like someone to volunteer
to make a wiki page describing the various optimization ideas and
implementation approaches.

Tom


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