Reading through the JEP again it does not seem to be related - it is about deprecating unsafe APIs that the executed code itself uses. OpenJDK also has "partial escape analysis" where the object that only conditionally escapes can still be placed on the stack/scalar replaced.

I'm not privy to the exact APIs that OpenJDK exposes but in .NET the main limitation around escape analysis that spans multiple methods is the fact that CoreCLR has re-JIT API which allows to perform a multitude of actions like attaching a profiler or a debugger to a live application and forcing the runtime to deoptimize a particular method for debugging, or modifying the implementation and re-JITting the result. Debug codegen is very different especially around GC liveness tracking and escape analysis that builds on top of it - it means that even debug code would have to uphold stack-allocated nature of such object in some way, complicating the design significantly. In addition to that, debuggers and other instrumentation may observe object references that would have otherwise not escaped local scope.

This creates an unfortunate situation where the above almost never happens in production, but ignoring it and "just stack-allocating anyway" would lead to disastrous breakage for all sorts of existing instrumentation. Because Go does not have to deal with this constraint, it can perform interproc escape analysis without risk - whether a pointer escapes or not can be statically proven. For NativeAOT, .NET could approach this problem in the same way, but paraphrasing compiler team: "We would like to avoid optimizations only available for one of the target types be it JIT or AOT, and only supporting AOT would not benefit the majority of the .NET users".

There is, however, recognition that more comprehensive interproc analysis could be very beneficial, including the EA which is why it is planned to work on it in .NET 10:

- https://github.com/dotnet/runtime/issues/108931 IPA framework

- https://github.com/dotnet/runtime/issues/104936 Stack allocation enhancements

Integrity by default is what the OpenJDK folks are pushing for so that any API that can break runtime assumptions, has to be explicitly allowed, so that they can actually make use of performance optimizations that would otherwise be too risky if anyone at any time could violate them.

Yeah there's a JEP around deprecating access to sun.misc.Unsafe, but that's part of a larger effort including Jigsaw to push the Java ecosystem in the direction of modular builds, where more invariants are assumed to hold (e.g. " 'final' fields are actually final") unless explicitly opted out for each module. I would assume the lack of such guarantees in the status quo wreaks a lot of havoc with EA.

Profiling and debugging would be separate considerations -- I'm really not sure what limitations those impose on the JVM JIT.