This is the mail archive of the java-discuss@sourceware.cygnus.com 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: Interpreter progress...



Kresten wrote:
> Now I have it up and running a tad more, I can now run my verifier on
> top of the interpreter.  So it can at least run for the ~10 minutes it
> takes to check the entire jdk with no fault.  

Great!

> It's hard to get a precise profile, the interpreter main loop function
> just eats up most of the time... :-( 

How are instructions being dispatched?  A big switch statement?  In
any case, I wouldn't worry too much about performance just yet.
There's usually plenty that can be done to improve it.  The main
concern at this point should be correctness.

> Is there such a thing as basic-block profiling?

Well, gcov will give you basic-block counts.

> Anyway, as an experiment, I replaces some chained
> if-else-if-else.. sequences on the critical path (of setting up
> gffi-calls) into switch statements, and the whole thing became 15%
> slower!  I didn't expect that, but non-the-less, there is
> definitively being spend a lot of time doing these calls.

Try a dispatch table with GCC's computed goto extension.

> I'm beginning to think, that maybe interpreted classes should have
> an extra vtable that the interpreter can use to call other
> interpreted methods in an efficient way. Ideas?

This might be reasonable.  Do you really need an extra vtable, or just
some way of determining whether to do interpreted or native calls?

> Today, I think I'll look into adding stub support to libffi for x86.
> It seems like that way, stub support is more likely to be integrated
> in the main stream, and be supported in the future, eh?  

Yes, that's a fair statement.  I think this might be useful to other
libffi users.

> I'm thinking of adding the following public API to libffi:

This all seems reasonable to me.  I'm more familiar with the term
`closure' in this context (rather than stub).

> At some point, it may be worth having a hash table of the "cif+args"
> values, since many will be the same.

Yes - exactly.

> Let me know what you think.

Looking forward to the demo...

AG

-- 
Anthony Green                                               Cygnus Solutions
                                                       Sunnyvale, California

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