RFR(XXS) 8198845: Missing resource mark results disassembling generated code failure in hs error report
david.holmes at oracle.com
Fri Mar 2 01:47:10 UTC 2018
On 2/03/2018 4:40 AM, Zhengyu Gu wrote:
> Hi David,
> On 02/28/2018 05:33 PM, David Holmes wrote:
>> Hi Zhengyu,
>> On 1/03/2018 7:50 AM, Zhengyu Gu wrote:
>>> nmethod uses stringStreams to buffer contents. Missing resource mark
>>> during error reporting, results failures while disassembling nmethod
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198845
>>> Webrev: http://cr.openjdk.java.net/~zgu/8198845/webrev.00/
>> This seems problematic. There's no guarantee you have a valid thread,
>> nor that you can use its resourceArea to allocate even if you do. What
>> is actually trying to do resourceArea allocation?
> This is where Disassembler calls into nmethod for code comments
> (nmethod::print_code_comment_on()), and subsequently call
> nmethod::reloc_string_for() where it uses stringStream to allocation
> memory from resource area for buffering the contents.
> I managed to remove most of resource objects from this code path, until
> hit ScopeDesc (from nmethod::scope_desc_in()) and scope seems to become
> too big to continue.
> Yes, it is problematic. However, it does not seem to can make it worse -
> without resource mark, it certainly fails.
> Any suggestions?
Does it make sense to at least check we have a _thread and skip that
whole path if we don't? That at least addresses one concern.
>>> hotspot_runtime on Linux x64 (fastdebug + release)
More information about the hotspot-runtime-dev