Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

profiler changes for tiered compilation #14612

Merged
merged 5 commits into from
Oct 24, 2017
Merged

profiler changes for tiered compilation #14612

merged 5 commits into from
Oct 24, 2017

Conversation

davmason
Copy link
Member

Adds new profiler APIs for tiered compilation support. Also as part of this change I updated ProfToEEInterfaceImpl::GetILToNativeMapping2 to properly respect the requested rejit ID.

@@ -2595,21 +2599,16 @@ HRESULT ProfToEEInterfaceImpl::GetCodeInfo3(FunctionID functionId,
CodeVersionManager* pCodeVersionManager = pMethodDesc->GetCodeVersionManager();
ILCodeVersion ilCodeVersion = pCodeVersionManager->GetILCodeVersion(pMethodDesc, reJitId);

// Now that tiered compilation can create more than one jitted code version for the same rejit id
// we are arbitrarily choosing the first one to return. To return all of them we'd presumably need
// a new profiler API.
Copy link
Member

Choose a reason for hiding this comment

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

This comment is still correct - we are arbitrarily choosing an implementation. The comment could also mention the new APIs you've added rather than refer to hypothetical new APIs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done


pCodeVersionManager->GetILCodeVersion(pMD, reJitId);
}

Copy link
Member

Choose a reason for hiding this comment

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

Lets add another comment to indicate this is an arbitrarily chosen version and profilers are recommended to use GetILToNativeMapping3 to avoid that ambiguity.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, sounds good

@@ -6583,6 +6592,190 @@ HRESULT ProfToEEInterfaceImpl::GetDynamicFunctionInfo(FunctionID functionId,
}

/*
* GetNativeCodeStartAddresses
*
* TODO: Description
Copy link
Member

Choose a reason for hiding this comment

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

TODO : )

Copy link
Member Author

Choose a reason for hiding this comment

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

Whoops! Taken care of now

ULONG32 cCodeStartAddresses,
ULONG32 *pcCodeStartAddresses,
UINT_PTR codeStartAddresses[])
{
Copy link
Member

Choose a reason for hiding this comment

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

Check out GetModuleInfo2 for example of how it deals with the variable size character buffer and the associated size in/out parameters. I know there aren't a ton of total examples in the profiler API and we already aren't strictly consistent which adds to the confusion, but I think GetModuleInfo2's behavior is a reasonable standard to emulate.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, I made it so that pcCodeStartAddresses and codeStartAddresses are optional. If that's not what you meant, let me know.

Copy link
Member

Choose a reason for hiding this comment

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

I was thinking of the different ways you can call GetModuleInfo2 that don't work here yet:

  • You can call with only pcchName/pcCodeStartAddresses non-null and receive the size of the buffer that would be needed (here this only works if the caller also allocated a sufficiently large buffer)
  • You can call with pcchName/pcCodeStartAddresses null if you don't care about the size (looks like you still go to E_INVALIDARG in this case)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, I see what you're saying now. I missed it the first time. I just updated it to be able to call with just with either pcCodeAddresses or codeStartAddresses null now and the other will be filled out appropriately


ILCodeVersion ilCodeVersion = NULL;
{
CodeVersionManager::TableLockHolder lockHolder(pCodeVersionManager);
Copy link
Member

Choose a reason for hiding this comment

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

I'd put the entire enumeration under the lock. Did anything lead you to avoid putting it under the lock (we might want to change whatever that was too)

Copy link
Member Author

Choose a reason for hiding this comment

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

I forgot to add the lock initially, then when I ran the tests only GetILCodeversion had an assert about the lock so I just put the it around that one place.

I have changed it to be around the whole enumeration now though

/*
* GetILToNativeMapping3
*
* TODO: Description
Copy link
Member

Choose a reason for hiding this comment

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

Another todo to do

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@@ -577,6 +577,29 @@ class ProfToEEInterfaceImpl : public ICorProfilerInfo8

// end ICorProfilerInfo8

// beging ICorProfiler9
Copy link
Member

@noahfalk noahfalk Oct 20, 2017

Choose a reason for hiding this comment

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

begin ICorProfilerInfo9

Copy link
Member Author

Choose a reason for hiding this comment

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

thanks, done

ULONG32* pcCodeInfos,
COR_PRF_CODE_INFO codeInfos[]);

// end ICorProfiler9
Copy link
Member

Choose a reason for hiding this comment

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

ICorProfilerInfo9

Copy link
Member Author

Choose a reason for hiding this comment

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

done too

@@ -2595,21 +2599,16 @@ HRESULT ProfToEEInterfaceImpl::GetCodeInfo3(FunctionID functionId,
CodeVersionManager* pCodeVersionManager = pMethodDesc->GetCodeVersionManager();
Copy link
Member

Choose a reason for hiding this comment

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

I notice a pre-existing bug - this code path didn't grab the code version manager lock and it needs to

Copy link
Member

Choose a reason for hiding this comment

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

If you run the tests with a debug build it should give you asserts anywhere you are missing the lock.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks. I haven't run the existing profiler tests yet, but in general I am running with debug coreclr so I should catch these once I do.

pCodeVersionManager->GetILCodeVersion(pMD, reJitId);
}

NativeCodeVersionCollection nativeCodeVersions = ilCodeVersion.GetNativeCodeVersions(pMD);
Copy link
Member

@noahfalk noahfalk Oct 20, 2017

Choose a reason for hiding this comment

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

The whole enumeration should be inside the lock (but you can leave the call to GetILtoNativeMapping3 outside of it)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, done

{
for(ULONG32 i = 0; i < cCodeStartAddresses; ++i)
{
codeStartAddresses[i] = addresses[i];
Copy link
Member

Choose a reason for hiding this comment

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

You've got a buffer overrun here. cCodeAddresses can be larger than trueLen but addresses only has length trueLen.

@noahfalk
Copy link
Member

LGTM, modulo that one remaining buffer overrun

@davmason davmason merged commit 5d66791 into dotnet:master Oct 24, 2017
@davmason davmason deleted the new_apis branch October 24, 2017 03:24
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants