On 12 January 2014 22:41, Ben Kloosterman <[email protected]> wrote: > Shap any comment on this > > "Can we ensure that the interface value type which is wrapping a value type > ( we don't care for reference) is always located in the same region /stack > as the value type wrapped ? 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 ." > > If we think such interfaces are always short lived ( which is likely true)
It's much more common that an interface is the only handle to the object that its client uses - but this is a solved problem, really. > 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 ? 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. If interfaces are implemented as instance arguments, there's often not even a need to bind the two together. > 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? -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
