RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v3]
Сергей Цыпанов
duke at openjdk.org
Mon Jul 11 12:25:39 UTC 2022
On Mon, 11 Jul 2022 08:02:43 GMT, Сергей Цыпанов <duke at openjdk.org> wrote:
>> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it. Is there a better way than adding a non-functional argument?
>> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.
>>
>> The constructor should be private, it has a very narrow scope of use given the lack of checking its args.
>>
>> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
>> it would have broader applicability then this point fix.
>> I would be interesting to ask the compiler folks if that's a future optimization.
>> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.
>
> Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params.
Benchmark results after:
Benchmark Mode Cnt Score Error Units
StringConstructor.newStringFromArray avgt 50 4,354 ± 0,195 ns/op
StringConstructor.newStringFromArrayWithCharset avgt 50 4,035 ± 0,088 ns/op
StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,166 ± 0,062 ns/op
StringConstructor.newStringFromRangedArray avgt 50 4,132 ± 0,054 ns/op
StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,416 ± 0,206 ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,421 ± 0,041 ns/op
-------------
PR: https://git.openjdk.org/jdk/pull/9407
More information about the security-dev
mailing list