[design] Mono runtime components #49913
Conversation
|
Tagging subscribers to this area: @CoffeeFlux Issue DetailsVery alpha version. Everything is probably broken. See The code is a skeleton of the runtime support, and one mocked up component (that doesn't do anything). The plan is to keep improving this until it's barely functional.
|
|
/cc @lateralusX - decided to open a draft PR for the branch. @steveisok Once we have some idea of what the static and dynamic versions of the components look like, I will need help drafting the packaging story |
|
/cc @akoeplinger |
|
|
||
| With static linking, all the present components are statically linked with the runtime into the final app. | ||
|
|
||
| Each component exposes a table of functions to the runtime. The stubs also implement the same table. In the places |
There was a problem hiding this comment.
This is similar to the local GC work done several years ago and something I'd like to do with interop in some capacity. Is there a reason this isn't a general .NET runtime design that both implementations can starting working towards?
There was a problem hiding this comment.
It depends on the goals, what scenarios does it make better. It would be good to have the goals and scenarios written down in this doc.
The primary goal for local GC was to make it possible for an app to bundle a GC with bug fix or performance improvement, without affecting global state of the machine. It was addressing a real challenge we had with iterating on GC fixes and improvements with large 1st party customers - the 1st party customers were very hesitant to deploy a .NET Framework patch to test it on a production machines (and these patches were very non-trivial to produce).
Local GC is less valuable now than it was in .NET Framework word. .NET Core supports allows bundling the whole runtime with the app that addresses the primary scenario as well. If we were to do the local GC again today, there is a good chance it would be way below the cut line and it would never get funded.
Link it into monosgen-shared and monosgen-static. This is needed by the "mono components" prototype dotnet#49913 so that each dynamic component could statically link its own version of eglib operations (and we will do followup work to move the ones that use global state, like the logging operations, to be in monosgen-{shared,static} only)
lambdageek
force-pushed
the
delta-components
branch
from
af8e756
to
8b33010
Compare
lambdageek
changed the title
lambdageek
force-pushed
the
delta-components
branch
from
5a6a8b5
to
672d4a7
Compare
|
/cc @lateralusX @vargaz Updated the design doc to match #50837. Aside from the packaging, I think the design is at a point where it can be reviewed. |
lambdageek
force-pushed
the
delta-components
branch
from
9487865
to
b5fe617
Compare
| ## High level overview | ||
|
|
||
| Each component is defined in `src/mono/mono/components`. | ||
|
|
There was a problem hiding this comment.
Is it really necessary to add a subdirectory for this ?
There was a problem hiding this comment.
It's not necessary, but I thought it made it clearer that components are meant to be optional
Link it into monosgen-shard and monosgen-static. This is needed by the "mono components" prototype dotnet#49913 so that each dynamic component could statically link its own version of eglib operations (and we will do followup work to move the ones that use global state, like the logging operations, to be in one place only)
ghost
locked as resolved and limited conversation to collaborators
Initial version of
docs/design/mono/components.md. Primarily focused on scenarios and workloads, and code organization.An attempt to move EventPipe to a component is in #50837