Question on location of hsdis library for JDK7

Tue Jul 5 22:13:42 PDT 2011

>
> It's documented correctly there or at least the intended operation is.

Yes, agreed. And...

> Anyway, I'm not against updating the language.  How about this:

That's what I'm looking for. It could be useful to include the bug ID in the
updated README as well.
Thanks again ^_^

Regards,
Kris Mok

On Wed, Jul 6, 2011 at 12:30 PM, Tom Rodriguez <tom.rodriguez at oracle.com>wrote:

>
> On Jul 5, 2011, at 4:03 PM, Krystal Mok wrote:
>
> > Cool, thank you very much for pinpointing the problem and fixing it so
> quickly :-)
> > Would it be better to document the exact search path in hsdis's README
> file?
>
> It's documented correctly there or at least the intended operation is.  I
> guess we could note that libhsdis is checked first and that JDK7 behaves
> strangely because of the bug.  But if you're reading it then you likely
> don't have the buggy version.  Anyway, I'm not against updating the
> language.  How about this:
>
> diff -r 2c359f27615c src/share/tools/hsdis/README
> --- a/src/share/tools/hsdis/README
> +++ b/src/share/tools/hsdis/README
> @@ -75,8 +75,16 @@
>  * Installing
>
>  Products are named like build/$OS-$LIBARCH/hsdis-$LIBARCH.so.  You can
> -install them on your LD_LIBRARY_PATH, or inside of your JRE next to
> -$LIBARCH/libjvm.so.
> +install them on your LD_LIBRARY_PATH, or inside of your JRE/JDK.  The
> +search path in the JVM is:
> +
> +1. <home>/jre/lib/<arch>/<vm>/libhsdis-<arch>.so
> +2. <home>/jre/lib/<arch>/<vm>/hsdis-<arch>.so
> +3. <home>/jre/lib/<arch>/hsdis-<arch>.so
> +4. hsdis-<arch>.so  (using LD_LIBRARY_PATH)
> +
> +Note that there's a bug in hotspot versions prior to hs22 that causes
> +steps 2 and 3 to fail when used with JDK7.
>
>  Now test:
>
> tom
>
> >
> > Regards,
> > Kris Mok
> >
> > On 2011-7-6, at 3:02, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> >
> >> This looks like a bug in disassembler.cpp that was masked by how
> LD_LIBRARY_PATH was setup by older JDKs.  The 1.6 launcher always setup the
> LD_LIBRARY_PATH to point into jre/lib/<arch> and jre/lib/<arch>/<vm> but the
> 1.7 one doesn't.  It relies on $ORIGIN and some extra smarts to avoid having
> to re-exec to setup LD_LIBRARY_PATH.  This is 6367077.
> >>
> >> The bug is that when hotspot looks for hsdis next to libjvm.so it's not
> stripping the lib path of the path so it tries to open libhsdis-i386.so.
> >>
> >> /7:     open("/net/
> jre.us.oracle.com/p/v33/jdk/6_14/fcs/b08/binaries/solaris-amd64/fastdebug/jre/lib/i386/client/libhsdis-i386.so",
> O_RDONLY|O_NONBLOCK) Err#2 ENOENT
> >>
> >> It then falls back to an LD_LIBRARY_PATH lookup on hsdis-i386.so which
> in 1.6 will find it next to libjvm.so or even in jre/lib/<arch> but which
> will fail in 1.7.  I filed 7062856 for this.
> >>
> >> For now, you can rename your library to libhdis-<arch>.so.
> >>
> >> tom
> >>
> >> On Jul 2, 2011, at 5:14 AM, Krystal Mok wrote:
> >>
> >>> Hi all,
> >>>
> >>> I used to build the hsdis library and put it along side
> $LIBARCH/libjvm.so and it worked fine.
> >>>
> >>> But when I was trying it out today with JDK7 build 147 x64 on Ubuntu,
> putting hsdis-amd64.so along side libjvm.so didn't work.
> >>> The log says:
> >>> Could not load hsdis-amd64.so; library not loadable; PrintAssembly is
> disabled
> >>>
> >>> Instead, setting LD_LIBRARY_PATH to the where hsdis-amd64.so is in did
> work like before. e.g.
> >>> $ export
> LD_LIBRARY_PATH=.:/home/sajia/jdk/7b147_x64_debug/fastdebug/jre/lib/amd64/server
> >>>
> >>> I'm not sure from which version it started to behave like this, or
> which platforms are affected.
> >>>
> >>> On the same machine, JDK6u25 can load the same hsdis-amd64.so from
> along side libjvm.so without problem.
> >>> Then I copied libjvm.so from JDK7b147 to my JDK6u25 installation and
> tried again:
> >>>
> >>> $ echo $LD_LIBRARY_PATH
> >>>
> >>> $ java -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly | head
> -n5
> >>> Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled;
> turning on DebugNonSafepoints to gain additional output
> >>> VM option '+UnlockDiagnosticVMOptions'
> >>> VM option '+PrintAssembly'
> >>> Loaded disassembler from hsdis-amd64.so
> >>> Decoding compiled method 0x00002aaaab118910:
> >>> $ java -version
> >>> java version "1.6.0_25"
> >>> Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
> >>> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17-fastdebug, mixed
> mode)
> >>>
> >>> And it worked. And then doing the reverse, copied the libjvm.so to
> JDK7b147's installation:
> >>>
> >>> $ export JAVA_HOME=~/jdk/7b147_x64_debug/fastdebug
> >>> $ export PATH=$JAVA_HOME/bin:$PATH
> >>> $ echo $LD_LIBRARY_PATH
> >>>
> >>> $ java -version
> >>> java version "1.7.0-fastdebug"
> >>> Java(TM) SE Runtime Environment (build 1.7.0-fastdebug-b147)
> >>> Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)
> >>> $ ls $JAVA_HOME/jre/lib/amd64/server/
> >>> hsdis-amd64.so  libjsig.so  libjvm.so  libjvm.so.orig  Xusage.txt
> >>> $ java -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly | head
> -n5
> >>> Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled;
> turning on DebugNonSafepoints to gain additional output
> >>> Could not load hsdis-amd64.so; library not loadable; PrintAssembly is
> disabled
> >>>
> >>> From that I'd guess it's a JDK7-only behavior; doesn't seem to be a
> HotSpot VM problem.
> >>> Does anybody have a clue on this?
> >>>
> >>> Regards,
> >>> Kris Mok
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110706/960db6a2/attachment-0001.html 