+1. There's code that does just what Thilo says, used in binary serialization, I think. -Marshall
On 9/10/2015 9:15 AM, Thilo Goetz wrote: > On 09/10/2015 09:17 AM, Richard Eckart de Castilho wrote: >> On 10.09.2015, at 08:46, Richard Eckart de Castilho <[email protected]> wrote: >> >>> On 10.09.2015, at 04:06, Marshall Schor <[email protected]> wrote: >>> >>>> I don't think there's support for the 2nd, directly. >>>> >>>> It's doable. There are various bits of code around that sequentially walk >>>> the >>>> heap, which is what this would amount to, I think. >>>> >>>> I'm curious about the need for such a capability? >>> >>> Basically for doing sanity checks on the CAS, e.g. to detect if client code >>> creates FSes but never adds them to any index. >>> >>> We've hit a bug in one piece of software where some annotations were indexed >>> an others not. The latter were still reachable in that case so I could >>> implement the sanity check without this capability. But while doing so, I >>> was wondering whether it was also possible to recover non-indexed FSes. >> >> Another case would be detecting FSes that become unreachable unintentionally. >> >> Cheers, >> >> -- Richard >> > > This used to be easy when I still worked on the code, and it probably still > is. The heap starts at position 1 (position 0 is the reserved null reference). > The first positon of a heap entry is the type of the FS. There is a table that > tells you how much space an entry of a certain type takes. So you know where > the next FS starts. And so on. As soon as you reach a type cell that contains > a 0, you know you have reached the end of the occupied heap cells. That way > you can look at all FSs that were ever written to the heap. > > There are low-level APIs that let you instantiate FSs from a given heap > position (but you probably knew that). > > --Thilo > >
