On Mon, Oct 14, 2013 at 10:09 PM, Bennie Kloosteman <[email protected]>wrote:
> Yep and if 50% of objects are value types and 50% of the ref > objects/actions are in enclosed regions there should only be 25% of the ref > counts ... 12% basic interlock ref count system cost becomes 3% . > A value type is simply a type that is pass-by-value rather than pass-by-reference. I have the sense that you are using the term "value type" here to mean "a type that does not have outbound references". I have been referring to these as "reference-free types". A value type can live on the heap, and when it does, it will be "wrapped" by a conventional object header. If you like, you can imagine that for every value type V there is a corresponding reference type V_ref, and the two are assignment compatible by dispensation. The proportion of reference-free types in the heap is unknown (at least to me), so it's hard to make sensible predictions based on that. Even reference-free types can have virtual functions and run-time type information, and *those* require something very like a reference. So the real beauty of a reference-free type is that none of its references are * mutable*. This means that no "store reference to slot" operation will occur on these types, and in consequence a reference type never needs to be logged by the reference counting scheme. Admitting unboxed types in the language/runtime has several consequences: 1. Objects, on average, tend to be slightly larger. The actual impact on object size demographics is something I don't know. 2. The number of roots on the stack goes up, because (a) locals are bigger, and (b) procedure calls make copies of value types, some of which contain references. The larger number of roots *may* be offset by having fewer objects to mark in the heap (because, in effect, one layer of indirection has been unboxed). 3. I suspect that the average size of a logged object grows (more importantly: the average number of references per logged object). Statement 3 is a belief that I haven't seen examined in the literature. My theory is that larger objects have more semantic "weight" in the program, and are therefore more likely to be the focus of mutations. This could be totally wrong. What *is* clearly true is that the efficiency of logging for deferred reference counting is a function of the weighted average number of references per logged object. It seems likely that unboxed types will tend to make that number go up. When i wrote that i was thinking reference could be 11-12 bytes structures > with the pointer ( or possibly masked high bits in a 64 bit pointer or 32 > bit pointer as an option on a 64 bit machine) and some flags (freeze / > release immutable ) and a counter so you dont have to have a header. > Adding size to the reference is far worse than having an object header. Unless you can play mapping games to implement lazy masking, masking is also expensive. On some machines you can used the VM system for masking, because some virtual caches aren't physically anti-aliased. Masked pointers are *sometimes* viable on 64-bit machines, but they are problematic on 32-bit machines, and you still would need an object header for forwarding. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
