[Mono-dev] Porting mcs to IKVM.Reflection

[Marek Safar]

Hello Kornél,

Thanks  for the proof of concept of using System.Reflection.Emit with 
latest gmcs. I'll look into this more deeply when I iron out all 
regressions caused by the big change.

It would be interesting to get some numbers out, I don't believe there 
should be much difference between SR(E) and IKVM but one never know. If 
you are going to do some testing use any "real" user assembly (not 
mscorlib), for instance System.Web or MD.

Regards,
Marek
> mcs creates an assembly, then creates types, and only after that is 
> processing the custom attributes. This is how attributes and even 
> assembly name (not the name part) can change after definition. 
> Although there are some other self referencing cases, this order of 
> creation/definition is required especially when building mscorlib.dll. 
> At least some cases of these requirements could be eliminated by doing 
> dependency analysis but there is no use to introduce extra complexity 
> when the solution is very simple.
>
> All of these functions are implemented as hacks in Mono's 
> System.Reflection.Emit.
>
> Blob encoded pseudo custom attributes are supported by Mono. I've 
> added decoding because they weren't ignored, exceptions were thrown 
> instead.
>
> I think that the only problem is that I've removed the exception when 
> emitting backward jumps but since things were working so far, I 
> haven't tried to resove that issue yet. (This is a work-in-progress 
> state.) Unlike Java, C# has support for backward jumps, so does 
> System.Reflection.Emit so support for that will have to be implemented.
>
> Some notes on IKVM.Reflection:
>
> First of all, thank you very much for creating it, since it's very 
> unique.
>
> Based on your questions I belive that you are trying to remain 
> compatible with MS.NET. This good, because both IKVM and mcs has a 
> dynamic mode that is generating code for direct execution that 
> requires System.Reflection.Emit. And to some extent enables 
> IKVM.Reflection to be a drop-in replacement for System.Reflection.Emit 
> on runtimes that have no built-in support.
>
> I on the other hand belive that removing arbitrary limitations of 
> System.Reflection.Emit (like preventing access to TypeBuilder's 
> member-builders), and adding missing functionality would make sense.
>
> Mono.Cecil is a great tool but it targets tools operating on metadata 
> rather and is too abstract and complex for compilers. It also has a 
> larger memory footprint. So I belive that there is a need for 
> IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit 
> as well.
>
> I also like the concept of having a Universe since that makes possible 
> to have multiple compiler instances in the same AppDomain.
>
> I belive that pseudo custom attributes and unmanaged resource 
> generation does not fit well to the concept of System.Reflection.Emit. 
> I would rather remove support for both of these and introduce 
> __methods for setting metadata that currently is built from pseudo 
> custom attributes. Unmanaged resource generation could be automated 
> (and customized) by using a dedicated class. This would be much faster 
> than encoding (either binary or just the constructor arguments) and 
> then decoding pseudo custom attributes.
>
> I also belive that CustomAttributeData should not be used as a 
> provider, __GetCustomAttributes (non-standard since is returning 
> constructor arguments rather than class instance) methods should be 
> added to reflection classes. An ICustomAttributeProvider interface 
> (with IsDefined and __GetCustomAttributes methods) would be very 
> useful as well.
>
> As a conclusion I would be happy to see features (that make sense) in 
> IKVM.Reflection.Emit that are not present in System.Reflection.Emit.
>
> Kornél
>
> Jeroen Frijters wrote:
>> Hi,
>>
>> Thanks for the IKVM.Reflection patches. I have a few questions about 
>> some of the changes.
>>
>> - Why are the various _SetAttributes methods and the 
>> AssemblyBuilder.__SetName() methods necessary?
>> - Do you really need blob encoded pseudo custom attributes in the 
>> version info? I intentionally don't suppor that (and also include the 
>> attributes as regular attributes) to be compatible with .NET
>> - Why are all the stack height asserts commented out in ILGenerator, 
>> do you think they are wrong?
>>
>> Thanks,
>> Jeroen
>>
>>> -----Original Message-----
>>> From: Kornél Pál [mailto:kornelpal at gmail.com]
>>> Sent: Tuesday, May 04, 2010 2:03 PM
>>> To: mono-devel
>>> Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters
>>> Subject: Porting mcs to IKVM.Reflection
>>>
>>> Hi,
>>>
>>> Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a
>>> try to port mcs to IKVM.Reflection.
>>>
>>> I addition to being able to have a single binary, mcs could run on
>>> MS.NET and we would not have to break MS.NET compatibility in
>>> System.Reflection.
>>>
>>> I've attached some work in progress patches both for mcs and
>>> IKVM.Reflection.
>>>
>>> I was impressed by the result that mcs is able to bootstrap itself,
>>> compile mscorlib.dll and its other requirements, and the resulting mcs
>>> is able to compile a bunch of Mono assemblies.
>>>
>>> Missing features:
>>> - security attributes
>>> - embedded resources
>>> - .netmodule support
>>> - debug info
>>>
>>> Also note that I was unable to figure out what MakeExpression methods
>>> are supposed to do but I had to disable them because they need
>>> System.Reflection types.
>>>
>>> mcs pathes are licensed under the MIT/X11 license.
>>> IKVM.Reflection patches are licensed under the zlib license.
>>>
>>> Kornél