while testing some pstack changes, i noticed that pstack doesn't print
java frames for 32-bit JVMs running on 64-bit kernels on x86 systems.
this occurs because pstack can't find a jvm debugging library
(libjvm_db.so) to load.

the problem only happens for 32-bit JVMs on 64-bit kernels, because
this is the only scenario where pstack has to find libjvm_db.so.
normally, if the pstack execution model matches the JVM execution
model, then pstack can find this library in the same directory as
the mail jvm library.  but if the pstack execution model doesn't
match that of the jvm, then we run into this problem.  pstack is
executed by isaexec, so the pstack execution model always matches
that of the kernel.  so on a 64-bit kernel, with a 32-bit jvm, pstack
has to guess where to find the 64-bit version of the jvm debugging
library.  to do this it appends "/64" to the path.  this is a standard
convention for how 64-bit version of libraries are delivered in solaris.

this works just fine for sparc systems.  here are some libjvm_db.so
paths from a sparc system:
	/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm_db.so
	/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/64/libjvm_db.so
	/usr/jdk/instances/jdk1.6.0/jre/lib/sparcv9/server/libjvm_db.so

unfortunatly, this doesn't work for x86 systems.  here are some libjvm_db.so
paths from an x86 system:
	/usr/jdk/instances/jdk1.6.0/jre/lib/i386/server/libjvm_db.so
	/usr/jdk/instances/jdk1.6.0/jre/lib/amd64/server/libjvm_db.so

the problem here is that the 32-bit version of the jvm isn't providing
a 64-bit libjvm_db.so library.  the amd64 version of the library can't
be used on 32-bit processes because it can't deal with those types
of processes.