vm/callbacks.hpp

   1 namespace factor {
   2
   3 // The callback heap is used to store the machine code that alien-callbacks
   4 // actually jump to when C code invokes them.
   5
   6 // The callback heap has entries that look like code_blocks from the code heap, but
   7 // callback heap entries are allocated contiguously, never deallocated, and all
   8 // fields but the owner are set to false_object. The owner points to the callback
   9 // bottom word, whose entry point is the callback body itself, generated by the
  10 // optimizing compiler. The machine code that follows a callback stub consists of a
  11 // single CALLBACK_STUB machine code template, which performs a jump to a "far"
  12 // address (on PowerPC and x86-64, its loaded into a register first).
  13
  14 // GC updates the CALLBACK_STUB code if the code block of the callback bottom word
  15 // is ever moved. The callback stub itself won't move, though, and is never
  16 // deallocated. This means that the callback stub itself is a stable function
  17 // pointer that C code can hold on to until the associated Factor VM exits.
  18
  19 // Since callback stubs are GC roots, and are never deallocated, the associated
  20 // callback code in the code heap is also never deallocated.
  21
  22 // The callback heap is not saved in the image. Running GC in a new session after
  23 // saving the image will deallocate any code heap entries that were only reachable
  24 // from the callback heap in the previous session when the image was saved.
  25
  26 struct callback_heap {
  27   segment* seg;
  28   free_list_allocator<code_block>* allocator;
  29   factor_vm* parent;
  30
  31   callback_heap(cell size, factor_vm* parent);
  32   ~callback_heap();
  33
  34   instruction_operand callback_operand(code_block* stub, cell index);
  35   void store_callback_operand(code_block* stub, cell index, cell value);
  36   void update(code_block* stub);
  37   code_block* add(cell owner, cell return_rewind);
  38 };
  39
  40 }