No, ra() raises the usecount on a block and all the blocks it contains.
Garbage collection (coalescing free blocks) takes way less than 1% of time in my traces, while allocate/free take more, so I don't think it's a winner to add anything to alloc/free.
I was very surprised at how well garbage collection performs. Blocks above about 16K are handled by the OS; smaller blocks are handled by asking the OS for 16K blocks which are then split into smaller blocks as needed. A 16K block is returned to the OS only when all the blocks it was split into are all free. I thought this would fragment the 16K blocks, but somehow the fragmentation seems to be transitory.
As part of polishing the code for memory allocation, I did rewrite the garbage collector to save the time of sorting the block addresses, by using a different way of matching the subblocks.
Henry Rich On 1/12/2017 7:07 PM, Raul Miller wrote:
ra() is the thing that merges contiguous free blocks? Anyways, would it be worthwhile, when freeing a block, to check if there is an adjacent free block to merge with (before or after)? This would imply keeping freed blocks in sorted lists, which (because sorting can be expensive) would in turn imply keeping multiple sorted lists (each order of magnitude larger being sorted with an order of magnitude longer interval and merging in the shorter lists at that time), and having the check walk through each of those lists. (Perhaps a pre-allocated space for holding the list of those sorted lists.) Er... unless there's some other constraint that makes this proposal be nonsense? Thanks,
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
