Improvements for object stack allocation. #21950

erozenfeld · 2019-01-11T02:23:09Z

This change enables object stack allocation for more cases:

Objects with gc fields can now be stack-allocated.
Object stack allocation is enabled for x86.

ObjectAllocator updates the types of trees containing references
to possibly-stack-allocated objects to TYP_BYREF or TYP_I_IMPL as appropriate.
That allows us to remove the hacks in gcencode.cpp and refine reporting of pointers:
the pointer is not reported when we can prove that it always points to a stack-allocated object or is null (typed as TYP_I_IMPL);
the pointer is reported as an interior pointer when it may point to either a stack-allocated object or a heap-allocated object (typed as TYP_BYREF);
the pointer is reported as a normal pointer when it points to a heap-allocated object (typed as TYP_REF).

ObjectAllocator also adds flags to indirections:
GTF_IND_TGTANYWHERE when the indirection may be the heap or the stack
(that results in checked write barriers used for writes)
or the new GTF_IND_TGT_NOT_HEAP when the indirection is null or stack memory
(that results in no barrier used for writes).

erozenfeld · 2019-01-11T02:24:41Z

x64 PMI diffs with #21944 applied to both base and diff and object stack allocation enabled in both base and diff:

PMI Diffs for System.Private.CoreLib.dll, framework assemblies for  default jit
Summary:
(Lower is better)
Total bytes of diff: -2225 (-0.01% of base)
    diff is an improvement.
Top file regressions by size (bytes):
         154 : Microsoft.DotNet.ProjectModel.dasm (0.07% of base)
          88 : xunit.execution.dotnet.dasm (0.04% of base)
          67 : System.Net.Http.dasm (0.01% of base)
          50 : Microsoft.Diagnostics.Tracing.TraceEvent.dasm (0.00% of base)
          34 : System.Private.Xml.dasm (0.00% of base)
Top file improvements by size (bytes):
       -1870 : System.Threading.Tasks.Dataflow.dasm (-0.30% of base)
        -421 : System.Private.DataContractSerialization.dasm (-0.05% of base)
        -277 : Microsoft.CodeAnalysis.VisualBasic.dasm (0.00% of base)
         -80 : NuGet.Configuration.dasm (-0.15% of base)
         -14 : System.Linq.Parallel.dasm (0.00% of base)
15 total files with size differences (7 improved, 8 regressed), 114 unchanged.
Top method regressions by size (bytes):
         154 ( 4.28% of base) : Microsoft.DotNet.ProjectModel.dasm - ProjectReader:ReadProject(ref,ref,ref,ref):ref:this
          51 ( 2.44% of base) : System.Private.Xml.dasm - XslAstRewriter:Refactor(ref,int):this
          50 ( 8.00% of base) : xunit.execution.dotnet.dasm - <>c__DisplayClass26_0:<Find>b__0():this
          46 ( 1.21% of base) : Microsoft.Diagnostics.Tracing.TraceEvent.dasm - TraceEventSession:EnableProvider(struct,int,long,ref):bool:this
          38 (11.73% of base) : xunit.execution.dotnet.dasm - <>c__DisplayClass28_0:<Find>b__0():this
