Put brackets around ipv6 addresses in `inet6 present`

[factor.git] / vm / callbacks.hpp

diff --git a/vm/callbacks.hpp b/vm/callbacks.hpp
index 0de5cad91fea3910df242d0308f8c98425e516f5..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 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.
-
-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 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).
+
+// 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.
+
+// 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;