Hi Yasumasa,
On 7/06/2018 10:43 PM, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8204531/webrev.00/
JBS:
https://bugs.openjdk.java.net/browse/JDK-8204531
We can use `jhsdb jsnap` to check all PerfData.
String values in PerfData are defined as jbyte array, but JSnap cannot
handle it well as following:
```
$ jhsdb jsnap --pid 28542 --all | less
sun.gc.cause=No
GC^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
```
You can see this value via `less` and `vim` on Linux. `^@` shows it is
non-ascii character.
So your synopsis says "remove unused chars following \0". Is that really
what is happening? I would have expected "new String(bytes, encoding)"
to stop processing bytes when it encounters a NUL!
PerfDataEntry has null-terminated C string. So we should restore as it
in Java layer.
If the issue is really "junk" beyond the \0 nul-terminator, how did we
get such values? Shouldn't the byte array already be terminated at the
NUL? Or is this just a raw representation of an array in the VM using
the exact length of the array regardless of content?
I see CStringUtilities.getString() both stops when it encounters a 0
value, and uses the default file encoding (else ASCII).
The fix seems perfectly reasonable, I'm just unclear where exactly this
"bad" data should have been stopped.
Thanks,
David
Thanks,
Yasumasa