Top method improvements by size (bytes):
        -189 (-14.12% of base) : System.Threading.Tasks.Dataflow.dasm - TransformBlock`2:get_DebuggerDisplayContent():ref:this (5 methods)
        -189 (-14.12% of base) : System.Threading.Tasks.Dataflow.dasm - TransformManyBlock`2:get_DebuggerDisplayContent():ref:this (5 methods)
        -148 (-12.52% of base) : System.Threading.Tasks.Dataflow.dasm - BroadcastBlock`1:get_DebuggerDisplayContent():ref:this (5 methods)
         -93 (-19.25% of base) : Microsoft.CodeAnalysis.VisualBasic.dasm - MethodCompiler:GetEntryPoint(ref,ref,ref,struct):ref
         -92 (-8.03% of base) : Microsoft.CodeAnalysis.VisualBasic.dasm - LocalRewriter:VisitForEachStatement(ref):ref:this
Top method regressions by size (percentage):
          38 (11.73% of base) : xunit.execution.dotnet.dasm - <>c__DisplayClass28_0:<Find>b__0():this
          25 ( 9.69% of base) : System.Private.DataContractSerialization.dasm - DataContractJsonSerializerImpl:.ctor(ref,ref):this (2 methods)
          50 ( 8.00% of base) : xunit.execution.dotnet.dasm - <>c__DisplayClass26_0:<Find>b__0():this
          13 ( 5.88% of base) : System.Security.Cryptography.X509Certificates.dasm - ECDsaCertificateExtensions:HasECDsaKeyUsage(ref):bool
          12 ( 5.56% of base) : System.Private.DataContractSerialization.dasm - DataContractSerializer:.ctor(ref,ref):this (2 methods)
Top method improvements by size (percentage):
         -18 (-32.14% of base) : System.Threading.Tasks.Dataflow.dasm - BroadcastBlock`1:get_ValueForDebugger():int:this
         -18 (-31.58% of base) : System.Threading.Tasks.Dataflow.dasm - BroadcastBlock`1:get_ValueForDebugger():long:this
         -18 (-29.51% of base) : System.Threading.Tasks.Dataflow.dasm - BroadcastBlock`1:get_ValueForDebugger():double:this
         -72 (-28.02% of base) : System.Threading.Tasks.Dataflow.dasm - BroadcastBlock`1:get_HasValueForDebugger():bool:this (5 methods)
         -90 (-25.35% of base) : System.Threading.Tasks.Dataflow.dasm - TransformBlock`2:get_OutputCountForDebugger():int:this (5 methods)
72 total methods with size differences (53 improved, 19 regressed), 193309 unchanged.

erozenfeld · 2019-01-11T02:24:56Z

No diffs with object stack allocation disabled.

erozenfeld · 2019-01-11T02:27:09Z

Some of the regressions are due to stack offset changes after moving allocations from the heap to the stack. For example, on x64
mov qword ptr [rbp-80H], rax is 4 bytes while mov qword ptr [rbp-B0H], rax is 7 bytes.

erozenfeld · 2019-01-11T02:28:22Z

src/jit/jitconfigvalues.h

@@ -349,7 +349,7 @@ CONFIG_STRING(JitInlineReplayFile, W("JitInlineReplayFile"))
 #endif // defined(DEBUG) || defined(INLINE_DATA)

 CONFIG_INTEGER(JitInlinePolicyModel, W("JitInlinePolicyModel"), 0)
-CONFIG_INTEGER(JitObjectStackAllocation, W("JitObjectStackAllocation"), 0)
+CONFIG_INTEGER(JitObjectStackAllocation, W("JitObjectStackAllocation"), 1)



I will not be merge this change. I'd like to run some ci testing with object stack allocation enabled. I'll revert this change before merging.

erozenfeld · 2019-01-11T02:28:50Z

@AndyAyersMS @echesakovMSFT @dotnet/jit-contrib PTAL

erozenfeld · 2019-01-11T02:39:17Z

Example of a good diff (BroadcastBlock``1:get_HasValueForDebugger():bool:this from System.Threading.Tasks.Dataflow.dll):

G_M19268_IG01:
-     push     rdi
-     push     rsi
-     sub      rsp, 40
+     sub      rsp, 24
+     xor      rax, rax
+     mov      qword ptr [rsp+10H], rax

