If I run the JVM on a 32-bit code, it resets its LD_LIBRARY_PATH, and
then exec's itself to use the new path. We implemented a workaround
in the analyzer, to collect data from the JVM after its exec.

When -d64 is specified, jvm first exec's its 64-bit version, and then resets
its LD_LIBRARY_PATH, and exec's again. We collect data on the first
64-bit exec, which is useless to the user, and the second exec's JVM fails
because the profiling timer ticks. We will fix that in our code, so it
won't fail, but we still won't get the data from the "real" jvm execution.

Can JVM be fixed to always do one exec: if it's to be 32-bit set LD_LIBRARY_PATH
and then exec; if it's to be 64-bit, set LD_LIBRARY_PATH, and then exec
the 64-bit version.

We can't really workaround this without parsing the user's java arguments,
and figuring out how many exec's are expected, and I really think it's a bad
idea to have us need to understand java's arguments.