direct threaded interpreter

direct threaded interpreter

[Tom Tromey]

I'd like to check in my direct threaded interpreter patch sometime
soon.

Overall I think this patch has a positive effect.  It speeds up the
interpreter quite a bit, at least in most cases.  In my measurements
(this is based on my notes, since I did this a while ago), one of the
benchmarks slowed down slightly.  On the other hand, some benchmarks
sped up hugely; calling a virtual function in a loop sped up 25%.

One drawback of the patch is that the "compiled" form of the bytecode
requires more memory at runtime.  For a given method, the new form
uses about 4 bytes (8 bytes on 64-bit architectures) per original byte
of bytecode.

So, this may not be the best fit for all environments.  How big a
problem would this be for people?  I could probably modify the patch
to make direct threading a configure-time option.  (I'm guessing that
making it a runtime option may defeat the purpose of making it
faster.)

This patch also cleans up some old ugliness by removing the
_Jv_InterpMethodInvocation structure.  That code predate the ability to
catch a java exception from C++.

Anyway, before I go ahead and do this I want to make sure it won't
cause undue problems.  If nobody much cares about the memory use, then
I'll just check it in.  We can always add the configure-time option
later on if it is needed.

Tom

Re: direct threaded interpreter

[Anthony Green]

On Thu, 2002-05-09 at 18:18, Tom Tromey wrote:
> If nobody much cares about the memory use, then
> I'll just check it in.  We can always add the configure-time option
> later on if it is needed.

Is making this a configure time option a lot of work?  

AG

Re: direct threaded interpreter

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

>> If nobody much cares about the memory use, then
>> I'll just check it in.  We can always add the configure-time option
>> later on if it is needed.

Anthony> Is making this a configure time option a lot of work?  

It is unknown.  I'll try to look at it before vacation.

Tom

Re: direct threaded interpreter

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

>> If nobody much cares about the memory use, then
>> I'll just check it in.  We can always add the configure-time option
>> later on if it is needed.

Anthony> Is making this a configure time option a lot of work?  

I dug into it a bit and it turned out to be pretty easy.  It does make
the interpreter a bit uglier; there are some #ifdefs littered about.
It isn't too bad, though; mostly it is obvious (to me anyway) why
things are the way they are.

I'll probably check it in this weekend, after I do some more testing.

I think the current test suite doesn't test the interpreter at all :-(

Tom

Re: direct threaded interpreter

[Bryce McKinlay]

Tom Tromey wrote:

>>>If nobody much cares about the memory use, then
>>>I'll just check it in.  We can always add the configure-time option
>>>later on if it is needed.
>>>      
>>>
>
>Anthony> Is making this a configure time option a lot of work?  
>
>I dug into it a bit and it turned out to be pretty easy.  It does make
>the interpreter a bit uglier; there are some #ifdefs littered about.
>It isn't too bad, though; mostly it is obvious (to me anyway) why
>things are the way they are.
>  
>

I'd prefer to avoid #ifdef'ing different configurations if possible. Not 
only does it make the code messier but experience tells me that whatever 
configuration is not the default will probibly stop working sooner or 
later. A runtime option would definately be preferred if thats possible.

regards

Bryce.

Re: direct threaded interpreter

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> I'd prefer to avoid #ifdef'ing different configurations if
Bryce> possible. Not only does it make the code messier but experience
Bryce> tells me that whatever configuration is not the default will
Bryce> probibly stop working sooner or later. A runtime option would
Bryce> definately be preferred if thats possible.

That would definitely be more difficult.  I think to do that and keep
the performance gains, we'd basically need two interpreters.  Though I
suppose we could do that by #include'ing the interpreter body twice.

What do you think of doing that?  I think it is a bit ugly.  I've
certainly disliked it in gcj -- but this is a different situation.

Other than maintenance, is there really much value in selecting this
at runtime?  For desktop/server use, I'd basically never run the
non-direct interpreter.  Only when space is at a minimum would I
consider it.

Right now it doesn't compile anyway, due to some gcc bug :-(.  It
definitely won't go in before June at this point.

Tom