[Mono-dev] Generic sharing: Good news, bad news, how to win big

[Rodrigo Kumpera]

On Mon, Apr 14, 2008 at 12:50 PM, Mark Probst <mark.probst at gmail.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080414/8b90bd8f/attachment.html