The 'M' bit says "this object has been logged; you can store references > into slots in this object without updating the target reference counts" > > >> Re internal references to c its not just c but packets,lgt,ldt skipping c >> even. >> > > I'm well aware. But these aren't things you would describe using heap > objects. >
Why not ? Network packets especially may not be easily put in a region if every part of the lib or program touches it . You can create static buffers but id rather the heap than the stack for most cases and reassigning buffers would be tricky with regions. > > >> Im ok with no internal referenced to value types but value types nearly >> always exist in a heap ref objects eg list which holds vectors. >> > > That's often true. But I can't answer your question without being picky > about names. In CLR, it is not possible to construct an internal object > reference to a value type. It is only possible to construct a BY-REF > reference to a value type. So we know from static typing that this requires > a more complicated approach for marking and barriers, and we know that the > BY-REF itself cannot be stored in a heap object. > Will do. > >> And all internal references are references to non native value types. >> > > Not necessarily. Could be references to native value types. > So because 1 in 1000000 stores &int you not need to find a M bit / header on every int.. > > >> What about value types in ref types in regions ? >> > > I don't think this changes anything. > Because your already considering regions was thinking somethign like your using internal references to objects that live the length of the region. The other side of the coin is an internal reference may not allow a region to close as it could be live longer where if a value type was used it could. > >> Btw why must regions have int references ? Why would a c# approach and >> fatpointer offset slices fail? >> > > > The short answer is that regions give us a form of liveness analysis that > we can exploit, and there are algorithms (notably string algorithms) where > regions encourage interior pointers. The fly in the ointment is object > relocation. > Its not common and for cross region get lively analysis to set the creation of them as pinned ,should add very little to fragmentation provided you have a block alloctor that reuses partial blocks like Immix. In fact its highly likely that a lot ( if not the majority) of these objects holding internal objects end up on the large object heap ( which is only 4K or 8K for Immix) . Ben
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
