RFR(XXS) 8198845: Missing resource mark results disassembling generated code failure in hs error report

David Holmes 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 
>>> code.
>>>
>>> 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.

Thanks,
David

> Thanks,
> 
> -Zhengyu
> 
>> David
>>
>>> Test:
>>>
>>>    hotspot_runtime on Linux x64 (fastdebug + release)
>>>
>>> Thanks,
>>>
>>> -Zhengyu


More information about the hotspot-runtime-dev mailing list