I've now pushed the first phase of garbage collection of the code area to git master. This marks unreachable code segments and fills them with HLT instructions so that any attempt to execute a segment that is supposedly garbage will produce an illegal instruction fault. I've dealt with return addresses by considering any value that could be an address into a code segment as a potential return address. This works for my previous example. Finding the start of a code segment from a return address is done by having a bitmap to indicate the start address. This is a small overhead but much less than would be needed if we had to cover the whole heap.
The next step is to reuse code space that has been identified as garbage.
David
On 20/10/2016 21:57, Rob Arthan wrote:
That sounds very promising. Is it also the case that space for code that was only generated to calculate the value of a top level binding will be reclaimed when you save state or export an object file? E.g., the code generated for the right-hand side of the following binding.
val fact10 = let fun f i = if i <= 0 then 1 else i * f(i-1) in f 10 end;
If so, then the only one of my use cases that might have a problem is interactive development. I strongly suspect this is not going to be significant in practice. As I said, if there is a way to see how much memory is occupied by compiled code, I could do some experiments to see if my suspicion is correct.
Regards,
Rob.