[Mono-bugs] [Bug 354047] Type created by MakeGenericType () from a finished TypeBuilder is flagged as a generic type definition

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Thu Jan 17 09:59:45 EST 2008


https://bugzilla.novell.com/show_bug.cgi?id=354047

User rkumpera at novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=354047#c1


Rodrigo Kumpera <rkumpera at novell.com> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
                 CC|                                                |rkumpera at novell.com




--- Comment #1 from Rodrigo Kumpera <rkumpera at novell.com>  2008-01-17 07:59:45 MST ---
Zoltan,

It has to do with one of my changes. I fixed another issue, which led to this
one due to how TypeBuilder::MakeGenericType is implemented.

The generic type definition List`1 should be the same type (same instance) of
the open instantiation List`1<!0>. This is kind of obvious, as both means the
same thing, but mono didn't implement this semantics and the following code
would print false:

Type gtd = typeof (List<>);
Type oi = gtd.MakeGenericType (gtd.GetGenericArguments ());
Console.WriteLine (gtd == oi);

I fixed that and hacked a solution to make it work in the presence of
TypeBuilders, (see MonoGenericClass::is_tb_open).

This should not happen with TypeBuilder and the behavior changes if you call
MakeGenericInstance() before and after CreateType(). Fixing that might require
quite some effort as it's a very convoluted area of the runtime.

I think a fix could be hacked by changing
metadata.c::mono_metadata_is_type_builder_generic_type_definition, but this
will make generic instantiation slower.

What happens here is that TypeBuilder::MakeGenericType works in a very
fundamental different way under mono and under MS. MS used a lightweight model,
where each instance holds only the instantiation vector, while mono does a full
type inflation to the runtime internal representation.

Honestly, I think we should stop spending time increasing the number of hacks
under the the whole TypeBuilder::MakeGenericType story and implement it
properly, it's even a [MonoTodo] under TypeBuilder.cs.

There are a couple of issues with the current situation:

-Once a TypeBuilder is inflated, changes made to the builder are not reflected
to the inflated type. This is a big one and causes bug like #335011. It's
fixable, but once again, will be a hack. Marek shown interest in making gmcs
use the MS semantics of SRE for generic types, but that bug is a blocker for
him.

-The current design causes memory retention, generic instances of a TypeBuilder
allocated unmanaged memory and this makes harder to make then GC'able. There
are no reasons to keep instances of TypeBuilder::MakeGenericType() around after
the type has been created.

-Implementing most of TypeBuilder::MakeGenericType under managed code will kill
 a lot of C code - which is a good thing for Moonlight, for instance.

-Things will use a lot less memory, as a managed instantiation of a generic
TypeBuilder can be as big as 16 bytes on x86 as it only needs a reference to
the arguments vector. This is a major win compared to the current situation.

The things that will be worse are that the code to save an assembly should get
slower since it will have to handle managed objects and not the runtime
internal representation and the runtime will need to call into managed code to
inspect such instances.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the mono-bugs mailing list