RFR: 8213741: Consolidate Object and String Stringifiers
Claes Redestad
claes.redestad at oracle.com
Mon Nov 12 18:47:43 UTC 2018
On 2018-11-12 16:56, Aleksey Shipilev wrote:
> On 11/12/2018 03:24 PM, Claes Redestad wrote:
>> Webrev: http://cr.openjdk.java.net/~redestad/8213741/jdk.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213741
> Looks good to me.
Thanks!
If anyone is wondering: With this and other recent improvements the
startup and footprint overheads of ISC will be about half compared to 11
GA, while keeping peak performance more or less the same. YMMV.
> *) Not sure this is significantly better than String.valueOf(String.valueOf(s)), as original comment
> suggests:
>
> 1701 String s;
> 1702 return (value == null || (s = value.toString()) == null) ? "null" : s;
Right, while String.valueOf(String.valueOf(value)); is semantically
neutral and possibly clearer in intent, I do see it perform
significantly worse (1.3x) on one microbenchmark. I've not delved into
exactly why - it could be either hitting an inlining limit or picking up
a polluted profile - but I think I'll keep it as-is.
>
> *) Do you really want new "static finals" be "private" as well? It seems to me the classes are
> private already, and maybe dropping some privates help to avoid some bridge methods? (Probably
> obsolete by nestmates, but still). It probably does not matter all that much for bootstrap code.
No bridge methods to be seen - verified by inspecting bytecode. Thanks
nestmates!
So it comes down to a question of style and what communicates intent the
best, and while I see arguments both ways on that account I think I'll
tend towards "as private as possible".
/Claes
More information about the core-libs-dev
mailing list