gc_orch branch changelog

gistfile1.txt

sorry for the non-existent commit messages; hopefully this makes up for it...

- split up some of orchestration.c to run.c
- [temporarily; will fix!] changed owner thread id to threadcontext pointer
- removed fossilized new_child slot
- added gc_morgue_count, which is the number of exited threadcontexts waiting to be reaped by the gc
- added instance-wide gc_thread_id, so each active participant in a gc run can get a unique monotonically increasing id
- removed fossilized gc_sent_items
- refactored the gc_work table to also contain [between gc runs] child threads as potential work to attempt to handle in the next run
- refactored the gc work-to-pass system to use a table on the threadcontext indexed by the other *owner* thread's gc_thread_ids
- refactored the work-passing system to send pointer pointers directly to the owner thread
- refactored the work-passing system to use extended versions of regular gc worklists
- added a generic quicksort algorithm macro to support comparison expressions distinct from the slot value for reference or container semantics items
- a worker thread sorts the worklist it receives by the allocating thread_id of the pointers' targets, so it can construct each worker's worklist efficiently
- made a bunch of stores more robust by converting to use MVM_store macro (could be overly reactionary)
- refactored the gc debug logging system to be dependent on multiple (or arbitrary) flag conditions with categories
- removed MVM_thread_cleanup_threads_list... but may re-add it.
- added a do_worklist macro for collect.c boilerplate
- moved the MVM_gc_root_gen2_cleanup call from collect.c to the end of post_run_frees_and_cleanups in run.c, since collect.c is called multiple times per gc run per thread
- created macros for the various attempts to CAS the gc_status flag
- greatly simplified the orchestration of the gc start consensus building. new invariants include:
  1. a thread must successfully "interrupt" itself in order to consider itself a ready participant in the gc run (to decrement gc_start)
  2. each thread tries to interrupt the child threads it created since the last gc run, recursively.