Avoid per-instance lock object in InterruptibleLazy and DelayInitArrayMap

[auduchinok]

I've been measuring memory allocations on some my changes and found out that these sync objects retail a lot of memory due to usages like in ImportILTypeDef. This is a debatable change: it makes things more dangerous (an issue could be if someone locks on the lazy itself) but at the same it's an implementation detail inside the compiler which is fairly advanced, so I hope that it can be used responsibly.

[majocha]

The way System.Lazy does it is they clear the sync object field via null assignment as soon as the value is created, but it is a bit complicated.

[auduchinok]

The way System.Lazy does it is they clear the sync object field via null assignment as soon as the value is created, but it is a bit complicated.

Thanks for the suggestion! The problem is it still keeps the memory for that field, and for many thousands of types it's becoming a bit too much.

[auduchinok]

Here's an interesting discovery about how this PR overlaps with #20090:

syncObj is worth much less than its own branch measured, and that's expected. It gave −80.3 MB on FSharp.Common when addConstraintSources was importing all 107 K types (≈1 M InterruptibleLazy+syncObj pairs); with only ~35 K types imported there are proportionally fewer lock objects left, and the branch's own DelayInitValue already locks on this. Hence −14.3 MB here. The two wins overlap; they don't add.

[T-Gro]

🤖 This review was generated by AI (@expert-reviewer agent). Findings may contain inaccuracies — please verify independently.

The change is mechanically correct: the private constructor makes InterruptibleLazy effectively sealed, and both DelayInitArrayMap subclasses (ILMethodDefs, ILTypeDefs) are sealed and never lock on this, so there is no internal lock collision. GetDictionary also calls GetArray() before entering its own monitor, so there is no nested self-lock. The memory win is real and worthwhile. The only caveat is the general lock-on-this concern already noted in the PR description — see the inline comment.

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

[T-Gro]

It would really great if we could annotate a type that locks itself, and then have a scanner making sure such type is never the subject to lock or Monitor.Enter.

I am more afraid of future changes regressing this, I think a one-off analysis for current snapshot is fine here.