RFR: 8178889: Move creation of AbstractChronology comparators to call sites
Roger Riggs
Roger.Riggs at Oracle.com
Tue Apr 18 15:00:17 UTC 2017
Hi Claes,
Looks fine
Roger
On 4/18/2017 8:28 AM, Claes Redestad wrote:
> Hi,
>
> in AbstractChronology we define a number of comparators which could be
> moved to their
> respective call site and thus be lazily initialized when needed with
> no performance
> penalty.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178889
> Webrev: http://cr.openjdk.java.net/~redestad/8178889/jdk.01/
>
> Testing/analysis:
> - naive micro to show this doesn't cause a regression in steady
> state[1], for those in
> doubt
> - reduces executed bytecode by ~127K and drops 5 generated classes
> from startup of
> applications that depend on AbstractChronology but don't use any of
> these comparators
> - pass all java/time tests
>
> Thanks!
>
> /Claes
>
> [1]
> package org.openjdk;
> import org.openjdk.jmh.annotations.Benchmark;
> import java.time.chrono.*;
> import java.lang.reflect.*;
>
> public class ChronoComparatorBench {
>
> public static Method timeLineOrder;
>
> static {
> try {
> timeLineOrder =
> ChronoLocalDate.class.getDeclaredMethod("timeLineOrder");
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
>
> @Benchmark
> public Object getComparator() throws Exception {
> return timeLineOrder.invoke(null);
> }
> }
>
> -f 1 -tu us -bm avgt
>
> Benchmark Mode Cnt Score Error Units
> ChronoComparatorBench.getComparator avgt 20 5.979 ± 0.067 ns/op #
> before
> ChronoComparatorBench.getComparator avgt 20 5.975 ± 0.054 ns/op #
> after
More information about the core-libs-dev
mailing list