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.stu...@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.hol...@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 > >
