Collected delegate diagnostic by kbaladurin · Pull Request #15809 · dotnet/coreclr

kbaladurin · 2018-01-10T16:26:32Z

Improve collected delegate calls diagnostic (https://github.com/dotnet/coreclr/issues/15465):

Improve UMEntryThunkCode::Poison to produce diagnostic message
Store freed thunks into FIFO free list, in this case it takes longer before the thunks get reused

Example:

$ ./corerun delegategc.dll
Press ESC to stop
register_callback:0x7f293afa316c ----
force GC!!!
upcall ----
FailFast: A callback was made on a garbage collected delegate of type 'delegategc!DelegateGC.Program+Callback::Invoke'.

   at DelegateGC.Program.upcall()
   at DelegateGC.Program.upcall()
   at DelegateGC.Program.MyView_KeyEvent(System.ConsoleKeyInfo)
   at DelegateGC.Program.Main(System.String[])
Aborted (core dumped)

kbaladurin · 2018-01-10T16:30:36Z

@jkotas PTAL

jkotas · 2018-01-10T21:29:15Z

+    m_movR10[1]  = 0xBF;
+#endif
+
+    FlushInstructionCache(GetCurrentProcess(), &m_movR10[0], &m_jmpRAX[3]-&m_movR10[0]);


Could you please use ClrFlushInstructionCache? It is no-op on Intel platforms that guarantee code cache coherency.

Yes, thank you for suggestion. Should we use ClrFlushInstructionCache instead of direct calls of the FlushInstructionCache in other places (for example in UMEntryThunkCode::Encode in arm/stubs.cpp, arm64/stubs.cpp, i386/cgenx86.cpp)?

I think so.

jkotas · 2018-01-10T21:34:41Z

+        MODE_COOPERATIVE;
+        PRECONDITION(CheckPointer(pEntryThunk));
+    }
+    CONTRACTL_END;


I would be useful to add a comment here that this diagnostic is best effort, it won't report the problem in 100% of cases, and it may sometime crash while trying to report the problem.

jkotas · 2018-01-10T22:19:49Z

-            *ppHead = pNewBlock;

-            MergeBlock(pNewBlock, pHeap);
+            if (pHeap->IsFIFO())


I am wondering how this would can interact with other places that use the executable heap, and whether we can make this generally more reliable.

Would it be better to move the FIFO into one level up to where UMEntryThunks are allocate? I am thinking about something like:

UMEntryThunk::CreateUMEntryThunk { if (number of cached thunks < 100) Allocate a new thunk using GetGlobalLoaderAllocator()->GetExecutableHeap() else Use thunk from the LIFO cache } UMEntryThunk::Terminate { Add a thunk to LIFO cache }

jkotas · 2018-01-10T22:21:12Z

It looks good to me overall, modulo comments. Thank you for implementing it!

kbaladurin · 2018-01-11T12:59:48Z

Thank you for review! I've updated PR.

kbaladurin · 2018-01-11T13:00:23Z

cc @Dmitri-Botcharnikov

kbaladurin · 2018-01-11T14:22:21Z

@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test

jkotas · 2018-01-11T14:49:15Z

+
+    if (p == NULL)
+    {
+        // On the phone, use loader heap to save memory commit of regular executable heap


Nit: Delete this comment. It is not relevant anymore.

jkotas · 2018-01-11T15:38:39Z

+            ++m_count;
+        }
+
+        m_list.InsertTail(new SListElem<UMEntryThunk*>(pThunk));


Allocating here is problematic. This method needs to have:

CONTRACTL { NOTHROW; } CONTRACTL_END;

contract because of UMEntryThunk::FreeUMEntryThunk that calls it is nothrow.

We should just use the UMEntryThunks memory itself to maintain the list.

It may be better to not use SList for this, and just implement a custom linked list just for the UMEntryThunk here.

jkotas · 2018-01-11T15:39:31Z

+
+            if (pElem != NULL)
+            {
+                UMEntryThunkFreeList::FreeThunk(pElem->GetValue());


We can put the thunk to the list all the time. No need to ever return it back to the LoaderHeap.

If you do this, we can also delete LHF_ZEROINIT flag on the LoaderHeap added by previous iteration of this change.

Why we don't need to return allocated chunks to the LoaderHeap? I think they can be reused since GlobalLoaderAllocator's executable heap is also used in other places.
Thank you!

Outside UMEntryThunks, the executable heap is used in a very few rarely used places. There is a close to zero chance that the returned memory would be reused for anything but UMEntryThunks.

Thank you for explanation, I've removed returning memory to the LoaderHeap in UMEntryThunkFreeList.
Is LHF_ZEROINIT flag not useful? I think it can reduce time of allocation if we don't need initialized memory.

LoaderHeap allocates memory directly from the OS using mmap. This memory is zero initialized, so the zero initialization is free for the normal loader heap use.

!LHF_ZEROINIT can only save something for cases where the memory is returned back to LoaderHeap. This was only done by UMEntryThunks on mainline paths. After this change, it will pretty much never happen. The memory is generally returned to LoaderHeap on exceptional paths only, like a complex operations like type loading fails in the middle and we need to backout the memory allocated so far - so that we do not have a memory leak if this operation is repeated again and again. We do not optimize performance on exceptional paths. We prefer simplicity for exceptional paths.

Thank you! I've removed this option.

jkotas · 2018-01-11T15:44:42Z

@@ -33,6 +33,90 @@ struct UM2MThunk_Args
    int argLen;
 };


You can the MDA_SUPPORTED code in dllimportcallback.* because of it is superceeded by this change.

