[gclist] finding object prefix from infix pointer

[Francois-Rene Rideau]

> I was stating a disadvantage to NOT using your scheme.
Uh, ok :)

But it looks like we've moved from the topic of implementing read/write
barriers to a _completely_ different (and orthogonal, it seems to me)
topic of identifying object head from an infix pointer (assuming your
implementation uses unguarded infix pointers).

> I'm not sure of a situation where it's more than just a minor inconvenience
> to do such a BIBOP lookup. There ARE techniques possible to ensure you can
> find the head of an object by scanning back in memory. As I recall, we used
> that in NIL on the Vax. (A long time ago -- don't quote me!).
Indeed, and I vaguely remember the technique was used in some recent
ML/LISP/whatever implementation (don't remember which), in a copying gc,
when looking in fromspace. And the technique is indeed interesting
if you have very few infix pointers, or your objects are all small.

However, the technique doesn't work in presence of BLOBs (or even BSOBs);
now you could have a way to separate BLOB zones from small object zones
from the high bits of their address, which is actually but
a partially evaluated static BIBOP implementation tactic,
and quite an affordable one indeed, on the large address spaces
required for my trick to be interesting.

But then, by pushing the static BIBOP idea burther,
and even on 32-bit address spaces, you could completely encode
object length (for small objects) in a few bits of the address,
using a logarithmic and/or floating point encoding,
assuming the allocated memory for every object is rounded up
to next admissible value.

Have such techniques been used before?

> Also, most of the things I can think of to do with this technique, can also
> be done via proxy objects, often more flexibly. The performance tradeoffs
> are different (and the impact on how you construct the system is large, as
> we're talking about mechanisms that operate at different levels of
> abstraction), but it does seem to me like the idea has a lot of competition,
> so it may be hard to find its niche.
Indeed.

Wait, this inspires me my next message on another topic...

Best regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Laziness is mother of Intelligence. Father unknown.