java

[Stephen Weeks]

> I take your comments on return addresses as small integers
> to mean that you suggest that the native code-generator
> keeps a similar representation, incurring a small overhead
> on returns.  But why do this at all -- since we can't easily
> adapt MLton's current code generator, it seems we may as
> well have full addresses and use native instructions to
> handle returns.  

The only reason was because I want to have only one GC, and the small
integers are used by the GC to index into the frameLayouts table which 
describes the size of stack frames and where the pointers are located
within each frame.

> Also, going to native-code should eliminate
> the need for chunks, allowing each FOL procedure to be
> directly compiled into an assembly language subroutine, so
> the need for encoding return addresses the way it's
> currently done becomes less important.  

I agree.

> What am I missing here?

Nothing.  It was a stupid idea on my part.  It should be easy enough
to tweak the GC and have it build a hash table of return addresses
(once, at program startup), and use that instead.  The hash lookups at 
GC time should have negligible performance impact.

Henry, BTW, are you getting email sent to MLton again?