We can delete MDA_SUPPORTED code in dllimportcallback, yes?

Yes, it is what I meant.

jkotas · 2018-01-11T15:51:21Z

+
+    ~UMEntryThunkFreeList()
+    {
+        SListElem<UMEntryThunk*> *pElem = m_list.GetHead();


This destructor won't be necessary once we stop allocating our own heap. (You do not need to worry about freeing memory allocated on LoaderHeap.)

kbaladurin · 2018-01-12T15:14:31Z

cc @parjong

jkotas · 2018-01-12T15:28:17Z

+
+#define DEFAULT_THUNK_FREE_LIST_THRESHOLD 64
+
+static UMEntryThunkFreeList s_thunkFreeList(DEFAULT_THUNK_FREE_LIST_THRESHOLD);


This contains Crst. Crsts in static variables has to be CrstStatic to avoid issues like: https://github.com/dotnet/coreclr/issues/13779#issuecomment-328007409

jkotas · 2018-01-12T15:29:10Z

+    union
+    {
+        // Pointer to the shared structure containing everything else
+        PTR_UMThunkMarshInfo    m_pUMThunkMarshInfo;


👍

Thanks for making it explicit where the link lives.

jkotas · 2018-01-12T15:34:28Z

    m_jmp        = X86_INSTR_JMP_REL32;
    m_execstub   = (BYTE*) ((pTargetCode) - (4+((BYTE*)&m_execstub)));

-    FlushInstructionCache(GetCurrentProcess(),GetEntryPoint(),sizeof(UMEntryThunkCode));


Could you please keep the full FlushInstructionCache in Encode (on x86 and x64 at least)?

We used to have issues with Time Travel Debugging that required explicit FlushInstructionCache to fix/workaround. I am not sure whether these issues still exist.

Using ClrFlushInstructionCache in Poison should be fine.

jkotas · 2018-01-12T15:45:51Z

 End

+Crst UMEntryThunkFreeList
+    AcquiredBefore LoaderHeap


Ordering this with LoaderHeap should not be needed - you are not calling into LoaderHeap when the lock is taken.

Since your lock is a pretty simple leaf lock, you can just use CrstLeafLock for it and not add to this file at all.

Thank you for suggestion!

Improve UMEntryThunkCode::Poison to produce diagnostic message when collected delegate was called.

Use free list to delay reusing deleted thunks. It improves collected delegate calls diagnostic.

This option was used for UMEntryThunkCode::Poison. Now we use own free list to store freed thunks and don't return allocated memory to the LoaderHeap. So reused thunks are always uninitialized.

jkotas

Thank you!

jkotas reviewed Jan 10, 2018

View reviewed changes

kbaladurin force-pushed the collected-delegate-diagnostic branch 2 times, most recently from e025ec5 to c6e61e3 Compare January 11, 2018 12:45

jkotas reviewed Jan 11, 2018

View reviewed changes

kbaladurin force-pushed the collected-delegate-diagnostic branch from c6e61e3 to 44eb523 Compare January 11, 2018 14:54

jkotas reviewed Jan 11, 2018

View reviewed changes

kbaladurin force-pushed the collected-delegate-diagnostic branch from 44eb523 to 757f7a8 Compare January 12, 2018 09:11

jkotas reviewed Jan 12, 2018

View reviewed changes

Improve UMEntryThunkCode::Poison method.

11d0b49

Improve UMEntryThunkCode::Poison to produce diagnostic message when collected delegate was called.

kbaladurin force-pushed the collected-delegate-diagnostic branch from 757f7a8 to 8238c90 Compare January 12, 2018 16:37

Konstantin Baladurin added 3 commits January 12, 2018 19:38

UMEntryThunk: store freed thunks into FIFO free list

c222495

Use free list to delay reusing deleted thunks. It improves collected delegate calls diagnostic.

dllimportcallback: remove code for CallbackOnCollectedDelegate MDA

1d9b937

LoaderHeap: remove LHF_ZEROINIT option.

564db77

This option was used for UMEntryThunkCode::Poison. Now we use own free list to store freed thunks and don't return allocated memory to the LoaderHeap. So reused thunks are always uninitialized.

kbaladurin force-pushed the collected-delegate-diagnostic branch from 8238c90 to 564db77 Compare January 12, 2018 16:39

jkotas approved these changes Jan 12, 2018

View reviewed changes

jkotas merged commit 02f172c into dotnet:master Jan 12, 2018

kbaladurin deleted the collected-delegate-diagnostic branch January 15, 2018 06:38

janvorli mentioned this pull request Sep 27, 2018

Enable delegate marshalling for collectible types #20158

Merged

reflectronic mentioned this pull request Feb 4, 2021

Managed Debugging Assistants dotnet/runtime#47826

Closed


		#define DEFAULT_THUNK_FREE_LIST_THRESHOLD 64

		static UMEntryThunkFreeList s_thunkFreeList(DEFAULT_THUNK_FREE_LIST_THRESHOLD);

Conversation

kbaladurin commented Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kbaladurin commented Jan 10, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas commented Jan 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kbaladurin commented Jan 11, 2018

Uh oh!

kbaladurin commented Jan 11, 2018

Uh oh!

kbaladurin commented Jan 11, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Jan 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Jan 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kbaladurin commented Jan 12, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

kbaladurin commented Jan 10, 2018 •

edited

Loading

jkotas commented Jan 10, 2018 •

edited

Loading

jkotas Jan 11, 2018 •

edited

Loading

jkotas Jan 12, 2018 •

edited

Loading