[FeatureRequest]: Support edits to FieldRVAs in the runtime for EditAndContinue/etc.

[phil-allen-msft]

With the merge of dotnet/roslyn#76036, there will be a much more common way to generate FieldRVA edits as part of HotReload as its anticipated that many of the strings to modify in a Razor project will be the content of the razor file (<tr><td>@someVar</td></tr> would be 2 literal strings; changing to divs would be new utf8 strings, which use FieldRVAs). Having those edits to FieldRVAs be supported at the runtime level means that EditAndContinue/HotReload of Razor, in the presence of utf8 strings, would work for customers.

Currently updating FieldRVA table is not supported. For this feature to work (and also other features that emit FieldRVA, such as UTF8 strings, initialized arrays, etc.) we need to be able to express FieldRVA updates in EnC delta metadata.

An RVA value is effectively an offset (relative virtual address) in the loaded PE image. As such it has no meaning in EnC delta metadata since the delta is not a PE Image.

However, we can reserve a block in the #Blob heap of the EnC metadata section and store the values there. A value of FieldRVA table field would then mean an offset within the blob heap.

When the runtime encounters FieldRVA table update in EnC delta it would copy the value from the delta #Blob heap to a runtime structure that it can later access when executing code that's loading the data.

UPDATE:

We can repurpose delta IL stream to store FieldRVA blobs. Method table in EnC delta already has a concept of RVA pointing to IL offset stream. FieldRVA would point to the IL stream as well.

[jkotas]

Method metadata has pointers to IL code as RVAs today. There is established pattern to encode these RVAs and IL code in the EnC payload. The scheme does not require reserving arbitrary space in the image.

Would it make more sense to encode the field RVAs the same way?

[tmat]

@jkotas IL stream delta is passed separately from metadata delta to the runtime. We would need to either

1. append it to this stream, which would confuse existing tools, or
2. add a new stream
   This would require new APIs across multiple tools and the runtime such as https://github.com/dotnet/runtime/blob/main/src/mono/System.Private.CoreLib/src/System/Reflection/Metadata/MetadataUpdater.cs#L29)

[jkotas]

append it to this stream, which would confuse existing tools

What are the existing tools? The IL stream is unstructured byte stream. You cannot do much with it unless you know where the method bodies start. There can be arbitrary junk between the method bodies.

[tmat]

@jkotas You are right. We do have tests that would get tripped off, but we can update our test infra. The tests simply expect the bodies to be next to each other - they just decode one after another. That said, the test infra needs improvements anyways. It'd be good to spend some time on making it better and avoid this assumption.

I agree now, it would make perfect sense to store the blobs to ILDelta. Will be just a bit odd to keep calling the stream IL delta in APIs, but that's ok.

[AaronRobinsonMSFT]

Will be just a bit odd to keep calling the stream IL delta in APIs, but that's ok.

@tmat It would be appreciated if you could share details offline on what this would look like within the stream. /cc @jkoritzinsky

[tmat]

@AaronRobinsonMSFT I think the blob format would be the same as on #Blob heap: data size in bytes (compressed unsigned int) followed by raw data.