Implement the "compact dispatch sections" optimization from CoreCLR's ComWrappers implementation in NativeAOT's implementation

[jkoritzinsky]

This will reduce memory usage for CCWs created using ComWrappers on NativeAOT. Also, by porting this optimization to NativeAOT, we can look at sharing code between CoreCLR and NativeAOT without losing perf.

[jkotas]

This will reduce memory usage for CCWs created using ComWrappers on NativeAOT.

We should validate that it is actually the case. I expect that NativeMemory.AlignedAlloc comes with some memory overhead, so we are assuming that this extra overhead is less than what this is saving.

[AaronRobinsonMSFT]

Also, by porting this optimization to NativeAOT, we can look at sharing code between CoreCLR and NativeAOT without losing perf.

I'm glad we are working to bring additional alignment and share code. Moving CoreCLR to use the same code is a non-goal at present and without understanding the impact to debugging I would push back on that effort. I realize this isn't necessarily germane to this specific PR, but merging this change should not be an indication to move forward on sharing the code between the two runtimes. Debugging some of these paths on CoreCLR is going to be significantly more difficult if this is in managed code.

[jkoritzinsky]

Also, by porting this optimization to NativeAOT, we can look at sharing code between CoreCLR and NativeAOT without losing perf.

I'm glad we are working to bring additional alignment and share code. Moving CoreCLR to use the same code is a non-goal at present and without understanding the impact to debugging I would push back on that effort. I realize this isn't necessarily germane to this specific PR, but merging this change should not be an indication to move forward on sharing the code between the two runtimes. Debugging some of these paths on CoreCLR is going to be significantly more difficult if this is in managed code.

I'm prototyping what it would look like to share code between CoreCLR and NativeAOT for ComWrappers. I agree that it's only worth doing if the debugging experience for us wouldn't suffer and there would be clean cut between what's in managed and what's in native code.

If after looking at where the boundary would be, we don't like it, we should close #77738 as "not planned".

[AaronRobinsonMSFT]

If after looking at where the boundary would be, we don't like it, we should close #77738 as "not planned".

Agree.

[jkoritzinsky]

Here's the numbers from when @AaronRobinsonMSFT moved CoreCLR to use this model: #77302

I'll change the allocation to match the model that CoreCLR uses so the numbers can be applicable here as well.

[jkotas]

moved CoreCLR to use this model: #77302

These look like microbenchmark numbers. I would be interested in the numbers for a real app, like the Windows Store app.

[Sergio0694]

Happy to work with @jkoritzinsky and help get perf profiles or anything else, if needed 🙂

[jkoritzinsky]

@jkotas, @Sergio0694 tested this change in the Microsoft Store and saw a 1.2% memory usage reduction with this change.

[jkoritzinsky]

/ba-g failures unrelated