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.
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
