From @benaadams on Monday, January 23, 2017 10:30:43 AM

Saw this while doing some disassembling https://github.com/dotnet/coreclr/issues/9039 where assigning to StringValues

G_M28429_IG07:
       48B94096F52B5C020000 mov      rcx, 0x25C2BF59640
       488B09               mov      rcx, gword ptr [rcx]
       488BD5               mov      rdx, rbp
       41B805000000         mov      r8d, 5
       E822ADF95A           call     String:Equals(ref,int):bool:this
       85C0                 test     eax, eax
       0F8427080000         je       G_M28429_IG40
       48814B2800000800     or       qword ptr [rbx+40], 0x80000
       488DBB80010000       lea      rdi, bword ptr [rbx+384]
       E89667AE5F           call     CORINFO_HELP_ASSIGN_BYREF
       E89167AE5F           call     CORINFO_HELP_ASSIGN_BYREF
       E942080000           jmp      G_M28429_IG41

It does a double reference assign + write barrier CORINFO_HELP_ASSIGN_BYREF.

Also it means data structures like FrameRequestHeaders.HeaderReferences is 688 bytes and FrameResponseHeaders.HeaderReferences is 592 bytes; so clearing needs to Memset quite a large amount of data; and Kestrel has a "faster" path where under 12 headers it does a bit count; then steps though all the headers checking if they are set and clearing them (with early bail)

The double ptr struct field also causes knock on issues like "FrameRequestHeaders:AppendNonPrimaryHeaders uses (and zeros) 888 bytes of stack" aspnet/KestrelHttpServer#1317 (issue in coreclr https://github.com/dotnet/coreclr/issues/9041)

An example of how this could be done is: benaadams/extensions@0b567e9; however there are knock on issues around foreach vs for patterns and I haven't confirmed it would be a net win, so am not making a PR for this at this time.

Copied from original issue: dotnet/extensions#185