Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove usage of ILGenerator #479

Open
wasabii opened this issue Jan 25, 2024 · 0 comments
Open

Remove usage of ILGenerator #479

wasabii opened this issue Jan 25, 2024 · 0 comments

Comments

@wasabii
Copy link
Contributor

wasabii commented Jan 25, 2024

Right now most of IKVM relies on the System.Reflection.Emit.ILGenerator interface, for construction of method bodies and exception blocks. The same API surface is used from IKVM.Reflection.Emit.

However, most usage of ILGenerator passes through CodeEmitter. CodeEmitter is the main type we use for assemblying IL. It then gets written into ILGenerator.

CodeEmitter, however, possesses most of the same capabilities as ILGenerator, but contains significant numbers of work around for stuff in ILGenerator: such as optimization in ILGenerator that rewrite instructions, etc. CodeEmitter is where our optimizations are applied.

IKVM is a pretty IL deep project, and doesn't need to be going through a higher-level API like ILGenerator. CodeEmitter could emit the IL and exception blocks on it's own. With optimizations that we control.

It looks like we can avoid ILGenerator in .NET Framework 4.5 and above now, since SetMethodBody is available on MethodBuilder. And, for dynamic methods/etc, we have DynamicILInfo with methods to set exception block information. CodeEmitter could write to these instead.

We would be in control of the exact IL emitted and it would remove the need for a very complicated component in IKVM.Reflection, and would require less workarounds.

This is what spawned this: dotnet/runtime#97520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant