Skip to content

BDN workaround for netcoreapp5.0->net5.0 moniker rebranding #23000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 17, 2020

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