So just to be clear, I'm talking about objects that are immutable, rather than objects that allegedly implement read-only semantics.
This may be a whole lot of nothing, but let me try to say what's rattling around in the back of my head. Really there are two cases: immutable objects and "reference immutable objects". In the latter, reference fields are immutable but data fields remain mutable. What got me thinking about immutable objects initially was forwarding during evacuation. When you forward an immutable object, you don't need a read barrier, because both copies are equally valid at all times. This, by the way, is why string compaction isn't as hard as some people imagine. The motivation here is that read barriers can be *incredibly* expensive, and they may be in force (in whatever form) for quite a long time. In fact, if you are doing continuous background evacuation, it's quite possible that you'll have an evacuating block *somewhere* essentially all the time. In that case you'll need a read barrier in force during the entire execution of the program. And so you start to see why read barriers built on page protections begin to look attractive. And all that to evacuate the 20 lousy objects that are occupying that block! Immutable objects also have implications for compaction. The moment I come across an immutable object during a mark-copy or mark-compact collection, I should put it in a block that only holds immutable objects, and I should run mark-copy for all of the immutable objects that are reachable from this pseudo-root. What happens is that I end up with a large range of lines that will live or die as a unit, because as long as the pseudo-root lives the entire block will live, and the block has been rendered contiguous. This also holds for objects that have been marked immutable, even if they weren't immutable by virtue of static typing. To a lesser degree, this also holds for reference-immutable objects (objects whose other fields may be written, but whose reference fields have become frozen). All of the same lifetime relationships apply. And that's very convenient, because objects can't usually be frozen until you are done constructing them. :-) On Wed, Oct 16, 2013 at 8:29 PM, Bennie Kloosteman <[email protected]>wrote: > I dont think the pay off will cover the costs but it may , there are many > other benefits to knowing objects will not changes. > For dynamically immutable objects (so RO here is a per-object property), the main cost is a bit in the object header. Those bits are precious, so it definitely needs an experiment. For objects that are immutable by virtue of their static type, the bit can be tucked in the vtable. Those bits are a lot cheaper. Hmm. For that matter, you could simply use VTable pairs for dynamically RO objects (one indicating RO, the other indicating RW). shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
