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