G_M19268_IG02:
-     mov      rsi, gword ptr [rcx+8]
+     mov      rax, gword ptr [rcx+8]
-     mov      ecx, dword ptr [rsi]
-     mov      rcx, 0xD1FFAB1E
-     call     CORINFO_HELP_NEWSFAST
-     mov      rdi, rax
-     lea      rcx, bword ptr [rdi+8]
-     mov      rdx, rsi
-     call     CORINFO_HELP_ASSIGN_REF
-     mov      rax, gword ptr [rdi+8]
+     mov      rdx, rax
+     mov      edx, dword ptr [rdx]
+     xor      rdx, rdx
+     lea      rcx, bword ptr [rsp+08H]
+     mov      qword ptr [rcx], rdx
      mov      eax, dword ptr [rax+96]

G_M19268_IG03:
-     add      rsp, 40
+     add      rsp, 24
-     pop      rsi
-     pop      rdi

-; Total bytes of code 56, prolog size 6 for method BroadcastBlock`1:get_ValueForDebugger():int:this
+; Total bytes of code 38, prolog size 11 for method BroadcastBlock`1:get_ValueForDebugger():int:this

AndyAyersMS

Overall this looks good -- nice to see it rounding into shape.

Left you a two small notes.

AndyAyersMS · 2019-01-11T02:59:16Z

src/jit/objectalloc.cpp

+                    {
+                        tree->ChangeType(newType);
+                    }
+                    lclVarDsc->lvType = newType;


Suggest you sink this update out of both then/else and add a JITDUMP message describing the change.

AndyAyersMS · 2019-01-11T03:02:20Z

src/jit/objectalloc.cpp

@@ -321,6 +392,8 @@ bool ObjectAllocator::MorphAllocObjNodes()

                    const unsigned int stackLclNum = MorphAllocObjNodeIntoStackAlloc(asAllocObj, block, stmt);
                    m_HeapLocalToStackLocalMap.AddOrUpdate(lclNum, stackLclNum);
+                    MarkLclVarAsDefinitelyStackPointing(lclNum);
+                    MarkLclVarAsPossiblyStackPointing(lclNum);


Can you add a note here and/or elsewhere that the possibly stack pointing set is kept as a superset of the definitely stack pointing set (and a local is in both it is definitely stack pointing).

AndyAyersMS · 2019-01-11T03:04:13Z

src/jit/objectalloc.cpp

+                    MarkLclVarAsPossiblyStackPointing(lclNum);
+
+                    // Check if this pointer always points to the stack.
+                    if (lclVarDsc->lvSingleDef == 1)


We should really get around to writing a checker for the early meaning of lvSingleDef someday. I think the upstream phases maintain it, but ...

erozenfeld · 2019-01-11T22:25:28Z

@AndyAyersMS I addressed your feedback and added a couple of small fixes for issues found in x86 testing. PTAL.

erozenfeld · 2019-01-12T00:09:31Z

@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test

This change enables object stack allocation for more cases. 1. Objects with gc fields can now be stack-allocated. 2. Object stack allocation is enabled for x86. ObjectAllocator updates the types of trees containing references to possibly-stack-allocated objects to TYP_BYREF or TYP_I_IMPL as appropriate. That allows us to remove the hacks in gcencode.cpp and refine reporting of pointers: the pointer is not reported when we can prove that it always points to a stack-allocated object or is null (typed as TYP_I_IMPL); the pointer is reported as an interior pointer when it may point to either a stack-allocated object or a heap-allocated object (typed as TYP_BYREF); the pointer is reported as a normal pointer when it points to a heap-allocated object (typed as TYP_REF). ObjectAllocator also adds flags to indirections: GTF_IND_TGTANYWHERE when the indirection may be the heap or the stack (that results in checked write barriers used for writes) or the new GTF_IND_TGT_NOT_HEAP when the indirection is null or stack memory (that results in no barrier used for writes).

erozenfeld · 2019-01-13T04:39:16Z

@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test

erozenfeld · 2019-01-14T18:42:09Z

@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test

erozenfeld · 2019-01-14T19:09:36Z

@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test

AndyAyersMS · 2019-01-14T19:10:34Z

