[MLton-devel] cvs commit: mark compact GC and backend/codegen changes

[Matthew Fluet]

>   This is the first checkin of the mark compact GC.  It is disabled for now, but
>   has passed all the regressions and a self compile with the C codegen.  There
>   were also a number of backend and codegen changes, which I'll try to highlight
>   below.  I've got everything completely working with the C codegen, but it's
>   broken with the native codegen for now.  Matthew, if you could take a look, that
>   would be great.

I'll try to take a look sometime this week.  What's the status of the
x86-codegen?  I.e., does everything that was done to the c-codegen need to
be ported, or are there particular issues cropping up?

The changes with backend/c-function.sig seem nice.

>   I added a new option, -inline-array {true|false}.  When true, arrays are
>   allocated inline, as they used to be.  When false, they are allocated and
>   initialized by a C routine, GC_arrayAllocate.  This routine could be used as a
>   hook in the future to special treatment by the runtime of large or pinned
>   arrays.  As soon as x86 codegen is working again, I'll run tests and see if
>   it hurts performance to switch the default to false.

My guess is that it doesn't hurt that much.


> + * 19 bits means that there are only 2^19 different different object layouts,
> + * which appears to be plenty, since there were < 128 different types required
> + * for a self-compile.
> + */

The 128 different types is 128 different representations, not SSA types,
correct?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel