Today the size of identifiers in heap dumps have the same size as the address size of the virtual machine. If we are using compressed oops, we might (very possibly) be able to use 32 bit identifiers even though we have a 64 bit virtual machine.

Two things limits if this is possible:
1) the Symbols must be representable with 32 bit identifiers
2) the JNI handles must be representable with 32 bit identifiers

So count those numbers and if possible use 32 bit identifiers when using compressed oops.

The counting will take some time (in a single thread), the renaming will cost a bit and the output will be different from before (Symbols and JNI handles will no longer be pointer addresses), so I suggest that we put the new behaviour behind a new JVM flag.

The reason for storing object identifiers as 32 bit entries is that it saves a bit of space (22% on test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpTest.java). One alternative is remapping the identifiers after dumping, and possibly adding better compression. That will create another step for users that I have been told is complicating stuff too much.