On Mon, Apr 14, 2008 at 12:50 PM, Mark Probst <[EMAIL PROTECTED]> wrote:
> Hey Rodrigo, > > > Anyway, this would only make sense if freeing is something that happens > > enough to > > justify the extra work. > > I don't think freeing would happen often enough. I'm actually more > concerned about the impact of the write barrier I'd need for the > hazard pointer, which would be used every time a slot is fetched from > a RGCTX. > > > I was thinking more about collections. Do interfaces have a rgctx too? > > No. I'm not sure what I'd put into the RGCTX of an interface, anyway. > What do you have in mind? > Well, I know just a little of how sharing works and I wasn't sure if it did build rgctx for inferfaces or not. Since it doesn't, using a chained rgctx won't do any good for collections, at least. > > > I expected that for F# sharing would have saved some overall time since > JIT > > activity is a lot smaller. > > I had hoped for that, too, but it's not there. Not that I'm terribly > unhappy, though - I saw generic sharing as mainly a memory > optimization. > > > By the way, talking about the F# case, generic sharing compiles 27% less > > methods, but only reduces > > the compiled code size by 6%. These numbers seen odd to me. Is generic > code > > really that > > smaller than non-generic or is the added code for sharing support that > > result on these numbers? > > I'll look into it in more detail, but it seems that generic methods > are usually very short, more so than non-generic methods. And we do > generate code that's a bit longer, but not by much. Other thing, how does sharing and inlining play together? I guess inlined generic code uses rgctx a bit less as it has precise type information at hand. If so, wouldn't more aggressively inlining generic code reduce the need for rgctx?
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
