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