Hxcpp uses conservative stop-the-world GC, where the threads need to co-operate. - Threads must not change GC pointers in the collection phase - The thread stacks/registers must be scanned for GC pointers - Threads must not block without letting the GC system know not to wait for them, otherwise GC blocks until end of block + call hx::GCEnterBlocking() / gc_enter_blocking() / (cpp.vm.Gc.enterGCFreeZone() from Haxe) before potentially blocking system call (fs,network, etc) + call hx::GCExitBlocking() / gc_exit_blocking() / (cpp.vm.Gc.exitGCFreeZone() from Haxe) before making more GC calls + Might need to pre-allocate buffers + Don't forget the exit blocking on error condition
When you create a thread from haxe, it starts attached. Before a non-haxe created thread can interact with hxcpp, some care must be taken, since GC allocations are done using a GC context per thread, and all threads must respect the stopped world. - Foreign threads must be attached-detached
- SetTopOfStack(int * inTop,bool inPush) - *inTop* = pointer to top of stack to attach, or '0' to remove stack - *inPush* = usually true. recursive attachment/detachment
Say the system starts each program stack at 10000, the stack might look like this, with local variables and arguments pushed on the stack:
10000 ----------------------------------------------- 9996 startup temp variable 9992 startup temp variable -- main function -- 9988 main return address - order and details of this are ABI specific 9984 char ** argv 9980 int argc
Hxcpp then runs it main code, which starts with the macro HX_TOP_OF_STACK, which expands to something like:
int t0 = 99; hx::SetTopOfStack(&t0,false); ... __boot_all(); __hxcpp_main(); -- main function -- 9988 main return address order and details of this are ABI specific 9984 char ** argv 9980 int argc 9976 int t0 -- hx::SetTopOfStack -- records '9976' as top of stack for this thread
Later, many generated functions deep,
__hxcpp_main generates an allocation call which
triggers a collection
... 8100 Array<Bullet> bullets -- alloc Enemy -- ... -- Call collect -- 8050 int bottomOfStackTemp MarkConservative(&bottomOfStackTemp, 9976) -> scans stack from 8050 -> 9976 MarkConservative(Capture registers)
Enter/exit use similar technique, where the registers are captured and the bottomOfStack is 'locked-in' when the "enter gc free zone" call is made.
8100 Array<Bullet> bullets -- EnterGCFreeZone -- 8088 int bottomOfStackTemp thread->setBottomOfStack(&bottomOfStackTemp) thread->captureRegisters() return * any changes here will not affect GC
Now, when another thread does a collection, the gc-free thread can be scanned from 8088 to 9976, regardless of any stuff happening lower dowsn the stack.
Top of stack can be tricky to get right when a gui framework does not really have a "main".
10000 ----------------------------------------------- 9996 startup temp variable 9992 startup temp variable -- main function -- setupWindows(onReadyCallback)...... ... 8000 -- onReadyCallback -- 7976 int t0 SetTopOfStack(&t0,false) -> 7966 __hxcpp_main(); setOnFrameCallack(haxeOnFrame) return;
Later, the haxeOnFrame callback is trigger, but not "below"
9800 -- haxeOnFrame --- // Top of stack will be below bottom of stack.
Solutions: - Make sure you get in at top of main
+ may scan too much?