Repository navigation
Changes in .NET structure #5
Description
As of about a week ago the structure of MethodTable was slightly changed, among others in CoreCLR.
You may want to change this, or don't, it's largely inconsequential, but something to take note of.
I did make the changes in my repo, so if you do choose to change the structure you're free to just copy what I did (C# and D are very similar so this should be easy)
Also, is this project still being maintained? Just curious because as far as I know you're the only other person doing this sort of thing, and I'm not sure what your plans are going forward.
Activity
Decimation commentedon Jan 24, 2024
Thanks for the heads-up. I'll definitely make the necessary changes.
Yes, this is still being maintained. It's one of my main projects. As for plans going forward, I don't have any major ideas in particular.
Decimation commentedon Jan 24, 2024
I updated to
.NET 8.0.1from.NET 8.0.0, and it doesn't seem that theMethodTablechanges were implemented in the runtime yet:I'll implement the corresponding changes in Novus once the CLR changes are implemented (as to not break Novus functionality).
cetio commentedon Jan 25, 2024
I assume custom builds may have problems, so maybe it's more of a niche thing, on that topic, do you plan on fleshing out Novus to support the different implementation flags in CoreCLR?
You have a small enough support structures list that reasonably it should be pretty easy to add conditional compilations.
Decimation commentedon Jan 25, 2024
Can you elaborate?
cetio commentedon Jan 25, 2024
CoreCLR uses a lot of implementation flags to conditionally have fields for stuff like profiling, debugging, COM, etc.
If you want to see just what most of these flags are, see this.
For example, the
CCWTemplatefield inEEClassas well as the union before it (with the delegate object handle or whatever, this is from memory I don't remember the exact name) are both conditionally compiled if the COM_INTEROP flag is set.This happens in a lot of CoreCLR structures, I think
MethodTablehas some debug fields,MethodDeschas a ton of debug fields, andEEClassalso has a random ushort debug field that does nothing.Decimation commentedon Jan 25, 2024
Ah, yeah that's what I thought you were referring to.
I certainly can, but I'm curious as to what information, metadata, or functionality can be attained from implementing support for CoreCLR implementation flags.
Novus isn't solely an experimental project/library. I use it in almost all of my other projects as a library. The CoreCLR interop is also utilized as an adapter/dependency for other project features such as
Meta...,Import...,Mem,RuntimeProperties,RuntimeResource, etc. Much of its architecture is tightly coupled with CoreCLR interop.For that reason, I would have to weigh the advantages of implementing such components against possible refactoring, collateral errors with other projects, etc.
Perhaps you could elaborate a bit further on potential implementation details and their advantages/disadvantages?
cetio commentedon Jan 26, 2024
There isn't necessarily any "benefit" to it, most of the metadata it provides would either not be useful or would almost never be exposed anyway.
It's more like would you rather hold a bomb that's pressure sensitive and could randomly explode, or a bomb with a fuse that may or may not randomly ignite, that's sorta how it is when it comes to exposing things you shouldn't really expose anyway. You should logically go to as many lengths as possible to try to prevent it from being actually super unstable, and implementation flags happen to be one of those things that can either invalidate your structure layout or totally ruin the stability of your project.
Not to say that it'd often cause instability but I've had C# devs up my ass about how there are loads of implementation details in CoreCLR that make it highly unstable to expose, and to remedy this you have to just add the implementation flags.
You don't lose anything except a bit of time by adding it and it makes your code more resilient because you don't have to bank on the flags always being that you assume to be the default, I doubt that in most cases it would have much of an impact, but it's better safe than sorry and makes your code more comprehensive I'd say.