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:
1. 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"
2. 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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