The Tizen leg is broken (and now, removed) so you might as well ignore it.

echesakov · 2019-01-15T00:47:01Z

tests/src/JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests.cs

        {
            object o = (f1 == 0) ? (object)new SimpleClassB(f1, f2) : (object)new SimpleClassA(f1, f2);
-            return (o is SimpleClassB) || !(o is SimpleClassA) ? 0 : 1;
+            GC.Collect();
+            return !(o is SimpleClassA) ? 0 : 1;


I bet there should be a reason why you prefered this over (o is SimpleClassA) ? 1 : 0

It's the result of refactoring the previous version of the test. I didn't bother simplifying this.

ygc369 · 2020-03-27T13:36:17Z

@erozenfeld
What's the progress of stack allocation project? Is it dead? Or will it be merged into next version of CLR?

erozenfeld · 2020-03-30T01:43:36Z

We have support for object stack allocation merged but off by default. It can be turned on by setting COMPlus_JitObjectStackAllocation=1. It currently can allocate objects on the stack only in simple cases because arguments to any calls are assumed to be escaping. We need interprocedural escape analysis to make object stack allocation possible in more cases. We are not currently working on it but it's on the table in our longer term planning.

erozenfeld · 2020-03-30T01:45:44Z

dotnet/runtime#11192 is a tracking issue for object stack allocation.

NinoFloris · 2020-04-16T18:29:08Z

@erozenfeld any background to off being the default?

Even the simplest version will definitely help F# code which creates a lot more superfluous tuples, optionals and such.

AndyAyersMS · 2020-04-16T19:31:13Z

@NinoFloris if you can point us at specific examples that would be helpful.

More broadly, we are looking for some of F# performance tests -- for example, to help us better evaluate some of the tradeoffs in dotnet/runtime#341.

erozenfeld · 2020-04-16T19:35:00Z

@NinoFloris The escape analysis is not free in terms of jit speed and we can't justify having it on if it almost never results in actual object stack allocation. And yes, if you have great F# examples where this analysis is sufficient and stack allocation candidates are not passed as arguments, please send them our way.

NinoFloris · 2020-04-17T16:05:34Z

I have linked to some cases, generally the F# compiler can automatically inline local functions or functions explicitly marked inline. However the optimizer is not advanced enough to erase the allocations of Options/Tuples/RefCells once they're all in the same body, this is where object stack alloc would be helpful.

I'm also hoping to see if I can (and OK'ed to) make some changes in that area in the compiler instead.

erozenfeld · 2020-04-17T19:28:49Z

Thank you @NinoFloris ! I'll take a look at these issues sometime next week.

ygc369 · 2020-04-18T00:53:37Z

@erozenfeld
I know that doing escape analysis during JIT is very hard, because JIT time must be very short, JIT compiler can't do too much analysis, but escape analysis is very complex and can't be done within a very short time. So it is very difficult to make a tradeoff. Then why not just introduce escape analysis in AOT compiler? AOT does not care about compiling time, it can do as much analysis as possible.
I think that before finding a good way to do escape analysis during JIT, a full escape analysis should be added to the .NET AOT(R2R) compiler firstly at least, and should be "on" by default.

erozenfeld · 2020-04-18T01:01:01Z

.NET AOT compilers (crossgen and crossgen2) use the jit to compile individual methods. Neither one currently does whole-program optimizations. We have some long-term plans to look into adding whole-program optimizations to crossgen2 and did some prototyping. Escape analysis is one of the optimizations we will consider. The way I envision this is crossgen2 will do compilation in bottom-up call graph order (callees before callers) and will record escape info for method parameters. That info can be used when compiling callers to determine which args can escape.

erozenfeld commented Jan 11, 2019

View reviewed changes

erozenfeld requested review from AndyAyersMS and echesakov January 11, 2019 02:28

AndyAyersMS reviewed Jan 11, 2019

View reviewed changes

