In v3, there are fast lookups FS -> ID : myFs._id() // compiles to a fetch of a final int field in the FS object
To go from an ID to an FS is not generally possible, because normally, the framework doesn't keep this association. There are exceptions though, the main ones being: a) If you use low level CAS Apis to create FSs, the API returns the ID, which means, that a GC that happens right after the API returns would garbage collect the FS because at that point, nothing is "holding on" to any reference (it's not in any index). To prevent this, the low level create FS methods add the FS to a map which goes from ID -> FS, and thus "holds onto" the FS, preventing Garbage collection. b) Another case where this happens is when PEARs are used; in this case the FSs involved with PEAR "trampoline" FSs end up being in similar maps. Both of these approaches of course disable a feature of V3 - namely, that unrefererenced FSs can be garbage collected. -Marshall On 9/2/2016 8:47 AM, Richard Eckart de Castilho wrote: > Fast lookups ID -> FS and FS -> ID would also be very much appreciated :) > > Cheers, > > -- Richard > >> On 02.09.2016, at 14:17, Burn Lewis <[email protected]> wrote: >> >> Could the id assigned in V3 be the same as the V2 address, as if the offset >> in a heap? Unique and monotonically increasing. >> >> Burn >> >> On Fri, Sep 2, 2016 at 5:36 AM, Peter Klügl <[email protected]> >> wrote: >> >>> Same here. >>> >>> >>> It looks like that we are now also starting to use the address, and I am >>> also thinking of using it more in Ruta (internal indexing). >>> >>> >>> Btw, I did some simple experiments lately concerning the stability of >>> the addresses when using CasIOUtils. Can it happens that the addresses >>> change if you just deserialize the same CAs twice without serializing it >>> in between? >
