Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8074023

Clock.system(ZoneId) could be optimized to always return the same clock for a given zone.

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: tbd_minor
    • Component/s: core-libs
    • Labels:
      None

      Description

      Clock.systemUTC() has been optimized to return a constant.
      It would be good if Clock.systemDefaultZone() and Clock.system(ZoneId) could also be optimized to avoid creating new instance of Clock.SystemClock every time they are called.

      One possible solution was proposed on core-libs-dev:
      http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031759.html

        Issue Links

          Activity

          Hide
          scolebourne Stephen Colebourne added a comment -
          Checking the code, it turns out that for ZoneRegion (one subclass of ZoneId), a new ZoneId instance is created every time ZoneId.of() is called. The underlying ZoneRules are cached, but not the ZoneId.

          For ZoneOffset (the other subclass of ZoneId), caching occurs for offsets that are 15mins apart (a sensible balance of memory usage).

          It would seem reasonable to add caching for those ZoneRegion instances that have a non-offset based underlying ZoneRules. This would be done in ZoneRegion.ofId(). Those instances of ZoneRegion created by ZoneId.ofOffset() would not be cached.

          With caching of a sensible selection of both ZoneOffset and ZoneRegion, the issue referred to here could then be tackled. The cache within ZoneId would probably be lazy rather than eager.
          Show
          scolebourne Stephen Colebourne added a comment - Checking the code, it turns out that for ZoneRegion (one subclass of ZoneId), a new ZoneId instance is created every time ZoneId.of() is called. The underlying ZoneRules are cached, but not the ZoneId. For ZoneOffset (the other subclass of ZoneId), caching occurs for offsets that are 15mins apart (a sensible balance of memory usage). It would seem reasonable to add caching for those ZoneRegion instances that have a non-offset based underlying ZoneRules. This would be done in ZoneRegion.ofId(). Those instances of ZoneRegion created by ZoneId.ofOffset() would not be cached. With caching of a sensible selection of both ZoneOffset and ZoneRegion, the issue referred to here could then be tackled. The cache within ZoneId would probably be lazy rather than eager.

            People

            • Assignee:
              rriggs Roger Riggs
              Reporter:
              dfuchs Daniel Fuchs
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: