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

[Stephen Weeks]

>   I added an additional check to CFunction.isOK that asserts
>   maySwitchThreads => returnTy = NONE

Fine.

>   The new CFunction interface is nice; it lets me express a (trivial)
>   optimization of GC calls.  In particular, when a program doesn't
>   handle signals, then a GC won't ever change threads.  Therefore, we
>   don't need to do an indirect jump to stackTop on return, since we know
>   that that will be the same return address that we pushed before the
>   call.  Overall, I doubt it will make any performance difference, but
>   it was easily added.

Cool.  I did the same thing in the C codegen.

>   There are a couple of outstanding issues with threads, but nothing
>   that inhibits compilation.  My straightforward port of ccodegen.h's
>   Thread_switchTo to native assembly is busted, but peforming
>   Thread_switchTo via a C-call into Thread.c works fine.

I wouldn't worry about fixing this too much, except to see if it some
other more general bug in the x86 codegen.  There is currently still
one outstanding bug that I need to fix with threads, and the solution
I have in mind right now will mean that Thread_switchTo will be a C
call for both codegens.  The problem is that if thread is switched out
by a signal handler (via GC_gc), it may have some bytesRequested,
which gets stored in s->currentThread->bytesNeeded.  Unfortunately,
nothing in Thread_switchTo currently ensures that the bytesNeeded of
the thread being swithced to is actually available.  Bad.  The current
fix I have in mind is to make Thread_switchTo a C call that mayGC, and
have the C routine do the check.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel