Thanks WIlliam
On Mon, Jan 13, 2014 at 3:50 PM, William ML Leslie < [email protected]> wrote: > On 12 January 2014 22:41, Ben Kloosterman <[email protected]> wrote: > > > then the above has a rare worst case of a region deallocation being held > up > > by the interface. > > Well, that's expected behaviour. The issue was about what this does > for noheap programs. > > > One more comment , objects are very often creates > > slightly prior to the interfaces ,( in our case on the stack) which are > then > > passed as params which are then moved to the heap as they are members of > > heap objects. > > > Will moving between heap and stack here result in worse > > performance ? Should interfaces wrapping heap objects always be > allocated on > > the heap ? > Well provided it is allocated in the same region or stack than that is guaranteed right ? Stack will be in frame that is equal or earlier to be released. With the worst but unlikely case for regions as i stated failing to close the region the object is in . What am I missing ? Closures ? > Interfaces never really want to live on the heap. If implemented as > pairs of (this ref, vtable ref), it's cheaper to pass this around as a > well-typed unboxed value than to stick it in the heap where it needs > metadata to describe its allocation, as well as possibly a header for > RTTI. > Im thinking about GP programming with many objects in the heap having members that are interfaces and these are very long lived and its very common. So instead of create on heap , we create on stack and copy to heap in each case. If we have interfaces that are created in the storage class of the underlying object then you create a bump ptr allocated interface on heap and then assign a pointer. Likely not a lot of difference but i thought to mention it as its so common . > > If interfaces are implemented as instance arguments, there's often not > even a need to bind the two together. > Yes they will get optimized out in many cases. > > > Also what about interfaces to internal value objects ? > > Are you asking about objects whose allocation is maintained outside > the runtime, or values living unboxed within some other value? > Im asking about a value / un boxed type which is part of a heap objects . Regards, Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
