Major compiler slowdown due to changes in .NET GC between .NET 7 preview2 and .NET 7 preview3

Build.cmd -c Debug is getting stuck for some time (5+ minutes on my local machine) on generating tables:

          327 shift/reduce conflicts
          393 reduce/reduce conflicts
          consider setting precedences explicitly using %left %right and %nonassoc on terminals and/or setting explicit precedence on rules using %prec
  writing tables to log
          1881 states
          326 nonterminals
          205 terminals
          1087 productions
          #rows in action table: 1881

I’ve seen reports of this from other people, we should investigate. Can reproduce it roughly every other clean build.

Update 1: Also, after terminating the build, and doing it again (without cleaning), it is stuck here for about 10 minutes already:

  FSharp.DependencyManager.Nuget -> C:\Users\vlza\code\fsharp\artifacts\bin\FSharp.DependencyManager.Nuget\Proto\netstandard2.0\FSharp.DependencyManager.Nuget.dll

Update 2: From the dump, it appears it spends a lot of time here:

C:\Users\vlza\code\fsharp\.dotnet\dotnet.exe  "C:\Users\vlza\code\fsharp\.dotnet\sdk\7.0.100-preview.7.22377.5\FSharp\fsc.dll" @"C:\Users\vlza\AppData\Local\Temp\tmp1a940496fb5f480798d2a8cccb94abe4.rsp"

[dsyme]

@En3Tho I’d advise against analysing too much at this stage. Whatever else, the GC was handling this application (the F# compiler) beautifully before and it seems to me that simply too much has changed in the GC and much more caution is now needed - in particular there has to be an easy fallback to get the old characteristics, and I’d also question whether region collecting should be on by default. In any case methodologically we just need to focus here on finding a way back to the rock-solid reliable performance we’ve had for the last 15 years.

One relevant factor is that the application turns on Batch mode.

@vzarytovskii @KevinRansom You might want to look at turning on ServerGC (or undoing the update to .NET 7 preview 7 back to preview 2) so that we are able to work in this repo

we should switch to old GC (via the runtimeconfig, if possible).

@mangod9 said this isn’t possible via runtimeconfig in preview7.

Turning server mode on should be possible

• For the SDK compiler in the existing SDKs, an environment variable export DOTNET_gcServer=1 set in the build should do the trick
• For the Bootstrap compiler, on Windows it runs using .NET Framework - on Mac/Linux we should generate a runtimeconfig
• For the output compiler to be inserted into future SDKs we should use a runtime config. There’s an existing runtimeconfig in the SDK, I’m not sure where/how that gets created or how to adjust it. THis is what’s currently produced in main:

C:\Windows\System32>more \GitHub\dsyme\fsharp\artifacts\bin\fsc\Debug\net6.0\fsc.runtimeconfig.json
{
  "runtimeOptions": {
    "tfm": "net6.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "6.0.0"
    },
    "rollForwardOnNoCandidateFx": 2
  }
}

[dsyme]

This has been fixed by .NET team