View source for Disposing of dismissives

=== <u>An anomaly</u> ===

Which of the following is "different"?

* <code>freeSTRef :: STRef s a -> ST s ()</code>
* <code>closeIORef :: IORef a -> IO ()</code>
* <code>endMVar :: MVar a -> IO ()</code>
* <code>discardTVar :: TVar -> STM ()</code>
* <code>hClose :: Handle -> IO ()</code>
* <code>finalizeForeignPtr :: ForeignPtr a -> IO ()</code>

...out of all these ''dismissive'' definitions, the last two - <code>hClose</code> and <code>finalizeForeignPtr</code> - actually do exist. As for the rest, what service they could provide in the language is much more reliably performed by the implementation! So why not also leave the dismissing of file handles and foreign references to the implementation? 

----
=== <u>The problem</u> ===

'''Resource churn.'''

Unlike the other types and their values, those of <code>Handle</code> and <code>ForeignPtr</code> allow access to ''external'' physical resources which are finite, which would be quickly spent without user intervention via dismissives like <code>hClose</code> and <code>finalizeForeignPtr</code>...here's an idea: adapt the techniques used for those other types and values, so they can also be used with with file handles and foreign references.

The problem is one of ''liveness'', namely the determining of which resources are still accessible from a running program - those which have been discarded can then be reclaimed, along with their resources.

----
=== <u>The obvious solution?</u> ===

This seems the ideal task for the implementation's garbage collector...provided it isn't carrying out a full collection each time a program e.g. uses up its quota of open file handles! That might work for  megabyte-sized heaps, but frequently processing ''multi-gigabyte'' heaps is an entirely different matter.

==== The refined solution ====

The garbage collection process therefore needs to be adapted to the task - using file handles as the example:

1. the list of currently-open file handles are tagged "unused" by the program;<br>
2. the tracing mechanism of the garbage collector operates as usual (during a full collection);<br>
3. any open file handles still tagged "unused" are then closed.<br>

So the tracing mechanism need only examine the heap and other program state in full - the remaining work just involves processing the list of file handles.

==== Opportunities for improvement ====

Of course, a direct implementation is only for prototypes, due to the frequent and full traces of all program state. Fortunately, as the technique is based on garbage collection, it can benefit from the extensive prior research, development and experience in this field of study (including [https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A-Hardware-Accellerator-for-tracing-garbage-Collection-Maas-6-2018.pdf hardware-based techniques]).

----
<br>
[[User:Atravers|Atravers]] 05:32, 9 November 2021 (UTC)

[[Category:Proposals]]