Phil,
On 30/08/2012 17:45, Phil Clayton wrote:
This looks really great - it should prove very valuable. I have a couple of questions about GC when performed by another thread:
- Is PolyML.fullGC asynchronous, i.e. triggers GC to start in the
background and returns immediately, or synchronous, i.e. waits until GC completes? (Looking at profiling output for some GTK+ programs, GC is not occurring as often as I would perhaps want so was considering inserting explicit GC calls.)
When the heap has run out or if PolyML.fullGC is called explicitly all the ML threads are stopped, the GC is performed and then the threads are allowed to continue. The exception is that a thread running code through the FFI will continue to run and only be stopped if it returns to ML before the GC is complete.
A fully asynchronous GC would require substantial changes to the ML code or some rather nasty handling of reading/writing protected memory. The GC itself will use multiple threads on a multi-core processor.
- Are finalizers run in separate threads, i.e. should we be making sure
that our finalization code - whether C or SML via a callback - is thread-safe?
Currently, the only finalisers as such are associated with the foreign function interface. There are weak references and there is a mechanism for an ML thread to be woken up after a GC that has detected some unreferenced weak references. The FFI finalisers are currently executed by the "main" thread during the GC but, as we discussed in a private email, there is a problem with this if the finaliser tries to make a callback into ML. I think a better solution would be for the finalisers to be called some time after the GC by some ML thread. I don't quite know how to do that. One possibility would be to have an ML thread waiting to execute the finalisers and have it woken up in the same way as weak references are signalled. Perhaps the FFI and weak reference mechanisms could be combined in some way.
David