On Mon, Jan 6, 2014 at 4:55 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sat, Jan 4, 2014 at 9:02 PM, Ben Kloosterman <[email protected]>wrote: > >> On Sun, Jan 5, 2014 at 12:43 PM, Jonathan S. Shapiro <[email protected]>wrote: >> >>> On Sat, Jan 4, 2014 at 7:43 PM, Ben Kloosterman <[email protected]>wrote: >>> >>>> Taking a step back I dont see how life time is becomes an issue just by >>>> changing an interface from a reference type to a value type . >>>> >>> >>> Simple. A reference type, ultimately, cannot be stack allocated. It is >>> always correct to simply migrate the reference type into the general GC >>> heap (i.e. the oldest region). Value types can be stack allocated. Along >>> with that comes hard region bounds. >>> >> >> I dont see an issue for the interface being value typed and on the stack >> its no diffirent to nay other value type holding a reference. >> > > I think I agree. The only issue is escape, and that's only an issue when > the interface references a life-time constrained object. > Yes but that is not because the interface is a value type but because it holds a pointer to a value type. > > >> For interfaces to objects an interface cant outlive an object when the >>>> interface holds a "reference" to it . They will always be collected ( >>>> whether stack frame , region of GC) together or interface then object. >>>> >>> >>> For an interface to a stack allocated value type, this is not correct. >>> >> >> Yep . I said that later but it doesnt answer the question whether >> interfaces should refer to stack allocated value types . What else does >> that introduce ? >> > > It introduces a region constraint. > > Here's why I think we need to look at this. I've been asking when to use > interfaces vs. instances. If we use interfaces for I/O, for example, we > certainly want to be able to do I/O on value types. And if so, then > interface instances need to be able to reference value types, and value > types will very often be stack allocated. > Ok interfaces can be long lived but these are nearly always assigned to a heap ( in Java /C#) , even though they are often created locally and passed as a param. So if they are using value types interfaces they are created on the stack ( or as a register variable) , these are then assigned to objects. So the stack part if normally short . Can we ensure that the interface value type which is wrapping a value type ( we dont care for reference) is always located in the same region /stack as the object it wrapped ( if value type ) ? Then worst case region analysis may prevent the region closing at which point we can choose to box it with warning or report as an error . Note this is a safe pointer and there is some overlap with int references. Speaking of int. ref what about an interface to a value type which is part of a heap object. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
