* gc: add a function to force the collector to run
This requires adding a "forced" stage for the collector,
which is the initial stage for a forced collection.
Thereafter, the collector continues to the usual stages
of collection.
* runtime: force the garbage collector to run when a thread exits
This is a first attempt to improve the memory usage reported in
issue #534.
* srfi-18: call Cyc_end_thread on thread exits
This ensures that the collector has a chance to run whenever
a thread exits. Attempts to partially address issue #534.
* gc: free unused parts of the heap before merging
When a thread exits, the heap is merged into the main thread.
Before doing so, free any unused parts of the heap to reduce
memory usage. Attempts to partially address issue #534.
* srfi-18: thread-terminate! takes a thread as argument
* gc: revert adding STAGE_FORCING
Use gc_start_major_collection() instead. Partial work towards
addressing issue #534.
* gc: free empty pages in gc_heap_merge()
Moving the code from gc_merge_all_heaps to gc_heap_merge removes
special handling of the start of the list and is (hopefully)
easier to read.
Partial work towards addressing issue #534.
* gc: oops, forgot the "freed" count
Partial work towards addressing issue #534.
* gc: oops, forgot the "freed" count (again)
Partial work towards addressing issue #534.
* types: update forward declaration of gc_heap_merge()
Partial work towards addressing issue #534.
* gc: remove accidental double counting
* runtime: small (cosmetic) simplification
* srfi-18: add a slot for thread context in the thread object
Partial work towards addressing issue #534.
* srfi-18: do a minor gc when terminating a thread
This ensures that any objects which are part of the
thread context are transferred to the heap.
Partial work towards addressing issue #534.
* types.h: make gc_alloc_pair public
This will be used to create the thread context.
Partial work towards addressing issue #534.
* gc: prepare heap objects for sweeping
Also introduce a global variable to track whether merged
heaps need to be swept.
Partial work towards addressing issue #534.
* gc: create a context for terminated thread objects
The context ensures that parametrised objects, continuations
and exception handlers can still be traced but are no longer
root objects (after thread terminations) and can be GCd eventually.
Partial work towards addressing issue #534.
* gc: sweep and free empty heaps for the primordial thread
The primordial thread may not have an opportunity to sweep
heap pages which have been merged from terminated threads.
So sweep any unswept pages during the cooperation phase.
Partial work towards addressing issue #534.
* srfi-18: revert thread-terminate! changes
These changes need to be revisited, and are not suitable for
the threads garbage collection pull request.
* srfi-18: define all of the components of the *primordial-thread* thread object
* srfi-18: pthread-terminate! takes a thread object as argument
Handle this by checking if the argument is the primordial thread,
current thread or another thread.
The first two cases remain almost identical to the previous implementation.
To terminate a thread (which is not the caller) we use a pthread key
which contains the thread data. The destructor is set to Cyc_end_thread
and will terminate the thread when pthread_cancel is called. This ensures
that Cyc_end_thread is called with the correct thread data by the thread
which will be terminated.
* runtime: cast to the required type for pthread_key_create
* runtime: clear the thread_key before exiting the thread
* runtime: handle cancelled threads separately
We probably don't want to call pthread_exit in the destructor.
Similarly, we don't want to perform a longjmp (i.e. GC(...))
in the desctructor.
* runtime: do a minor GC for cancelled threads
The main idea is to avoid a longjmp and return to the destructor
for the cancelled thread. So, adjust GC and gc_minor to allow
for a NULL continuation.
Modified thread-start! to initiate a GC prior to running the thread, in case thunk contains any closures on the "parent" thread's stack. Otherwise when the parent thread goes to collect them, the contents will be corrupted when the spawned thread attempts to access them.
