Hi David,
With regard to a user GC relocating a vector and destroying the
validity of the lovingly crafted address, I have a good idea. [Well,
I think it is a good idea. I am so tired that my eyes are making the
screen swim alarmingly, so it may be nonsense.]
How about adding a pop_after_gc "hook" that is responsible for
correcting the addresses that get mucked up? The simplest way to do
this is to modify Aaron's suggestion by "marking" the resulting exptr
struct by adding it to a temporary property along with enough
information to re-do the computation. Then the pop_after_gc hack
would re-run the computation.
Enough information means both "n" and "vec", I guess. So there is
quite a lot of overhead, really. However, you could marginally
improve on that by sharing the information. After all, one probably
repeatedly generates either identical or sequential &vec[n] values.
In either cases a sharing opportunity arises which can be exploited
by caching "n" and "vec" and checking whether it is the same or one
bigger than a previous value. But such a time/space tradeoff is
probably not what you want.
--
Steve
|