review request for 6798511/6860431: Include functionality of Surrogate in Character

Ulf Zibis Ulf.Zibis at gmx.de
Mon Mar 22 15:29:44 UTC 2010


Am 21.03.2010 20:39, schrieb Martin Buchholz:
> On Sun, Mar 21, 2010 at 00:56, Martin Buchholz<martinrb at google.com>  wrote:
>
>    
>> Study also:
>> http://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/base/Preconditions.java
>>      
> Sorry, the best (most recent) version of Preconditions to study is here:
>
> http://code.google.com/p/guava-libraries/source/browse/trunk/src/com/google/common/base/Preconditions.java
>
> especially this comment:
>    

Thanks for the update. I'm not sure if I understand right the below 
comment. Does it mean, that inlining the message from a constant is less 
fast than from a call on badMsg()?

-Ulf

>    /*
>     * All recent hotspots (as of 2009) *really* like to have the natural code
>     *
>     * if (guardExpression) {
>     *    throw new BadException(messageExpression);
>     * }
>     *
>     * refactored so that messageExpression is moved to a separate
>     * String-returning method.
>     *
>     * if (guardExpression) {
>     *    throw new BadException(badMsg(...));
>     * }
>     *
>     * The alternative natural refactorings into void or Exception-returning
>     * methods are much slower.  This is a big deal - we're talking factors of
>     * 2-8 in microbenchmarks, not just 10-20%.  (This is a hotspot optimizer
>     * bug, which should be fixed, but that's a separate, big project).
>     *
>     * The coding pattern above is heavily used in java.util, e.g. in ArrayList.
>     * There is a RangeCheckMicroBenchmark in the JDK that was used to test this.
>     *
>     * But the methods in this class want to throw different exceptions,
>     * depending on the args, so it appears that this pattern is not directly
>     * applicable.  But we can use the ridiculous, devious trick of throwing an
>     * exception in the middle of the construction of another exception.
>     * Hotspot is fine with that.
>     */
>
>
> Martin
>
>
>    




More information about the core-libs-dev mailing list