Derby
  1. Derby
  2. DERBY-5873

Avoid unnecessary allocation of Number instances in client/server

    Details

    • Bug behavior facts:
      Performance

      Description

      Java 5 introduced some new static factory methods (called valueOf()) in the Number sub-classes, to be used in preference of the constructors unless a fresh instance is required. The valueOf() methods are allowed to cache and reuse objects, possibly reducing the allocation/gc cost and the memory footprint. For example, Integer.valueOf(int) uses a pre-allocated cache for values between -128 and +127 by default (the cache size can be tuned with JVM flags).

      Now that the server and client code is compiled against Java 5 libraries, we should use the valueOf() methods to get those benefits. Note also that Java 5 auto-boxing of numbers uses these methods implicitly, so in many cases we can just remove the calls to the constructor and the compiler will automatically insert the calls for us.

      1. d5873-1a.diff
        130 kB
        Knut Anders Hatlen
      2. d5873-2a-bigdec.diff
        6 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          The attached patch replaces all calls to constructors for classes in the java.lang.Number class hierarchy or java.lang.Boolean with static factory methods, or with auto-boxing where that's possible and more convenient, in the client and drda code trees.

          All the regression tests passed with the patch.

          Show
          Knut Anders Hatlen added a comment - The attached patch replaces all calls to constructors for classes in the java.lang.Number class hierarchy or java.lang.Boolean with static factory methods, or with auto-boxing where that's possible and more convenient, in the client and drda code trees. All the regression tests passed with the patch.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1365468.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1365468.
          Hide
          Knut Anders Hatlen added a comment -

          In the first patch, I forgot about the BigDecimal and BigInteger classes, which are also sub-classes of Number. I see that Java 5 introduced the following valueOf() factory methods for BigDecimal that we could use:

          • valueOf(double) - replaces the "new BigDecimal(Double.toString(<double>))" idiom used to convert a double to BigDecimal without changing the precision
          • valueOf(long, int) - could be used to create a BigDecimal value directly instead of going via a BigInteger and/or byte[], if the unscaled value is known to fit in a long

          Will post a followup patch.

          Show
          Knut Anders Hatlen added a comment - In the first patch, I forgot about the BigDecimal and BigInteger classes, which are also sub-classes of Number. I see that Java 5 introduced the following valueOf() factory methods for BigDecimal that we could use: valueOf(double) - replaces the "new BigDecimal(Double.toString(<double>))" idiom used to convert a double to BigDecimal without changing the precision valueOf(long, int) - could be used to create a BigDecimal value directly instead of going via a BigInteger and/or byte[], if the unscaled value is known to fit in a long Will post a followup patch.
          Hide
          Knut Anders Hatlen added a comment -

          The 2a patch makes CrossConverters and Cursor use BigDecimal.valueOf(double) when converting a double to a BigDecimal. It also makes Decimal and DDMReader use BigDecimal.valueOf(double,int) when parsing a BigDecimal with precision up to 18 sent over the wire.

          All the regression tests passed.

          Show
          Knut Anders Hatlen added a comment - The 2a patch makes CrossConverters and Cursor use BigDecimal.valueOf(double) when converting a double to a BigDecimal. It also makes Decimal and DDMReader use BigDecimal.valueOf(double,int) when parsing a BigDecimal with precision up to 18 sent over the wire. All the regression tests passed.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1372405.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1372405.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development