As I understand the GC it just adds a bbRelease and bbRetain to each write access to a Global or Field variable of type Object (or something derivered from it).
These macros aren't added to a write acces to a Local variable. So the program flow had to go different depending on where the Object Ptr points to: if it points to a Local variable it could simply set the assigned value, but if it points to a Global or Field variable it would need to bbRetain the assigned value and to bbRelease the previously contained value. Of course this could be done by simply comparing the address of the variable pointed by the Object Ptr variable with the current stack pos, esp, and the stack-top stored in the GCStackTop variable. But this would add a big overhead to each dereferenced write access to an Object Ptr variable, which could be done easily if you would say: bbRelease and bbRetain need to be added to each write access to object variables, so each reference is counted in the object's ref-count and there's no need to scan the stack for references.
"The GC is not multithreading save, that easy it is currently"
Here are some points which would be needed for a threadsafe GC:
- a global synchronization object (an Event object on win32) which makes sure that only one thread enters one of the GC functions. So there should be a call to WaitForSingleObject at the beginning of each GC function (GCAlloc, GCFree, collectmem...) and a call to SetEvent at the ending.
- the bbretain and bbrelease code needs lock statements to prevent simultaneous execution on multi-processor systems. the bbrelease code needs to have only one access to the ref count, which does two things: decrement the count and check whether it became zero, to eventually call GCFree
- no stack search any more, instead counting all variables with bbretain and bbrelease, so the bbGCStackTop variable wouldn't be needed any more.
I think these are the most important changes to create a threadsafe GC or is there anything else?
These macros aren't added to a write acces to a Local variable. So the program flow had to go different depending on where the Object Ptr points to: if it points to a Local variable it could simply set the assigned value, but if it points to a Global or Field variable it would need to bbRetain the assigned value and to bbRelease the previously contained value. Of course this could be done by simply comparing the address of the variable pointed by the Object Ptr variable with the current stack pos, esp, and the stack-top stored in the GCStackTop variable. But this would add a big overhead to each dereferenced write access to an Object Ptr variable, which could be done easily if you would say: bbRelease and bbRetain need to be added to each write access to object variables, so each reference is counted in the object's ref-count and there's no need to scan the stack for references.
"The GC is not multithreading save, that easy it is currently"
Here are some points which would be needed for a threadsafe GC:
- a global synchronization object (an Event object on win32) which makes sure that only one thread enters one of the GC functions. So there should be a call to WaitForSingleObject at the beginning of each GC function (GCAlloc, GCFree, collectmem...) and a call to SetEvent at the ending.
- the bbretain and bbrelease code needs lock statements to prevent simultaneous execution on multi-processor systems. the bbrelease code needs to have only one access to the ref count, which does two things: decrement the count and check whether it became zero, to eventually call GCFree
- no stack search any more, instead counting all variables with bbretain and bbrelease, so the bbGCStackTop variable wouldn't be needed any more.
I think these are the most important changes to create a threadsafe GC or is there anything else?