RFR(S): 8145015: jni_GetStringCritical asserts for empty strings

David Holmes david.holmes at oracle.com
Mon Dec 14 07:25:59 UTC 2015

+1 from me. My only query is whether:

3194   jchar* ret;

should retain the const, as the return type is "const jchar *"?


On 14/12/2015 5:11 PM, Tobias Hartmann wrote:
> Hi Volker,
> thanks for taking care of this! Your fix looks good to me (not a reviewer).
> Best,
> Tobias
> On 09.12.2015 18:53, Volker Simonis wrote:
>> Hi,
>> can somebody please review and sponsor the following fix:
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145015/
>> https://bugs.openjdk.java.net/browse/JDK-8145015
>> The problem is that change "8141132: JEP 254: Compact Strings" removed
>> the handling for empty strings from jni_GetStringCritical(). As a
>> consequence, the functions will now assert with:
>> assert(is_within_bounds(which)) failed: index 0 out of bounds 0
>> if called with a string of length zero (because it tries to access the
>> zeroth element of a zero-length array).
>> The fix is trivial, just use 's_value->base(T_CHAR)' instead of
>> 's_value->char_at_addr(0)'.
>> While doing this fix I also noticed that jni_GetStringCritical()
>> doesn't handle out-of-memory situations when creating a new character
>> array (before this wasn't necessary because it always returned the
>> original character array, but now with compressed strings it may have
>> to allocate a new array). So I've also added the new check by using
>> Notice that I also allocate one extra character for zero termination.
>> While it seems that this is not strictly necessary, it is now the same
>> code like in jni_GetStringChars(). And it again simplifies the
>> handling of zero-length strings. Without the extra character it would
>> be hard to distinguish out-of-memory errors from the allocation of
>> zero bytes, because malloc() is free to return NULL if called with an
>> allocation size of zero.
>> Thank you and best regards,
>> Volker

More information about the hotspot-dev mailing list