Please let "stackalloc" be safe code and allow initialization to follow it

[ygc369]

For example:
int a[]=stackalloc int[]{0,1,2,3};//a[0]=0,a[1]=1,a[2]=2,a[3]=3

[GeirGrusom]

As far as I know, the C# compiler will actually use stackalloc if it feels it is appropriate on arrays, so I don't think allowing a safe version of stackalloc will give any sort of performance boost. The usefulness of stackalloc is more when dealing with unsafe code in an unsafe context.

edit: seems I was misinformed. I cannot reproduce any such behavior.

[HaloFour]

Under what circumstances would this be useful? The result of stackallloc is not a .NET array and it couldn't be assigned to any variable expecting an array. It compiles down to the CIL instruction localloc which explicitly returns a pointer, unsafe by definition. The compiler might be able gloss over that locally if you're using fixed indexes but you won't have bounds checking.

[GSPP]

The C# compiler does not allocate any ref type on the stack right now. Neither does the JIT (unfortunately!).

This should not be a language feature but a JIT optimization. Escape analysis should show that the array does not escape the current stack frame.

[mirhagk]

stackalloc itself should remain as is, because I don't think developers should ever have to worry about it. But localloc or something similar should be made safe so that the compiler can optimize it. localloc also needs to be made MUCH faster (last I looked into it it did some weird things for allocating and ended up nearly always being slower, even in the simple case of allocate then go away and even compared to garbage collection).

@GSPP I agree that it should not be a language feature but I do not think it should be a JIT optimization, it should be done by the compiler. Really good escape analysis is probably too much work to be done JIT and the original C# compiler knows more about the code anyways.

In a general case I think there needs to be a way for the C# compiler to signify performance tips to the JIT compiler, which may or may not be used (sorta similar to MethImpl attributes, but it needs to be something that can be attached to any IL instruction). There's just so much work that the high level compilers already do, and it can also afford to spend more time on the analysis. Make the high level compilers focus on understand the code, and the JIT compiler focus on understanding the system trade-offs.

[GSPP]

@mirhagk the JIT cannot trust the compiler to allocate ref types on the stack. If the compiler is malicious it could subvert the type system. We simply need a flag to tell the JIT to spend more time. For many web apps startup time is irrelevant because deployments are done by switching endpoints. No interruption.

And certainly the new VC++ based AOT compiler can do this. Or the new LLVM-based JIT.

[mirhagk]

Well any work that the compiler does can be verified by the JIT compiler if the JIT compiler does not trust the code. Since these would be "tips" the JIT does not need to actually perform it if it doesn't trust the code and can't easily verify that it's okay.

I'm also thinking in the .NET native case. There are some things that are probably not possible to determine from CIL alone, and when you have a tight loop and control both the compiler and the assembler it'd be nice to call .NET native with a flag instructing it that it can feel free to do these tips without verification since you trust it.

EDIT: I assume that .NET native is being used in the process of a company/organization/programmer creating their own binaries to release to others. Obviously .NET native running in the context of win phone would not pass the flag allowing unsafe tips

[ygc369]

If C# language can provide a safe version of stackalloc, it should also provide a new safe type ---- array on stack(like this:#126). If there is any difficulty to provide a safe version of stackalloc, C# language should at least allow initialization to follow the unsafe version.

[ygc369]

Many people focus on a safe version of stackalloc, but before that, please consider to allow initialization to follow the unsafe version first, which is easier to realize.