runtime

runtime copied to clipboard

A document describing CLR memory model.

Closes:https://github.com/dotnet/runtime/issues/63474

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

https://github.com/dotnet/runtime/tree/main/docs/design/specs may be better location for this doc. It is not CoreCLR specific (botr is generally CoreCLR specific) and it augments ECMA spec (augments of ECMA spec live under docs/design/specs).

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details

---

A document describing CLR memory model.

Closes:https://github.com/dotnet/runtime/issues/63474

Author:	VSadov
Assignees:	VSadov
Labels:	area-Meta, memory model
Milestone:	-

@dotnet/jit-contrib FYI

@BrzVlad could you take a look

This pull request has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

@VSadov I think it would be a good idea to merge this doc even though if it is not 100% finished. Could you please mark the few places with open questions, and address any remaining feedback?

@jkotas Yes, I was going to ask the same question. I think there are couple questions (like provide some details/examples in couple places), but otherwise there is nothing major and actionable.

I will go through the feedback once more, address remaining questions and I think we can wrap this up. We can always add to this if something comes up.

@jkotas - I think I addressed all the remaining actionable feedback. Could you take a quick look? and I think we can merge if nothing needs changing.

I believe that we have identified a few open questions where we are not sure about the current CoreCLR JIT being compliant with what's written in the doc and we are not sure about the cost to make it compliant. (@markples has a work item to investigate one of them.) Can we mention them in the doc?

@jkotas There was a concern about compiler optimization honoring ordering of data-dependent reads (and writes to object fields to a lesser degree). We expect that from the hardware (for writes we insert fences if needed). The question was whether compiler itself may violate such ordering in some optimizations and whether it is costly to prevent that if it does. I think the concern was mostly about reads as writing has obvious sideeffects, which limits what optimizations can do.

Preliminary conclusion was that compiler honors data dependency because the internal representations are tree-based. @markples was going to confirm for sure and experiment with intentional enforcing, but I assumed that data dependency is observed, at least in non-corner cases, so I just wrote that in + added example of illegal optimization that came up in discussions. (around line 117, I think)

If that does not hold, we will fix the compiler, ... or the document. I hope it just holds. At very least it would be unintuitive. I will log an issue to not forget to clear this up.

If that does not hold, we will fix the compiler

We should also make sure that this holds for Mono LLVM-based codegen.

@jkotas - the issue to follow up on data dependency and compiler optimizations. https://github.com/dotnet/runtime/issues/79764

Could you please include a link in the doc?

Thanks!!!