audio.engine.test: cleanup using

[factor.git] / vm / callbacks.hpp

diff --git a/vm/callbacks.hpp b/vm/callbacks.hpp
index 17b9f397604c940e480a0f54cb552b528e4fd143..234daa88d1e31670c5a0ef2815331a5dcb0e3f9f 100644 (file)
--- a/vm/callbacks.hpp
+++ b/vm/callbacks.hpp
@@ -1,27 +1,27 @@
 namespace factor {
 
-/* The callback heap is used to store the machine code that alien-callbacks
-actually jump to when C code invokes them.
+// The callback heap is used to store the machine code that alien-callbacks
+// actually jump to when C code invokes them.
 
-The callback heap has entries that look like code_blocks from the code heap, but
-callback heap entries are allocated contiguously, never deallocated, and all
-fields but the owner are set to false_object. The owner points to the callback
-bottom word, whose entry point is the callback body itself, generated by the
-optimizing compiler. The machine code that follows a callback stub consists of a
-single CALLBACK_STUB machine code template, which performs a jump to a "far"
-address (on PowerPC and x86-64, its loaded into a register first).
+// The callback heap has entries that look like code_blocks from the code heap, but
+// callback heap entries are allocated contiguously, never deallocated, and all
+// fields but the owner are set to false_object. The owner points to the callback
+// bottom word, whose entry point is the callback body itself, generated by the
+// optimizing compiler. The machine code that follows a callback stub consists of a
+// single CALLBACK_STUB machine code template, which performs a jump to a "far"
+// address (on PowerPC and x86-64, its loaded into a register first).
 
-GC updates the CALLBACK_STUB code if the code block of the callback bottom word
-is ever moved. The callback stub itself won't move, though, and is never
-deallocated. This means that the callback stub itself is a stable function
-pointer that C code can hold on to until the associated Factor VM exits.
+// GC updates the CALLBACK_STUB code if the code block of the callback bottom word
+// is ever moved. The callback stub itself won't move, though, and is never
+// deallocated. This means that the callback stub itself is a stable function
+// pointer that C code can hold on to until the associated Factor VM exits.
 
-Since callback stubs are GC roots, and are never deallocated, the associated
-callback code in the code heap is also never deallocated.
+// Since callback stubs are GC roots, and are never deallocated, the associated
+// callback code in the code heap is also never deallocated.
 
-The callback heap is not saved in the image. Running GC in a new session after
-saving the image will deallocate any code heap entries that were only reachable
-from the callback heap in the previous session when the image was saved. */
+// The callback heap is not saved in the image. Running GC in a new session after
+// saving the image will deallocate any code heap entries that were only reachable
+// from the callback heap in the previous session when the image was saved.
 
 struct callback_heap {
   segment* seg;
@@ -31,7 +31,6 @@ struct callback_heap {
   callback_heap(cell size, factor_vm* parent);
   ~callback_heap();
 
-  bool return_takes_param_p();
   instruction_operand callback_operand(code_block* stub, cell index);
   void store_callback_operand(code_block* stub, cell index, cell value);
   void update(code_block* stub);