Skip to content

Conversation

@adamsitnik
Copy link
Member

@adamsitnik adamsitnik commented Jun 16, 2020

A workaround for BDN bug caused by netcoreapp5.0->net5.0 moniker rebranding

The proper fix is available at: dotnet/BenchmarkDotNet#1479 but before we ship new BDN version to NuGet.org (most probably a matter of months) you can use this workaround.

@JamesNK

Fixes #22915

@Pilchie Pilchie added the area-perf Performance infrastructure issues label Jun 16, 2020
@JamesNK
Copy link
Member

JamesNK commented Jun 17, 2020

Confirmed that this works. Temporary work around can be removed when updating to new BDN.

@JamesNK JamesNK merged commit 580a6cc into dotnet:master Jun 17, 2020
@adamsitnik adamsitnik deleted the bdnNet50Workaround branch June 17, 2020 07:55
(
// not using "net5.0", a workaround for https://github.com/dotnet/BenchmarkDotNet/pull/1479
targetFrameworkMoniker: "netcoreapp5.0",
runtimeFrameworkVersion: default,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JamesNK @adamsitnik When I was running benchmarks on net5.0, I got a MethodAccessException when trying to reference Encoding.Latin1:

OverheadJitting  1: 512 op, 386800.00 ns, 755.4688 ns/op

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.MethodAccessException: Attempt by method 'Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark+<>c.<Setup>b__7_0(System.String)' to access method 'System.Text.Encoding.get_Latin1()' failed.
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.<>c.<Setup>b__7_0(String _) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 39
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.HttpUtilities.GetRequestHeaderString(ReadOnlySpan`1 span, String name, Func`2 encodingSelector) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Infrastructure\HttpUtilities.cs:line 146
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestHeaders.Append(ReadOnlySpan`1 name, ReadOnlySpan`1 value) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpHeaders.Generated.cs:line 6686
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.OnHeader(ReadOnlySpan`1 name, ReadOnlySpan`1 value) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpProtocol.cs:line 522
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.TryTakeSingleHeader(TRequestHandler handler, ReadOnlySpan`1 headerLine) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpParser.cs:line 342
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.ParseHeaders(TRequestHandler handler, SequenceReader`1& reader)
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.ParseData() in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 91
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.LiveAspNet() in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 74
   at BenchmarkDotNet.Autogenerated.Runnable_0.WorkloadActionNoUnroll(Int64 invokeCount) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 838
   at BenchmarkDotNet.Engines.Engine.RunIteration(IterationData data)
   at BenchmarkDotNet.Engines.EngineFactory.Jit(Engine engine, Int32 jitIndex, Int32 invokeCount, Int32 unrollFactor)
   at BenchmarkDotNet.Engines.EngineFactory.CreateReadyToRun(EngineParameters engineParameters)
   at BenchmarkDotNet.Autogenerated.Runnable_0.Run(IHost host, String benchmarkName) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 164
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at BenchmarkDotNet.Autogenerated.UniqueProgramName.AfterAssemblyLoadingAttached(String[] args) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 47

I knew we had workarounds in place to make "net5.0" work with BenchmarkDotNet, so I found this PR. I figured this kind of MethodAccessException was likely caused by a runtime framework version mismatch, so locally I changed runtimeFrameworkVersion: default, to runtimeFrameworkVersion: "5.0.0-preview.8.20323.9",.

Sure enough, this fixed it, but is there a better way to fix this than manually passing the runtimeFrameworkVersion in here? It wasn't the most obvious thing, and is a bit of a pain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-perf Performance infrastructure issues

Projects

None yet

4 participants