On Wed, 25 Nov 2009, Mindaugas Kavaliauskas wrote: Hi,
[...] > 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. Yes, but these are very good propositions and quite easy to implement so maybe I'll add it soon at least partially. For sure memory trimming when mspace becomes unused and calling general memory cleanup function from GC can be added in few lines. Such memory cleanup function can be activated in two different states: 1. when all threads are frozen 2. after releasing unused blocks In the 1-st step it can balance mspace usage and in 2-nd it can call mspace trimming. In fact the 2-nd step is optional and everything can be done in 1-st one. Just simply sometimes it will cause that memory freed by GC will be released to system on 2-nd GC call what does not have to be bad idea because it may reduce unnecessary memory allocation/deallocation between process and OS. I also think that it's time to enable by default HB_GC_AUTO. With new hb_gcAllocate() function which returns locked blocks (they are unlocked automatically when they are attached to any know Harbour item) it's safe to activate GC in any user code. Of course if it does not try to make some operations directly on HVM internal structures in some unsafe way but anyone who use private HVM API is doing it for his own risk and should adopt his code to follow HVM modifications so it's not our problem. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
