C# stack allocation

[lakani]

Why can't we simply write the following sentence to define an object on the stack

Class a;
a.somemethod();

For sure its not that just simple as for sure, compiler needs to check any ref to a never get out of the scope, etc.....

[HaloFour]

I think you answered why the .NET runtime doesn't allow it. It's not even an option for C#, regardless of what syntax might make sense.

[CyrusNajmabadi]

compiler needs to check any ref to a never get out of the scope, etc.....

How does the compiler do that? The impl of someMethod (which can be in a different assembly) may just do exactly that.

[lakani]

compiler needs to check any ref to a never get out of the scope, etc.....

How does the compiler do that? The impl of someMethod (which can be in a different assembly) may just do exactly that.

someMethod must be compiled for sure using the new compiler flag (I'm assuming its a new flag), thus the new stack compiled assembly cab reference only assemplies built with that flag on,
And for sure the ordinary complied assemblies can reference all, so you won't broke any thing,

Sorry for my English

[HaloFour]

It'd require a lot more than a new compiler flag. It would require a concept of ownership and borrowing, baked into the runtime itself, and for all languages targeting the runtime to understand it. It would be an enormous amount of work and amount to splitting the ecosystem in two, fundamentally changing the design philosophy of all programs ever written for .NET. IMO it would never be worth the effort.

[CyrusNajmabadi]

someMethod must be compiled for sure using the new compiler flag (I'm assuming its a new flag), thus the new stack compiled assembly cab reference only assemplies built with that flag on,

The problem here, that always must be considered, is that the callee and caller may be recompiled at any time, independently.

So say the someMethod impl is recompiled l, and now escapes in its body. This breaks all downstream programs which man run against this new version, but which were never recompiled. :-)

Sorry for my English

Your English is great! :-). You've been very clear, and have been asking for questions. But this is a very very very difficult space, unless a ton of effort is done in multiple areas.

Note: this is a major reason why 'structs' (and variants like ref-structs) exist in the first place. So that author and consumer can indicate exactly the expected contract and can emit code accordingly.

[lakani]

So how rust compiler are able to?

[HaloFour]

Extremely different design philosophies. Rust's defining feature is ownership and borrowing ensuring that all code written for every object respects the lifecycle of that instance. The entire language is designed around that concept of memory safety, which is what allows for safe stack allocation. C# has no such concept and as a language it's assumed that any code can safely copy a reference and hold onto it. Plus Rust crates are typically compiled from source whereas dependencies in C# are typically compiled and opaque, so the compiler cannot reason about what a library might do with any given reference.

[jaredpar]

Even retrofitting C# with the concept of borrowing has a number of pitfalls. I wrote about them a few years ago here

https://blog.paranoidcoding.org/2019/12/02/borrowing.html

[hez2010]

There's nothing to do with the C# compiler. If the .net jit compiler can prove a doesn't escape, it can already allocate it on the stack, or even eliminate the allocation at all by promoting it to the register.

See https://godbolt.org/z/qvP855165 for the example. Although c is a class here, the compiled code ends up allocating nothing as the compiler managed to prove that c doesn't escape.

[AartBluestoke]

"If the .net jit compiler can prove a doesn't escape"
Is the entire problem. Even a print() call can theoretically leak its parameters via custom formatters.
Any call to any class that is not sealed can be overridden by a child class and capture the parameters.
Anything async might leak, anything that accesses static variables might leak.
If we could solve this then tail recursion, efficient recursive iterators, allocation free linq, and several other things could be progressed.

[huoyaoyuan]

Any call to any class that is not sealed can be overridden by a child class and capture the parameters.

This is incorrect. The majority of methods are non virtual. Otherwise, inlining will not be possible either. Anything suitable for inlining (even conditional) is suitable for escape analysis.

[lakani]

I know that escape analysis has been introduced into the run time, but what about aot

[hez2010]

NativeAOT uses the same compiler as the JIT, so both JIT and AOT share the same optimizations.

[full-ing-arr]

i inderstand, but we can do this way

struct Data {}
class A {
  ref Data data { get; init;}
}

ref var data = ref new Data( ... );
var a = new A() {
  data = data
}

but if we out of this scope, we lose data and it's main problem
ollso we can store data in long-live array on stack

NativeArray<Data> mydata = new ...
mydata[id] = data;

then

var a = new A() {
  data = ref mydata[id]
}

but problem in next, we need call

mydata.dispose()

at hand somewere

if u solve or find how use this more simplest use some c# suggar, it will be great