On Sun, Nov 3, 2013 at 9:13 PM, Ben Kloosterman <bkloo...@gmail.com> wrote:
> > > 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. > Sorry. Yes, network packets would go in the heap, but they don't lay out in the way that you want unless you can encode dependent unboxed array sizes. > 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.. > No. First, we don't know that it's 1 in 1,000,000. In the Coyotos kernel it could turn out that interior pointers are performance critical. I'll give an example of how they are used in a moment. > 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. > So in general, regions are an abstract concepts. Some may get stack allocated, but in the general case an object in a region still lives in the heap. So being in a region doesn't change the considerations for the runtime. What regions do in one case (stack allocation) is trade pressure on the nursery for increased mark time on the stack. In the other case (dynamic regions), they might let us group objects into blocks more effectively for purposes of fast reclaim, but we don't know yet if that's worthwhile. Oh. I suppose region typing might also let us differentiate local vs. shared objects, but I haven't thought about whether that's really the case. shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
