On Tue, Oct 15, 2013 at 11:03 AM, Bennie Kloosteman <[email protected]>wrote:
> On Tue, Oct 15, 2013 at 10:53 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> 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. >> > > Yep but that would be poor design in a ref counted language , you would > often put many in a single object , try to use regions and stack more etc.. > Umm. I didn't mean to suggest that *interior* value type instances would get headers added. Only the outermost. And in a reference counting design, that seems to be the only option in designs where boxed objects get a header at all. But you do (implicitly) raise the problem of whether interior references can be supported. That's a big can of worms, but it seems to be orthogonal to the GC vs. RC choice. That's something we should take up separately, I think. > Agree imutable is important and also note string implimentation as an > array reference vs an embeded char[]. Ref counting has huge implications on > design ..its going to be hard getting a standard lib that works well with > ref counting and a GC. > I'm not sure why ref counting should have any impact on string implementation. The question of whether the string payload immediately follows the header or is stored separately has more to do with relocation concerns than with GC/RC in my mind. Above a certain size, you really don't want the string payload stored contiguously. Can you explain what you see as the relationship between GC/RC and string design? > > > >> 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. >> > > Im not convinced of that ...ref counting on C++ does exactly that and the > basic implimentation C++ is much faster than Java using bits in the header( > yet alone a new header field) . > Measurements please, because this is *incredibly* counter-intuitive, and seems contrary to every hard measurement I know about concerning L1 cache misses. Unless the implementation has changed a lot since I last looked, the performance of C++ reference counting pointers is truly awful, and the size penalty of using them is pretty significant. I think the cost of the object header is greater than we think... > Maybe so. But a significant number of objects do have in-degree higher than one, and for those objects it is much better to use a one-word header than an additional word per pointer. There are also interop issues when fat pointers are used. Finally, I'm not at all convinced that the per-object header can be eliminated when fat pointers are used. You only have to need a single bit for object forwarding to require a full word of object header. Im pretty sure the fastest will be 32 bit pointer on 64 bit machine .. > I assume you mean to be filtering out the high 32 bits? Then you might be surprised. The reduction in D-cache utilization from this is pretty serious. > So whats the cost of 2 32 bit fields + the header overhead itself 7-10% ? > Fair question, except that I don't see any use case for more than one word of object header at this point (unless you count the vtable pointer as part of the header, which I do not). What do you imagine lives in that 3-word header? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
