Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files

[Tom Rodriguez]

> OK, I added that.
> 
> I also had to add these
> 
> +		_ZTV20ParallelScavengeHeap;
> +		_ZTV16GenCollectedHeap;
> 
> to the list of exported symbols.  Without this jmap doesn't work.

The SA does use vtables to dynamically identify the type of some objects and these are needed for that. Looking at the way this works on Windows, it has a build script, make/windows/build_vm_def.sh, that exports all vtables globally so that this is guaranteed to work on a product binary without having to explicitly enumerate the needed vtables.  On solaris we never strip libjvm.so so we haven't worried about explicitly exporting everything, though we do explicitly export a few things in make/solaris/makefiles/mapfiles-vers-COMPILER[12] but I believe that is for dtrace.  If you'd like the SA tools to work reliably even when stripped you might need to add something to the build process that adds all of the vtables like windows does.  We don't have a good way to enumerate all the ones that are needed.  I'd really prefer it if we didn't need to rely on the symbol table at all for the vtables.  I think it might be possible to build the vtable lookup logic into vmStructs.cpp but that's a bigger change and I'm not totally sure how it would work.

One thing to keep in mind with your testing is that some of the tools use JVMTI for live processes instead of going through the SA.  For instance, I believe jstack will use JVMTI unless you use the -F option, though the -m option requires using the SA code.

So do you want to pursue making the SA work with a stripped libjvm.so or is requiring debug info to be installed acceptable?  Sorry if I made this more complicated than you wanted.  I think your original change is fine, but if the norm is being stripped then making these tools work in that situation would be good.

tom

> 
>>> Also, are these the only symbols that are ever looked up by this
>>> symtab reader?
> 
>> Those are the only ones needed by the core SA functionality.  The
>> only thing other symbols are used for is the jstack -m mode that
>> dumps mixed Java and native frames ala pstack and adding the
>> external debug info reader to support this seems reasonable.
> 
> OK.  I guess this will work, but on my x86_64 Linux box ptrace_getregs
> is disabled, so jstack -m fails.
> 
> There's a new webrev at 
> http://cr.openjdk.java.net/~aph/100028-jdk6-webrev-2/
> 
> I can confirm that jmap -heap works with and without debuginfo,
> whether or not the libraries are stripped.
> 
> Andrew.