RFR: 8204531: Remove unused chars following '\0'

[David Holmes]

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
>