Thanks David! I've run test on submit-hs repo, but I received 1 failure:
mach5-one-ysuenaga-JDK-8199323-20180313-0429-14193 java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java windows-x64 Error: failed to clean up files after test I guess the failure does not relate to this change. After getting second reviewer, I re-run the test before pushing. Yasumasa 2018-03-13 16:38 GMT+09:00 David Holmes <david.hol...@oracle.com>: > 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
