Slimmer QueueUserWorkItemCallback #3157

benaadams · 2016-02-12T09:41:18Z

As per https://github.com/dotnet/coreclr/issues/3147#issuecomment-183158977

No stored ExecutionContext when context is default

/cc @stephentoub something like this?

stephentoub · 2016-02-12T12:10:45Z

src/mscorlib/src/System/Threading/ExecutionContext.cs

@@ -53,7 +53,7 @@ internal void Undo()

    public sealed class ExecutionContext : IDisposable
    {
-        private static readonly ExecutionContext Default = new ExecutionContext();
+        internal static readonly ExecutionContext Default = new ExecutionContext();


This can stay private and you can instead use IsDefaultFTContext
Edit: Nevermind, it would need to be internal to be used explicitly as an arg to ExecutionContext.Run.

stephentoub · 2016-02-12T12:22:51Z

cc: @ericeil

stephentoub · 2016-02-12T12:23:51Z

src/mscorlib/src/System/Threading/ThreadPool.cs

-                    QueueUserWorkItemCallback tpcallBack = new QueueUserWorkItemCallback(callBack, state, compressStack, ref stackMark);
+                    ExecutionContext context = compressStack && !ExecutionContext.IsFlowSuppressed() ?
+                                                ExecutionContext.Capture(ref stackMark, ExecutionContext.CaptureOptions.IgnoreSyncCtx | ExecutionContext.CaptureOptions.OptimizeDefaultCase) :
+                                                ExecutionContext.Default;


@ericeil should comment on whether for this version of the code base it needs to be this complicated, or whether for CoreCLR it could be simplified, since we know that many of these things are nops.

ericeil · 2016-02-12T18:28:11Z

src/mscorlib/src/System/Threading/ThreadPool.cs

@@ -1168,11 +1168,7 @@ internal interface IThreadPoolWorkItem

    internal sealed class QueueUserWorkItemCallback : IThreadPoolWorkItem


Please rename to QueueUserWorkItemCallbackNullContext

ericeil · 2016-02-12T18:36:03Z

A couple of general thoughts on this:

The work queues are exposed to debuggers, and I'm not sure how much they depend on the exact details of the workitem types. It's possible that this change will also require work in the debuggers to understand the new types. @noahfalk may know more.
This change substantially increases the number of types that implement IThreadPoolWorkItem. This may impact the performance of the interface dispatch at the callsites for these methods, since they're now more polymorphic (requiring more interface dispatch cache entries). I don't know the current design of interface dispatch on CoreCLR, but there are typically performance "cliffs" as callsites become more and more polymorphic. This may not end up mattering, or be sufficiently offset by the GC perf gains from smaller (on average) work item objects, but it's something to watch out for.

Overall, though, I think this is a great change to try, with potential to help substantially in many scenarios.

ericeil · 2016-02-12T18:36:39Z

cc: @kouvel

noahfalk · 2016-02-12T19:25:57Z

Thanks Eric! At the ICorDebug interfaces our interaction with the threadpool is identifying which threads are in the pool so no worries there. The SOS/DAC interfaces expose data from ThreadpoolMgr native class, but I am guessing this change wouldn't affect it. The relevant source is debug\daccess\request.cpp ClrDataAccess::GetThreadpoolData(struct DacpThreadpoolData *threadpoolData).

Higher up the stack its possible that Visual Studio might introspect on those types, but a cursory source search didn't find anything. I'll send an email to the VS debugger guys and ask them to take a peak.

benaadams · 2016-02-12T22:01:28Z

This change substantially increases the number of types that implement IThreadPoolWorkItem...

Altered to follow @stephentoub's suggestion of having the null context use the same as non default context, and do the null check in execute. So there is just one new type for the default context.

Both null and non-default context now use the original type which is more or less the same other than removing the constructor that does the EC capture.

noahfalk · 2016-02-13T00:59:04Z

Following up, my coworker over in VS debugger wrote me back and said he thinks this is fine from the VS perspective, they don't introspect into these types.

stephentoub · 2016-02-13T16:41:30Z

src/mscorlib/src/System/Threading/ThreadPool.cs

+                // call directly if it is an unsafe call OR EC flow is suppressed
+                WaitCallback cb = callback;
+                callback = null;
+                cb(state);


Why did you swap the polarity of the if/else?

stephentoub · 2016-02-13T16:45:46Z

Thanks, @noahfalk, for following up.

Parallel of dotnet/coreclr#3157

stephentoub · 2016-02-14T16:46:58Z

LGTM (once squashed).

Does this have the expected impact on your benchmark?

benaadams · 2016-02-14T23:49:38Z

Checking now

benaadams · 2016-02-15T00:14:26Z

Its using the right object

Have to redo it as a release build to measure the allocations for same scenario correctly.

benaadams · 2016-02-15T01:03:12Z

Yep, behaves as suggested allocated bytes go from ~41MB to ~33MB

Before

After

ericeil · 2016-02-15T17:30:05Z

Looks great. Thanks!

Slimmer QueueUserWorkItemCallback

Parallel of dotnet/coreclr#3157

sajayantony · 2016-02-20T02:30:07Z

Very cool 👍

sajayantony · 2016-02-20T02:33:44Z

@geoffkizer we should get some updated numbers soon.

dnfclas added the cla-already-signed label Feb 12, 2016

stephentoub reviewed Feb 12, 2016
View reviewed changes

benaadams force-pushed the QueueUserWorkItemCallback branch from 3645744 to afe2dc4 Compare February 12, 2016 14:34

ericeil reviewed Feb 12, 2016
View reviewed changes

benaadams force-pushed the QueueUserWorkItemCallback branch from 16e65e5 to b939185 Compare February 12, 2016 21:57

stephentoub reviewed Feb 13, 2016
View reviewed changes

benaadams added a commit to benaadams/corert that referenced this pull request Feb 14, 2016

Slimmer QueueUserWorkItemCallback

014566e

Parallel of dotnet/coreclr#3157

benaadams mentioned this pull request Feb 14, 2016

Slimmer QueueUserWorkItemCallback dotnet/corert#861

Merged

Slimmer QueueUserWorkItemCallback

9418bc4

benaadams force-pushed the QueueUserWorkItemCallback branch from 672e93a to 9418bc4 Compare February 14, 2016 20:13

ericeil added a commit that referenced this pull request Feb 15, 2016

Merge pull request #3157 from benaadams/QueueUserWorkItemCallback

2ec6a40

Slimmer QueueUserWorkItemCallback

ericeil merged commit 2ec6a40 into dotnet:master Feb 15, 2016

benaadams deleted the QueueUserWorkItemCallback branch February 15, 2016 17:55

benaadams restored the QueueUserWorkItemCallback branch February 15, 2016 17:56

benaadams added a commit to benaadams/corert that referenced this pull request Feb 16, 2016

Slimmer QueueUserWorkItemCallback

cf4ba39

Parallel of dotnet/coreclr#3157

jkotas mentioned this pull request Mar 23, 2016

Performance improvements for Enum.ToString() #3849

Closed

benaadams mentioned this pull request May 23, 2016

Task & Thread Pool scheduled item optimizations #5156

Closed

benaadams deleted the QueueUserWorkItemCallback branch September 8, 2016 07:08

benaadams mentioned this pull request Oct 16, 2016

Make sure IHttpContextAccessor is always registered aspnet/HttpAbstractions#728

Closed

		@@ -1168,11 +1168,7 @@ internal interface IThreadPoolWorkItem

		internal sealed class QueueUserWorkItemCallback : IThreadPoolWorkItem

Slimmer QueueUserWorkItemCallback #3157

Slimmer QueueUserWorkItemCallback #3157

Uh oh!

Conversation

benaadams commented Feb 12, 2016

Uh oh!

stephentoub Feb 12, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Feb 12, 2016

Uh oh!

stephentoub Feb 12, 2016

Choose a reason for hiding this comment

Uh oh!

ericeil Feb 12, 2016

Choose a reason for hiding this comment

Uh oh!

ericeil commented Feb 12, 2016

Uh oh!

ericeil commented Feb 12, 2016

Uh oh!

noahfalk commented Feb 12, 2016

Uh oh!

benaadams commented Feb 12, 2016

Uh oh!

noahfalk commented Feb 13, 2016

Uh oh!

stephentoub Feb 13, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Feb 13, 2016

Uh oh!

stephentoub commented Feb 14, 2016

Uh oh!

benaadams commented Feb 14, 2016

Uh oh!

benaadams commented Feb 15, 2016

Uh oh!

benaadams commented Feb 15, 2016

Uh oh!

ericeil commented Feb 15, 2016

Uh oh!

sajayantony commented Feb 20, 2016

Uh oh!

sajayantony commented Feb 20, 2016

Uh oh!

Uh oh!