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