P4
A DESCRIPTION OF THE PROBLEM :
On Windows, dbghelp.dll is used in Hotspot to load symbol information that seems to be primarily used to enrich the output of VM logs (especially crash logs). Unfortunately, this library requires cautious synchronization to be used correctly because its functions should only be called from a single thread at a given time. Hotspot takes care of this by guarding the unsafe calls using critical sections.
However, this means that applications on the JVM can't safely use the library. Instead, users currently have to rely on unstable, undocumented behavior that may break at any time, or "outsource" any call into an external process which adds a significant amount of overhead.
To overcome this issue, I would love to see an explicit opt-in VM option to turn off dbghelp-based symbol parsing. Effectively, this would be a niche option that would allow JVM applications to use the library safely by giving up on some log output that is not relevant anyway to the majority of developers.
On Windows, dbghelp.dll is used in Hotspot to load symbol information that seems to be primarily used to enrich the output of VM logs (especially crash logs). Unfortunately, this library requires cautious synchronization to be used correctly because its functions should only be called from a single thread at a given time. Hotspot takes care of this by guarding the unsafe calls using critical sections.
However, this means that applications on the JVM can't safely use the library. Instead, users currently have to rely on unstable, undocumented behavior that may break at any time, or "outsource" any call into an external process which adds a significant amount of overhead.
To overcome this issue, I would love to see an explicit opt-in VM option to turn off dbghelp-based symbol parsing. Effectively, this would be a niche option that would allow JVM applications to use the library safely by giving up on some log output that is not relevant anyway to the majority of developers.