Re: [BC] Patch: FYI: Class preparation rewrite

[Tom Tromey <tromey at redhat dot com>]

Bryce> Cool. I'm not sure about putting all the ABI linking code into
Bryce> something called _Jv_Resolver, though, and I always thought of
Bryce> resolve.cc as an interpreter specific class. Would _Jv_Linker be a
Bryce> better name? My idea was to move this stuff (ie the code to build the
Bryce> various indirect dispatch tables) to something called link.cc. Its
Bryce> doing a lot more than just resolving stuff :)

Yeah, resolve.cc used to be interpreter-specific -- but now it is
generic.

I'm ok with renaming.  Actually I don't care much either way.  It
really is linking, but anybody hacking this needs to know the
"resolve" name anyway due to ClassLoader.resolveClass.

Bryce> There are a few details of the _Jv_ExecutionEngine I'm not sure
Bryce> about it seems like a bit too much is exposed publically by
Bryce> this interface, but I guess we can work that out more as we go
Bryce> along...

The execution engine "API" is completely ad hoc.  Basically it boils
down to us having different Class layouts and meanings depending on
where the class came from.  This is sub-ideal, but it makes sense
given different needs in different places.  E.g., we could have
defineclass build an otable and atable and modify the interpreter to
suit, but that seems like a lot of work just to get rid of one of the
_Jv_ExecutionEngine methods.

Even the name "execution engine" is wrong here, as I belatedly
realized... the thought experiment is "what if we had a jit in here?"
-- obviously the class would come from defineclass.cc but would have
*other* different bits, not covered by the current API.

So, still a bit of a mess naming-wise, but at least the logic parts
aren't as horribly confusing.  I put some of these cleanups on my
to-do list.

Ultimately I want all the interpreter-specific code (except one small
initialization bit) in interpret.cc.  Even defineclass.cc can be
generic, e.g. we might have a jit around someday.

Tom