-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Search native code in all R2R ni.dll in version bubble #57277
Conversation
c2d2f5d
to
91e753a
Compare
da2f1cd
to
8dc0aa9
Compare
@jkotas had you time to check PR? |
src/coreclr/vm/codeman.h
Outdated
@@ -1264,6 +1290,14 @@ class ExecutionManager | |||
SIZE_T Size, | |||
Module * pModule); | |||
|
|||
static int FindRangeSectionHandleHelper(TADDR addr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs comment on what this returns. It does not return a simple index...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, can it be in the private
section (before public:
)?
enum | ||
{ | ||
RangeSectionHandleArrayInitialSize = 100, | ||
RangeSectionHandleArrayExpansionFactor = 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In debug/checked builds, we should make the initial size small and make the array grow on element at a time to ensure that the array resize algorithm and the potential race conditions are exercised.
src/coreclr/vm/codeman.h
Outdated
TADDR LowAddress; | ||
TADDR HighAddress; | ||
#ifndef DACCESS_COMPILE | ||
Volatile<RangeSection *> pRS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this need to be volatile?
src/coreclr/vm/codeman.h
Outdated
struct RangeSectionHandle | ||
{ | ||
TADDR LowAddress; | ||
TADDR HighAddress; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think that this needs to store HighAddress. It can just store the LowAddress and the method that is binary searching inside the array can just return the candidate RS index. We can then validate that the candidate RS index actually fits by comparing the address with RangeSection::HighAddress.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side-effect of this change is going to be that the size of this struct will be power of two that will make the binary search faster.
FrameWithCookie<ExternalMethodFrame> frame(pTransitionBlock); | ||
ExternalMethodFrame * pEMFrame = &frame; | ||
pModule = ExecutionManager::FindReadyToRunModule((TADDR)(((BYTE*)pEMFrame->GetReturnAddress())-1)); | ||
|
||
BEGIN_PRESERVE_LAST_ERROR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BEGIN_PRESERVE_LAST_ERROR
should be before the newly added code.
src/coreclr/vm/prestub.cpp
Outdated
@@ -1853,6 +1860,11 @@ extern "C" PCODE STDCALL PreStubWorker(TransitionBlock* pTransitionBlock, Method | |||
{ | |||
PCODE pbRetVal = NULL; | |||
|
|||
Module* pModule = NULL; | |||
FrameWithCookie<ExternalMethodFrame> frame(pTransitionBlock); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not look right to create a dummy ExternalMethodFrame
just to get the return address.
The fixups from R2R modules should come via ExternalMethodFixupWorker
. Can we just use the module that is computed there?
BTW: I do like this change - it should be general performance improvement for any scenario with large number of modules. |
3d7cad1
to
fe70768
Compare
and make it private
Binary search algorighm in FindRangeSectionHandleHelper changes accordingly.
fe70768
to
b3cebf2
Compare
0a80132
to
0d663c4
Compare
0d663c4
to
84187af
Compare
pLast = pCurr; | ||
pCurr = pCurr->pnext; | ||
} | ||
ReaderLockHolder rlh(HostCallPreference::NoHostCalls); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is important for this path to be lock-free. Adding a lock here is very likely to regress GC stackwalking performance on machines with a lot of cores.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is so important, we will investigate another way to isolate readers from writers. We think we could find one with two interchanging arrays.
src/coreclr/vm/codeman.cpp
Outdated
pCurr = pCurr->pnext; | ||
} | ||
ReaderLockHolder rlh(HostCallPreference::NoHostCalls); | ||
while (!rlh.Acquired()); // rlh con did not yield and we have HOST_NOCALLS limitation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what this is trying to achieve, but it does not look right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are obliged to ask if the lock has been aquired after NoHostCalls
constructor of ReaderLockHolder
. NoHostCalls
is necessary because of contract requirement from very above on call stack. We have encountered contract violation if we use default constructor (and the source of violation is not GetRangeSection, it is much higher).
6df483d
to
80f8f73
Compare
hi @y-yamshchikov, assume you are still working on this PR feedback? |
hi @y-yamshchikov, checking if this PR still needs to be kept open since it hasnt been updated in a couple of months. Thx |
Dear @mangod9, we are working on new approach granting lockfree reading of RangeSections and still benefiting from binary search capabilities of sorted array, fighting all the contradictions dictating by the multiprocessor environment. We end up with new version of synchronization mechanics and for now working on comprehensive testing environment which grants extensive coverage of all possible synchronization issues. To be presented soon, both the code and the testing model. |
thanks for the update, should we close this PR for now and open a new one once ready? Thx! |
There is lot of useful feedback conversation still not outdated, I think the change is made in a successive way to prolong current PR. |
I would suggest we close the PR and reopen when more changes are added. This helps to keep the "Open PRs" list manageable. |
Closing for now so it doesnt get flagged in stale PRs. Please reopen when ready to merge again. Thx. |
This PR fixes part of #44948 and fixes #46160.
This code simply traverses through assemblies in the application
domain. For each assembly (module) it realizes is it Ready To Run and is
it in the same bubble with (does it deliberately bubbling the) module
from which generic function originates. If so, it makes request for code
is Ready To Run and hopes there is some in the module. If the request
succeeds it proceeds with found pointer to the bare native code.
Now such methods use their Ready To Run code.
We have got significant performance gain on startup: 7% average on our representative set on Tizen.
This PR worked out notices in PR below:
#47269
about linear search through the set of RangeSections. In this new PR we propose storing of RangeSections in sorted array (with number of optimizations inspired by prior linked list based solution).
We have extensively tested this PR on armel/Tizen platform so in this case we are confident in reliability and profitability of the solution.
Dear colleagues @jkotas @alpencolt @gbalykov @t-mustafin, please take a look.