Hi,
1. we can add additional "mark" function which will be registered
with GC block together with cleanup function by hb_gcAlloc().
... We can implement it
without additional memory overhead and even increasing a little
bit speed of existing GC core code but it will be necessary
As always I vote for feature instead of backward compatibility :)
for 3-rd party code developers. Such modifications breaks binary
compatibility so maybe we should also modify hb_gcAlloc() function name
to detect possible problems at link time.
It could be hb_gcAllocate().
2. we can extend internal GC structure and introduce new field with
list of bound GC blocks. Programmer can attach given GC block with some
to other GC block using:
void hb_gcBind( void * pParentBlock, void * pBlock );
Then when GC in mark step finding pParentBlock marks also all blocks
attached to it. Such solution increase a little bit total memory used
by Harbour because we will need additional space for pointer (on some
platforms rounded to memory alignment factor - usually 8 bytes) in
each GC block (each codeblock, array, hash array, GC collectible pointer).
So, pParentBlock will have a list of all its "childs" pBlocks. It will
require one more hb_gcUnbind() function on pBlock release, or keep two
way pointers between blocks. Or am I wrong?
3. We can add new function which will be used instead of hb_itemNew(), i.e.:
PHB_ITEM hb_itemRefNew( void * pParentBlock, PHB_ITEM pSource )
... may create some performance problems if application uses a lot of
items allocated by hb_itemRefNew(). It's necessary to make linear
scan to remove hb_itemRefNew() item from the list when pParentBlock()
Not nice.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
