Runtime: JIT: Support object stack allocation

[erozenfeld]

This issue will track work on supporting object stack allocation in the jit. See dotnet/coreclr#20251 for the document describing the work.

The initial goal is to be able to remove heap allocation in a simple example like this:

class Foo
{
    public int f1;
    public int f2;
    public Foo(int f1, int f2)
    {
        this.f1 = f1;
        this.f2 = f2;
    }
}

class Test
{
    static int f1;
    static int f2;
    public static int Main()
    {
         Foo foo = new Foo(f1, f2);
         return foo.f1 + foo.f2;
    }
}

and then in a similar example where the class has gc fields.

Proposed initial steps are:

• [x] add getHeapClassSize jit interface method and its implementations dotnet/coreclr#20283
• [x] add canAllocateOnStack jit interface method and its implementations dotnet/coreclr#20283
• [x] modify getClassGCLayout jit interface method to work on reference types dotnet/coreclr#20814
• [x] add COMPlus_JitObjectStackAllocation environment variable to control this optimization (off by default) dotnet/coreclr#20814
• [x] move ObjectAllocator phase to be closer to inlining dotnet/coreclr#20377
• [x] modify lvaSetStruct to allow creating locals corresponding to stack-allocated classes dotnet/coreclr#20814
• [x] update types of references in methods with stack allocated objects to TYP_REF (when always pointing to the heap) or TYP_I_IMPL (when always pointing to the stack) or TYP_BYREF (when pointing to the heap or to the stack) dotnet/coreclr#21950
• [x] modify gc reporting to properly report gc fields of stack-allocated objects
• [x] modify gc writebarrier logic to apply appropriate barriers when assigning to fields of (possibly) stack-allocated objects dotnet/coreclr#21950
• [x] add simple conservative escape analysis sufficient for the example above dotnet/coreclr#20814
• [ ] make the analysis more sophisticated to handle increasingly more complex examples
• [ ] special case calls to helpers where arguments don't escape (this will require ensuring that the helpers report gc arguments as interior to gc)
• [ ] enable promotion of fields of stack-allocated objects
• [x] enable the optimization for x86 dotnet/coreclr#21950
• [ ] enable stack allocation of boxed structs
• [ ] enable stack allocation of constant-sized arrays
• [ ] enable stack allocation of strings
• [x] enable object stack allocation in R2R mode dotnet/coreclr#21533
• [ ] make sure object stack allocation doesn't block fast tail call optimization unnecessarily (currently fast tail call optimization is disabled if there are any locals with lvAddrExposed set)

I will be modifying and extending this list as the work progresses.

cc @dotnet/jit-contrib

category:cq
theme:object-stack-allocation
skill-level:expert
cost:extra-large

[jkotas]

add getObjHeaderSize jit interface method and its implementations

Why is this needed?

[erozenfeld]

We'll have to allocate space for ObjHeader before the stack-allocated object unless we can prove that it won't be needed for synchronization or hash code storage.

[jkotas]

needed for synchronization or hash code storage

I think using sychronization, etc. should prohibit stack allocation, for the initial iteration at least. Otherwise, you would also need a helper call to clear these objects from the synchronization tables and teach the synchronization tables to allow references to objects that do not live on the GC heap.

[mikedn]

modify lvaSetStruct to allow creating locals corresponding to stack-allocated classes
modify gc writebarrier logic to apply appropriate barriers when assigning to fields of (possibly) stack-allocated objects

How would stack allocated object fields would be accessed? Would existing FIELD/IND nodes be replaced with LCL_FLD/LCL_VAR nodes? Are writer barriers still needed if the object is allocated on stack?

[Suchiman]

What would be the point of trying to synchronize on a stackallocated object? If it's considered for stack allocation then it means it doesn't escape which means no other thread can attempt to synchronize on it so any attempts to do so should be a no-op. The hash code could be derived from it's stack address as the object won't move until its deallocated.

[erozenfeld]

We'll need to detect calls to RuntimeHelpers.GetHashCode on the stackallocated object. They will be problematic if we don't allocate ObjHeader before the object.

[erozenfeld]

modify lvaSetStruct to allow creating locals corresponding to stack-allocated classes
modify gc writebarrier logic to apply appropriate barriers when assigning to fields of (possibly) stack-allocated objects

How would stack allocated object fields would be accessed? Would existing FIELD/IND nodes be replaced with LCL_FLD/LCL_VAR nodes? Are writer barriers still needed if the object is allocated on stack?

Stack allocated object will be treated like a struct and its fields may be promoted. No write barriers are needed if we are assigning to a field of a stack-allocated object.

[erozenfeld]

We will have cases where we are assigning to a field of an object that may live on the stack or on the heap (e.g., at joins or when passing a stack allocated object to another method). We'll have to detect these cases and use checked write barriers.

[erozenfeld]

I suppose calls to RuntimeHelpers.GetHashCode will look like calls to native code so we will consider the object escaping and won't stack-allocate, so we don't need ObjHeader for that.

[erozenfeld]

dotnet/coreclr#20814 implemented an initial version of object stack allocation. I updated the items in the description of this issue to mark what's done and added more items to the road map.

[erozenfeld]

dotnet/coreclr#21950 added several improvements:
objects with gc fields can be stack allocated;
optimization is enabled on x86;
gc pointer reporting is less conservative when the method has stack-allocated objects.

[benaadams]

What would be the point of trying to synchronize on a stackallocated object? If it's considered for stack allocation then it means it doesn't escape which means no other thread can attempt to synchronize on it so any attempts to do so should be a no-op.

Call it a "lock elision" optimization and highlight it as a feature 😉 I think that's what Java does, unless I misunderstand what they do.

Equally could drop interlocked in objects that don't escape (where they operate on the object)?

[mikedn]

Call it a "lock elision" optimization and highlight it as a feature 😉 I think that's what Java does, unless I misunderstand what they do.

AFAIR the first Java collection classes were synchronized. Of course, they found out that this isn't such a great idea and their implementation of escape analysis was also trying to help by removing synchronization when the collection object wasn't escaping the stack.