erozenfeld force-pushed the RetypeStackPointingRefs branch from 45c257d to a377055 Compare January 11, 2019 22:22

AndyAyersMS approved these changes Jan 11, 2019

View reviewed changes

erozenfeld force-pushed the RetypeStackPointingRefs branch from a377055 to 01731f7 Compare January 13, 2019 03:04

echesakov reviewed Jan 15, 2019

View reviewed changes

echesakov approved these changes Jan 15, 2019

View reviewed changes

erozenfeld merged commit f2d3dfe into dotnet:master Jan 15, 2019

erozenfeld deleted the RetypeStackPointingRefs branch January 15, 2019 01:33

erozenfeld mentioned this pull request Jan 15, 2019

Re-enable ObjectStackAllocationTests for arm32 #21539

Merged

erozenfeld mentioned this pull request Jan 31, 2020

JIT: Support object stack allocation dotnet/runtime#11192

Closed

20 tasks

sandreenko mentioned this pull request Jan 31, 2020

[x64[r2r] ObjectStackAllocationTests is broken after #21950 dotnet/runtime#11826

Closed

This was referenced Apr 17, 2020

[Optimization] Compiler creates branches with allocs that can never be hit dotnet/fsharp#8983

Open

[Optimization] Detuple branch results dotnet/fsharp#8953

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improvements for object stack allocation. #21950

Improvements for object stack allocation. #21950

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019 •

edited

Loading

AndyAyersMS left a comment

AndyAyersMS Jan 11, 2019

AndyAyersMS Jan 11, 2019

AndyAyersMS Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 12, 2019

erozenfeld commented Jan 13, 2019

erozenfeld commented Jan 14, 2019

erozenfeld commented Jan 14, 2019

AndyAyersMS commented Jan 14, 2019

echesakov Jan 15, 2019

erozenfeld Jan 15, 2019

ygc369 commented Mar 27, 2020

erozenfeld commented Mar 30, 2020

erozenfeld commented Mar 30, 2020

NinoFloris commented Apr 16, 2020

AndyAyersMS commented Apr 16, 2020

erozenfeld commented Apr 16, 2020

NinoFloris commented Apr 17, 2020 •

edited

Loading

erozenfeld commented Apr 17, 2020

ygc369 commented Apr 18, 2020

erozenfeld commented Apr 18, 2020

Improvements for object stack allocation. #21950

Improvements for object stack allocation. #21950

Conversation

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019

erozenfeld Jan 11, 2019

Choose a reason for hiding this comment

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 11, 2019 • edited Loading

AndyAyersMS left a comment

Choose a reason for hiding this comment

AndyAyersMS Jan 11, 2019

Choose a reason for hiding this comment

AndyAyersMS Jan 11, 2019

Choose a reason for hiding this comment

AndyAyersMS Jan 11, 2019

Choose a reason for hiding this comment

erozenfeld commented Jan 11, 2019

erozenfeld commented Jan 12, 2019

erozenfeld commented Jan 13, 2019

erozenfeld commented Jan 14, 2019

erozenfeld commented Jan 14, 2019

AndyAyersMS commented Jan 14, 2019

echesakov Jan 15, 2019

Choose a reason for hiding this comment

erozenfeld Jan 15, 2019

Choose a reason for hiding this comment

ygc369 commented Mar 27, 2020

erozenfeld commented Mar 30, 2020

erozenfeld commented Mar 30, 2020

NinoFloris commented Apr 16, 2020

AndyAyersMS commented Apr 16, 2020

erozenfeld commented Apr 16, 2020

NinoFloris commented Apr 17, 2020 • edited Loading

erozenfeld commented Apr 17, 2020

ygc369 commented Apr 18, 2020

erozenfeld commented Apr 18, 2020

erozenfeld commented Jan 11, 2019 •

edited

Loading

NinoFloris commented Apr 17, 2020 •

edited

Loading