(original) (raw)

Thanks Thomas!

I did not understand cause of failure in CondyInterfaceWithOverpassMethods.java.
Can you share Mach5 report?

I want to know I can push this change now.


Yasumasa

2018-03-13 17:34 GMT+09:00 Thomas Stüfe <thomas.stuefe@gmail.com>:
\> Hi Yasumasa,
\> looks fine to me too. Thank you for fixing.
\>
\> Like David, not a big fan of the array allocation on the stack, but it will
\> probably be okay. Lets hope noone changes JVM\_MAXPATHLEN.
\>
\> Best Regards, Thomas
\>
\> On Tue, Mar 13, 2018 at 8:38 AM, David Holmes <david.holmes@oracle.com>
\> wrote:
\>>
\>> Looks fine to me. Just need a second review.
\>>
\>> And if you use the new submit-hs repo \[1\] to do pre-push testing you can
\>> push this yourself.
\>>
\>> Thanks,
\>> David
\>>
\>> \[1\]
\>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030656.html
\>>
\>>
\>> On 13/03/2018 12:25 AM, Yasumasa Suenaga wrote:
\>>>
\>>> Hi David,
\>>>
\>>>> I don't think this code has the same concern that the code in jvm\_md.h
\>>>> claims\*\* to have, so a simple use of MAXPATHLEN should be fine on all
\>>>> non-windows platforms.
\>>>
\>>>
\>>> It sounds good to me. I updated webrev:
\>>> http://cr.openjdk.java.net/\~ysuenaga/JDK-8199323/webrev.01/
\>>>
\>>>
\>>>> My only concern with the current change is whether a 4K on stack buffer
\>>>> might cause any issues?
\>>>
\>>>
\>>> In case of HotSpot for x64 Linux, stack size is 1MB. So I think the risk
\>>> of stack overflow is very low.
\>>> In fact, my environment (Fedora 27 x64) works fine with this change.
\>>>
\>>>
\>>> Thanks,
\>>>
\>>> Yasumasa
\>>>
\>>>
\>>> On 2018/03/12 13:13, David Holmes wrote:
\>>>>
\>>>> Hi Yasumasa,
\>>>>
\>>>> On 8/03/2018 11:21 PM, Yasumasa Suenaga wrote:
\>>>>>
\>>>>> Hi all,
\>>>>>
\>>>>> Could you review and sponsor it?
\>>>>>
\>>>>> webrev:
\>>>>> http://cr.openjdk.java.net/\~ysuenaga/JDK-8199323/webrev.00/
\>>>>> JBS:
\>>>>> https://bugs.openjdk.java.net/browse/JDK-8199323
\>>>>> Mach5 test result on submit repo:
\>>>>> mach5-one-ysuenaga-JDK-8199323-20180308-1027-13701
\>>>>>
\>>>>> I encountered DebuggerException when hsdis is located on long path as
\>>>>> below:
\>>>>>
\>>>>> Location of hsdis:
\>>>>>
\>>>>> /home/yasuenag/work/xxxxxx/xxxxxxxxxxxxxx/xxxxxxxxxxxxx/workspace/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6\_8.x86\_64/jre/lib/amd64/hsdis-amd64.so
\>>>>>
\>>>>> Exception:
\>>>>> sun.jvm.hotspot.debugger.DebuggerException:
\>>>>> /home/yasuenag/work/xxxxxx/xxxxxxxxxxxxxx/xxxxxxxxxxxxx/workspace/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6\_8.x86\_64/j:
\>>>>> cannot open shared object file: No such file or directory
\>>>>>
\>>>>> In Java\_sun\_jvm\_hotspot\_asm\_Disassembler\_load\_1library(), buffer which
\>>>>> uses for library path is defined as below:
\>>>>>
\>>>>> \`\`\`
\>>>>> char buffer\[128\];
\>>>>> \`\`\`
\>>>>>
\>>>>> I copied JVM\_MAXPATHLEN related code to sadis.c from
\>>>>> os/posix/include/jvm\_md.h and os/windows/include/jvm\_md.h .
\>>>>
\>>>>
\>>>> I don't think this code has the same concern that the code in jvm\_md.h
\>>>> claims\*\* to have, so a simple use of MAXPATHLEN should be fine on all
\>>>> non-windows platforms.
\>>>>
\>>>> \*\* The posix jvm\_md.h code is historical and I don't think we have to be
\>>>> concerned either about a 4095 definition of MAXPATHLEN or that the VM and
\>>>> libraries may have been compiled on different Linux versions!
\>>>>
\>>>> My only concern with the current change is whether a 4K on stack buffer
\>>>> might cause any issues?
\>>>>
\>>>> Thanks,
\>>>> David
\>>>> -----
\>>>>
\>>>>>
\>>>>> I added noreg-hard label on this ticket because this issue is available
\>>>>> when disassembling on coredump.
\>>>>>
\>>>>>
\>>>>> Thanks,
\>>>>>
\>>>>> Yasumasa
\>
\>