
Pinned objects in the nursery?

when is preemptive GC en/disabled?

finalizers?

write barrier?  mark the card bit if a pointer is stored somewhere in the
card.

stacklets: need to mess with JIT?

bricks? free list impl

"!!"?

interior pointers: why #def?

ephemeral heap segment?


GCHeap::Alloc
  EnterAllocLock();

  check against LARGE_OBJECT_SIZE

  gc_heap::allocate
     compare alloc_ptr + size to alloc_limit (in alloc context)
     if enough space, then return

     gc_heap::allocate_more_space
       enter( more_space_lock)
       get_new_allocation -- check how much space is
	    left in current generation
         dd_new_allocation( dynamic_data_of( gen_number = 0))
       check size???

       GarbageCollectGeneration

       exit( more_space_lock)

  LeaveAllocLock();


limits:

  low
  high
  ephemeral_low
  ephemeral_high


units:

  dynamic_data - one per generation

  segment? - 16M

  generation

  alloc_context - one per generation?

  allocation_quantum - 8K

  heap_segment

  brick - 2K, one short per brick, otherwise ptrdiff_t, one brick table per
    generation, referenced by card_table_info

      -32768 large object
      -1 is clear

    size_t bo = brick_of (o);
    if (bo < brick)
    {
        set_brick (bo, (o - brick_address(bo)));
        size_t b = 1 + bo;
        int x = -1;
        while (b < brick)
        {
            set_brick (b,x--);
            b++;
        }
    }


  card - 1K cards, one byte per card, for inter-generational pointers,
	0 => no pointers, FF => pointers


Technical Overview of the CLR:

  Unmanaged pointers * or native int are the traditional pointers of other
  runtime systems, that is, the addresses of data. Unmanaged pointers are an
  essential element for the interoperation of CLI programs with native code
  components. Such pointers may not point into the managed heap since such
  heap values are under the control of a garbage collector that is free to
  move and compact objects. Conversely, values of managed pointer type may
  safely point outside the managed heap, since the garbage collector knows the
  heap limits.


Where is the space in Generation 1 allocated?

  ****Garbage Collection**** 1
  Generation 0: [00B6F8A4 00C35BA4[, gap size: 12
  Generation 1: [00AA002C 00B6F8A4[, gap size: 12
  Generation 2: [00AA0038 00AA002C[, gap size: 12

Why doesn't that happy for Generation 2 here: (?)

Considering large object 01AA0018 [01AA0024,01AA0400[
*00B6F9E0*Assert failure(PID 2232 [0x000008b8], Thread: 460 [0x1cc]): free_list
    File: f:\winxp\sscli\clr\src\vm\wks\..\gcsmp.cpp, Line: 2050 Image:


Why is the gen1 free_list overwriten with the gen2 one?



heap_segment
  .mem   	pointer to the first (if any) object in the segment
  .allocated    the next pointer to be allocated
  .committed    the first address that is not committed
  .reserved     the first address that is not reserved
  .used         the first address this is not cleared, used <? allocated
  .plan_allocated ?

generation_gap: b/c the syncblk is actually at ((DWORD*)this)[-1], so we need
to be sure that there is a place to put the syncblk for the first object in
the generation. (???)


algorithm:

  Initialize:
    - Divide allocated space into Pages
    - Add each page to the free list, linking from one page to the next

  Allocate:
    - If there is enough space in the current allocation context, then just
      allocate from there.
    - Otherwise, take a new page off the free list, add it to the used list,
      and reset the pointers in allocation context to use that page.

  Collect:
    - Start collection when only half of pages are free
    - Scan from roots, taking pages off the free list for copies
    - Keep Cheney-like pointers in tospace to track progress






How exactly is this possible:

space reserved for collector: 8060928
space available for collector: 8037312
space used by mutator: 253952
space occupied by mutator: 220518
space reserved for mutator: 8454144
space available for mutator: 8429376
space reserved, total: 16769024
internal fragmentation: 0.131655
space utility, total: 0.013150

46 live pages after collection
1968 pages reserved for next collection
2064 pages in mutator free list


TODO:

  Fix finalizeresurrect w/ printouts
  Make plugs work properly with SEPARATE_PAGE_HEADERS
  Fix initialize() space calculations
  Don't use DFS (or at least recursive-based DFS)
  Compare SEPARATE vs. NON-SEPARATE PAGE HEADERS (performance)
  Understand how to abstract the representation (in SEPARATE vs NON)
  Finish handing pinning (i.e. dynamically pinned objects)
  Finish weak pointers (i.e. the long ones)
  Clean up page manipulations
  Add page sorting?
  "Key-object"-like handling


		FIXME: spoons: "permanent pinned" could leak (as in a
		"pinned-leak"): we maintain a page as permanently pinned even
		if the object that causes us to pin it in the first place has
		died.
