I dont think object size had anything to do with it eg embed array vs a slighty smaller object and a seperate large array object and vlarge objects end up in the large heap so dont get relocated.. 4.5 added support for objects bigger than 2G ( eg Array objects are still huge) .
I think the main reason is the way you use them , you need to pin them which gives a pointer. IMHO its probably just the work needed eg they need to generate array access style code that handles objects offsets and if you allow references in these embedded arrays the mark needs to be aware of it and may create problems with the mark and precise collection ( which you mention ). By the time of v2 it was clear that .NET C# was not a native replacement and would take a lot more than this to make it so , they did add fixed marshalling which seems to interop with native objects which have embedded arrays. re the precise GC reference vector Is it worth saying that any array of unboxed objects must have objects that have no references as the use cases rarely require this ( and we mentioned these no ref objects like string before as they dont need to be marked etc) . How do you pass references to this embedded array around ? Only by value as per embedded objects unless you use the ref parameter ? And if you pass around just the ref paramater is the GC smart enough not to collect the parent object . I was thinking of accessing internal arrays via a slice where either the GC is aware of objects pointed to by slices or the base pointer is to the object and the min and max values represent the array. ( I believe D has slices and is moving to precise collection but i havent seen much informattion). You can use interior pointers but they are a bit more expensive ( and im not sure C# uses them ) I dont mind autoboxing if the stack frame becomes too large . It would be nice if there is a warning / perf counter somewhere in Debug so the stack frame size or code can be adjusted if its frequent . BTW both Rust and go have replaced segmented stacks , Go now does a global pause , copies in a new stack and adjusts pointers to stack . Ben On Sat, Oct 26, 2013 at 2:30 AM, Jonathan S. Shapiro <[email protected]>wrote: > A small thought occurred to me the other morning regarding unboxed arrays. > > Given that they had been planned for CLR 1.0, I was pondering why the CLR > team might have decided not to implement unboxed arrays, and why they > currently restrict unsafe fixed arrays to reference-free types. Here is > some speculation: > > In the absence of unboxed arrays, the total size of an object tends to be > small. There are limits to how many fields programmers will add by hand in > their programs, so that effect is additive. The unboxed array construct is > therefore the only way to introduce a multiplicative effect (by replicating > some object a lot of times). > > This has implications for type description records. The traditional > bit-vector to identify pointer words ceases to be a space-effective > encoding mechanism. You begin to want a "little language" for describing > reference locations. > > A second concern involves stack barriers. Stack barriers work well when > the size of a frame (measured in object references) is relatively bounded. > If a frame can contain thousands of references, it becomes hard for a > barrier to render the scanning phase "incremental enough". > > Finally, large frames impede stack-in-the-heap designs. > > So for a variety of reasons, I think that our implementation needs to be > free to heap-allocate unboxed objects that would normally appear in the > stack frame when the stack frame becomes too large. This doesn't change any > semantics. The concern is that it reduces the programmer's direct > understanding of data layout. Perhaps to the degree that this should be > treated as a compile-time warning or error rather than a problem to be > fixed automatically. I'm not sure. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
