On 30/08/12 18:35, David Matthews wrote:
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.
Understand. I should have read your (and Makarius') paper more carefully.. "A more promising solution is to run the garbage collector as a distinct phase as at present but to parallelize the collector itself"
- 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.
Right. For some reason I was thinking that calling back from a finalizer was only an issue on the termination pass but now understand that it is not possible generally. Thinking about it, applications should be able to work around this without too much difficulty - spotting where the word-around is needed is probably the hard bit.
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.
That sounds like a good approach. Presumably this would work for ML values generally, not just vols. I note that the MLton implementation of finalizable values uses a weak reference to determine whether an ML value still exists. It appears to check all such weak references when a GC occurs.
Thanks, Phil