https://bugzilla.novell.com/show_bug.cgi?id=354047
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=354047#c1 Rodrigo Kumpera <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] --- Comment #1 from Rodrigo Kumpera <[EMAIL PROTECTED]> 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
