The FullAOT compiler handles generics by compiling a single shared instance for all ref-only type arguments. so List<object> shares code with List<string> but List<int> gets its own version. This is the default behavior.
If this is not the case, then you have something broken in your setup. On Fri, Jul 6, 2012 at 11:24 AM, Virgile Bello <virgile.be...@gmail.com>wrote: > It would be for platforms supporting only AOT. > Of course we would license Mono. We already had a quick discussion about > licensing maybe a year ago (it's still R&D/proof of concept for now, and it > was only Windows until now so we just delayed actual deal until necessary), > but thanks for pointing out, maybe now is a good time to start the > discussion again with Xamarin, I will send an email right away. > > > On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera <kump...@gmail.com>wrote: > >> You need to correctly drive the FullAOT compiler. >> Why do you want to use FullAOT anyway? >> Do you plan to run it on a target that disables JIT? >> Do you hold a license that allows you to do so? Mono is LGPL and FullAOT >> doesn't work with it. >> >> On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello <virgile.be...@gmail.com>wrote: >> >>> During full AOT, It seems that if generics is a ref type, AOT is skipped >>> (which makes sense because most of the time it is not necessary, one >>> codegen for any ref type is usually enough). >>> However, if the class internally uses a struct based on the generic >>> types, it will fail at runtime. >>> Here is a simple example showcasing the issue: >>> >>> public class B >>> { >>> public void Test<T>() >>> { >>> System.Console.WriteLine(typeof(T)); >>> } >>> } >>> >>> public class A<T> >>> { >>> public void Test() >>> { >>> new B().Test<System.Collections.Generic.KeyValuePair<T, T>>(); >>> } >>> } >>> >>> >>> class P >>> { >>> static void Main(string[] args) >>> { >>> new A<int>().Test(); >>> new A<string>().Test(); >>> } >>> } >>> >>> If I run this program with full aot, it will fail. >>> new A<int> will work (AOT forced because value type) >>> However, new A<string> will generate a JIT exception (because even >>> though string is a ref type, A should be AOT for this specific type because >>> KeyValuePair inside A<T> needs to be JITed.) >>> >>> But maybe I misunderstood the problem (or it is just a specific bug), >>> because this other case actually work (I was expecting it to have the same >>> issue): >>> >>> public class B >>> { >>> public void Test<T>() >>> { >>> >>> System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair<T, >>> T>)); >>> } >>> } >>> >>> public class A<T> >>> { >>> public void Test() >>> { >>> new B().Test<T>(); >>> } >>> } >>> >>> >>> class P >>> { >>> static void Main(string[] args) >>> { >>> new A<int>().Test(); >>> new A<string>().Test(); >>> } >>> } >>> >>> Just wanted to check if I understood the issue right and if there would >>> be nothing preventing from fixing it? >>> I wouldn't mind taking a look at the sources by myself if necessary. >>> >>> Virgile >>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list