Start to use C++ 17 STL in superpmi #116422
Conversation
github-actions
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
community-contribution
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| std::filesystem::path g_realJitPath{""}; // Destructable objects will be cleaned up and won't leak | ||
| std::filesystem::path g_logPath{""}; | ||
| std::filesystem::path g_HomeDirectory{""}; | ||
| std::filesystem::path g_DefaultRealJitPath{""}; | ||
|
|
||
| void SetDefaultPaths() | ||
| std::unique_ptr<MethodCallSummarizer> g_globalContext = nullptr; |
There was a problem hiding this comment.
According to https://learn.microsoft.com/windows/win32/dlls/dllmain and other documentations I can find, constructors/destructors for global objects with be respected by dll/so unloading. I haven't test it though.
There was a problem hiding this comment.
Global destructors are a bug farm. The problem is that they run while the other threads are stopped at random spot (on Windows) and while other threads are running (on non-Windows). Every time we happen to introduce one by mistake, we end up deleting it later to fix intermittent hangs and crashes.
There was a problem hiding this comment.
How does it compare to DllMain (DETACH)? The counter shim writes statistics on unload, which is simulated by PAL. Is there better approach?
There was a problem hiding this comment.
DllMain (DETACH)
It has the same problems
There was a problem hiding this comment.
Does is mean that things won't be worse if we replace existing DllMain with global objects? Currently the DllMain of JIT is doing shutdown.
There was a problem hiding this comment.
Currently the DllMain of JIT is doing shutdown.
If I am reading the code correctly, DllMain of JIT is only called on Windows. It is never called on non-Windows.
Does is mean that things won't be worse if we replace existing DllMain with global objects?
I would expect it to be fine for superpmi. I am not sure about regular JIT.
There was a problem hiding this comment.
If I am reading the code correctly, DllMain of JIT is only called on Windows. It is never called on non-Windows.
JIT is loaded by CLRLoadLibrary in LoadAndInitializeJIT, which is implemented in PAL with LoadLibraryExW and does DllMain simulation. It's never unloaded though, but if it is, the DllMain will also be called by PAL.
|
It seems that our linux glibc x64/x86/arm64 build environment aren't ready for C++ 17 STL. Is it because we are targeting the runtime version of lowest supported OS? |
|
We use Ubuntu |
|
Is it OK to use some polyfill for superPMI only? We don't need strict compatibility or reliability here. If this is too flaky, I can remove C++ 17 usage and convert to C++ 11 STL instad. |
What would you have to give up on by converting to C++ 11? |
Everything in |
As discussed in #112419, there should not be blocker for adopting C++ 17 in development environment. SuperPMI is I/O intensive and can be simplified significantly with std::filesystem.
The end goal is to eliminate PAL simulation of Windows I/O functions. This PR acts as a first step to adopt STL in the dll shim entries.