Diagnostics: gcroot algorithm is inefficient

[sdmaclea]

I am able to dump all the string objects in the heap within a matter of seconds.

For a smaller heap of 30MB finding the gcroot of a single object took >7 minutes.

Investigate the possibility of a better algorithm.

[mikem8361]

Could you add the coredump that take 7 minutes?

[sdmaclea]

I put it the core file on \\scratch2\scratch\stmaclea\core_20191121_152854

[tomasdeml]

Any progress on this? The slowness of the gcroot command hampers investigation of our production issues (the dump is ~ 4 GB). The command does not complete at all (after a few hours I gave up) 😢.

[sdmaclea]

I am going to take a look at this.

[mikem8361]

Thanks!!!

[sdmaclea]

I built dotnet-dump from source and timed it. Strangely the it is >100x faster than the latest dotnet-dump release.

I thought maybe the difference was in master vs. release/stable, but the release/stable results are similar. I also tried debug vs release. Both of these are about > 100x faster than dotnet-dump official release.

Copying the locally built libsos.so over the official tool fixes the issue.

Seems like official build of dotnet-dump isn't using the libsos.so from source. I don't see the issue with sos.packaging.props...

@mikem8361 @hoyosjs

Not sure what else I can do here....

[mikem8361]

Maybe somehow (I don’t see in the logs) our official builds are publishing debug libsos.so bits? May it is something weird with building the official SOS under CentOS 7 docker image mcr.microsoft.com/dotnet-buildtools/prereqs:centos-7-3e800f1-20190501005343?

Did you try the bits from this official release/stable build under the “CentOS_7_x64_Release” tab? Or the package under packages->Release->Shipping->dotnet-dump.3.1.135903.nupkg? That is where I got the packages to pushed to nuget.org recently.

Thanks for looking into this.