RFR: 8276220: Reduce excessive allocations in DateTimeFormatter [v3]

[Stephen Colebourne]

On Tue, 2 Nov 2021 11:03:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add fallback for values outside the allowable range

Changes requested by scolebourne (Author).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3158:

> 3156: 
> 3157:         // only instantiated and used if there's ever a value outside the allowed range
> 3158:         private FractionPrinterParser fallback;

This class has to be safe in a multi-threaded environment. I'm not convinced it is safe right now, as the usage doesn't follow the standard racy single check idiom. At a minimum, there needs to be a comment explaining the thread-safety issues.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3266:

> 3264:             if (!field.range().isValidIntValue(value)) {
> 3265:                 if (fallback == null) {
> 3266:                     fallback = new FractionPrinterParser(field, minWidth, maxWidth, decimalPoint, subsequentWidth);

It would be nice to see a test case cover this.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3290:

> 3288:             range.checkValidValue(value, field);
> 3289:             BigDecimal minBD = BigDecimal.valueOf(range.getMinimum());
> 3290:             BigDecimal rangeBD = BigDecimal.valueOf(range.getMaximum()).subtract(minBD).add(BigDecimal.ONE);

I wouldn't be surprised if there is a way to replace the use of `BigDecimal` with calculations using `long`.  Fundamentally, calculations like 15/60 -> 0.25 are not hard, but it depends on whether the exact results can be matched across a wide range of possible inputs.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3544:

> 3542:             BigDecimal valueBD = BigDecimal.valueOf(value).subtract(minBD);
> 3543:             BigDecimal fraction = valueBD.divide(rangeBD, 9, RoundingMode.FLOOR);
> 3544:             // stripTrailingZeros bug

I believe this bug was fixed a while back, so this code could be simplified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188