This repo contains CoreRT, a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET Native compiler toolchain.
@kant2002:matrix.org alternatively you could try the mono winforms implementation
True. So far, my expectation that everything except WebBrowser would simply works (assuming proper ComWrappers given) and want to validate that
I really want to have simple demos to show that technology actually working. and all heavy lifting was done by you and Jan by pushing me in proper direction.
so brains was yours, hands mine :)
thanks. It is fun working with you guys, always learning something new.
If possible I will resurrect my PR then. because it is annoying that DAtaGridView not working.
it's big thing in WinForms world.
we have two copies in the repo: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReferenceSource/ReflectionMethodBodyScanner.cs - this is the literal exact same file that exist in the IL Linker repo, including the horrible formatting. then there's https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReflectionMethodBodyScanner.cs which is the thing we actually build. if you can send a pull request that updates both with just the diff you're changing, that would make things faster
1 reply
I update them by copying the IL Linker file over and manually porting any relevant diffs, but we don't need a full update
I just don't want it to show up as a diff next time I do the full update, which is why I ask for updating both files
after COM work, that's nothing.
BTW. Do you know any book or article which explain IReferenceTracer and philosophy behind it.
because I read about COM earlier, I was almost unscattered with change, but UWP just do not want stick to me.
I have tried asking around, I do not think they have any public documentation
I tried looking at the way they are used in CoreCLR but the flow is far too complicated. Maybe it’ll make more sense after taking another look, though
Thanks. Maybe only reasonable way would be file PR here and see how everything unrolls :)
definitely not very soon.
on a very high level (I don't know more details), IReferenceTracker allows integration with the WinRT reference tracker. it's used to avoid memory leaks (we're mixing ref counting with the .NET GC). the IReferenceTrackerTarget is called into during GCs
the WinRT APIs interfaces are equally poorly documented
Looks like CoreCLR source code is my best bet. At least I already a bit familiar with that area.
@RalfKornmannEnvision oh, I just found FEATURE_EMULATED_TLS you added in the past for Android. with that I have a Hello World with a real System.Console running on Android. very few hacks needed. looks very close to being checkinable: https://github.com/dotnet/runtimelab/compare/feature/NativeAOT...MichalStrehovsky:droidhacks?expand=1
once that's done, it shouldn't be too much work to hook it up with something like https://github.com/floooh/sokol and have a canvas we can draw to and an audio buffer we can play to
@MichalStrehovsky I had a simple console app running in the past but only with debug outputs. IIRC the stack walks on Android were terrible slow. There is one improvement in this old PR https://github.com/dotnet/runtimelab/pull/296/files. I worked on another one on top of it as I noticed a major part of the bad performances is that for every walk it runs trough all dynamic modules over and over again to find the correct one with the needed information. And at least on android there are a lot of dynamic modules and the needed one seems always somewhere at the end of the list.
yeah, I didn't try to measure perf yet and for now run out of the time I allocated myself for it (back to doing "work stuff"). might get back to it next week. Jan wanted to find someone else to review the unwinding change because these things require a bit more careful look when they go into the product. The person who was finishing up the ARM64 Linux/Windows support didn't look into it and I'm not too qualified. At some point I'll need to learn those things too.
lol
I am probably missing something simple but I have been stuck trying to get Comparer.CompareTo working on a runtime derived from Test.CoreLib. The exact issue appears related to IComparable.CompareTo so I suspect I missed something while setting up casting to interfaces since (char)a.CompareTo(b) works fine but (IComparable)a.CompareTo(b) gives junk, (char)(IComparable)a does preserve everything from char so it's not like either boxing or casting totally fail. Is there anything required for interface casting to work correctly other than RhTypeCast_IsInstanceOfInterface and RhTypeCast_CheckCastInterface? https://github.com/JoshuaWierenga/EfiSharp/tree/ArrayImprovements in case it matters but I haven't committed the actual comparison code currently.
I assume the arguments to the interface call get corrupted while we compute the target of the dispatch. the problem is that when we do an interface call, we need to resolve the target. but at that time the arguments to the interface call are already in the registers. the first thing RhpInitialDynamicInterfaceDispatch does is preserves all the registers, then calls the resolution helper, then restores the registers, and jumps to the target of the resolution
some of the assembly helpers are in the runtime because of perf. but some are there because of correctness
this one is because of correctness
you'll need to look into compiling these. it shouldn't be a problem to include assembly helpers in the EFI binary. linker can link them in
(it's not a problem with casting, it's a problem with calling interface methods. I suggest you step through it in a debugger on the "real" CoreLib to get a hang of it)
I think I am close but it's now crashing because FindInterfaceMethodImplementationTarget returns IntPtr.Zero, is there anything in DispatchResolve.cs that might be platform dependant or RhpGetDispatchCellInfo for that matter? I might have to try updating my copy of NativeAOT since I saw you changed a few things related to interfaces a few days back, I am already using the changes in EEType and DispatchResolve, not sure if anything else changed during the last runtime pull.
do you mean this one? dotnet/runtimelab#1219. the compiler and the runtime data structures have to be in sync, so yeah, this would be needed if you also picked up a new compiler. nothing comes to mind - you'll need to step through it. on a high level, each interface dispatch contains three pieces of information - the slot number of the interface, the interface type and a
this. we look up the dispatch table for this and then iterate over all the entries in it until we find the row with a matching interface type and slot number. we then take the code pointer from the last "column" of the table
I started a running list of breaking change announcements here: dotnet/runtimelab#1241. there was no good way to communicate when we're breaking things. since this is all preview-quality, we're pretty liberal in breaking things