Hi,
Przemysław Czerpak wrote:
using some logic dependent on GC activation or thread destruction.
See above and do not forget that memory allocated by one thread can
be accessible by other threads so you cannot free mspaces when thread
is destroyed. Anyhow if you want to force freeing unused mspaces which
do not have any active memory blocks then it can be done quite easy
by adding small function which will scan all allocated mspaces and
free the ones which do not have any memory "in use". This function
can be activated by GC and it can be extended to make also memory
trimming for all existing mspaces (dlmalloc_trim()).
Yes, I found out (quickly after writing my last letter) the fact that
calling simple mspace_destroy() is not possible. After thread exist
memory can be used by another thread, but mspace_trim() can be used on
exit. It was not clear for me how another thread can free allocated
memory from different mspace, and this idea made me to take a deeper
look into internals of dlmalloc. The FOOTERS is the answer, though it
increases usage of memory a little. We can add INSECURE define also if
we want to have a small speed improvement.
Since memory can be allocated from any mspace, sometimes it can be
useful to change hbstack allocator (if two or more threads are using the
same mspace, but some mspaces are unused - it can happen after some
thread exits). But this optimisation is not critical, I think we have
more issues in Harbour now instead of trying to make more complex MM.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
