dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.17k stars 4.72k forks source link

Need API/mechanism to determine allocated PGO buffer size #47356

Closed BruceForstall closed 3 years ago

BruceForstall commented 3 years ago

The new PGO schema code in SuperPMI for MethodContext::recGetPgoInstrumentationResults() tries to figure out how big the buffer is that the VM allocated for pInstrumentationData by looking at the largest Offset in the updated Pgo schema and adding 16:

// This isn't strictly accurate, but I think it'll do
size_t bufSize = maxOffset + 16;

This isn’t acceptable because if the allocated buffer is smaller, and the VM allocated memory butts up against an unallocated page, we could read past the page and get an access violation.

We need a precise way to determine the size of the allocated buffer (or the part of any buffer that this API cares about).

Could the API itself simply return the size as an OUT parameter, so we don’t have to think about how to calculate it?

Or should there be a new JIT-EE API to compute this (an API might not be convenient or possible to use for SuperPMI, however).

Note that the same “+ 16” logic exists in MethodContext::repAllocPgoInstrumentationBySchema(), but in that case it doesn’t matter because we’re allocating temporary memory.

AndyAyersMS commented 3 years ago

See #51521 for one take on this.

davidwrighton commented 3 years ago

@BruceForstall is @AndyAyersMS's solution in #51521 good enough? If so, could you close this issue?

BruceForstall commented 3 years ago

I think so.