glassfish
  1. glassfish
  2. GLASSFISH-14927

[PERF] Performance regression in ORB copyObject

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1_ms07
    • Fix Version/s: 3.1_ms07
    • Component/s: orb
    • Labels:
      None

      Description

      We are still observing some cases where the corba Util.copyObject() is regressed in performance from 2.1 to 3.1. In particular, trade2 has a Quote EJB. In 3.1, copying that EJB takes a very long time; the copyObject goes into the Fallback copier, and the time to serialize/deserialize the 5 member hashtable held by that bean is quite large. In 2.x, the hashtable is never serialized/deserialized; presumably it is using the reflective copier.

      1. orb.tgz
        2.76 MB
        Ken Cavanaugh
      2. server.log.gz
        42 kB
        Scott Oaks

        Issue Links

          Activity

          Hide
          Ken Cavanaugh added a comment -

          Can you attach information about the data members and type of the Quote EJB? I don't know why we are
          falling back for this object.

          Show
          Ken Cavanaugh added a comment - Can you attach information about the data members and type of the Quote EJB? I don't know why we are falling back for this object.
          Hide
          Scott Oaks added a comment -

          Attached is the server.log file javax.enterprise.resource.corba.level=FINE.

          Show
          Scott Oaks added a comment - Attached is the server.log file javax.enterprise.resource.corba.level=FINE.
          Hide
          Ken Cavanaugh added a comment -

          I've attached a gzipped tarball of the ORB that fixes the
          logger problem that blocked getting information on the
          fallback copier behavior.

          Show
          Ken Cavanaugh added a comment - I've attached a gzipped tarball of the ORB that fixes the logger problem that blocked getting information on the fallback copier behavior.
          Hide
          Scott Oaks added a comment -

          Falling back because it is a subclass:

          [#|2010-12-09T08:10:10.241-0800|FINE|glassfish3.1|javax.enterprise.resource.corba.orbutil.copyobject|ThreadID=16;_ThreadName=Thread-1;ClassName=com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator;MethodName=handleFullLogging;object=s:1,193.0,details;details=details;price=193.0;symbol=s:1;_Key=trade.QuoteKey@1b6ea;|ORBOCOPY00001: Object copy failed on copy of

          {object=s:1,193.0,details details=details price=193.0 symbol=s:1 __Key=trade.QuoteKey@1b6ea}

          which has type class com.ibm.ivj.ejb.runtime.AccessBeanHashtable|#]

          Show
          Scott Oaks added a comment - Falling back because it is a subclass: [#|2010-12-09T08:10:10.241-0800|FINE|glassfish3.1|javax.enterprise.resource.corba.orbutil.copyobject| ThreadID=16;_ThreadName=Thread-1;ClassName=com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator;MethodName=handleFullLogging;object=s:1,193.0,details;details=details;price=193.0;symbol=s:1; _Key=trade.QuoteKey@1b6ea;|ORBOCOPY00001: Object copy failed on copy of {object=s:1,193.0,details details=details price=193.0 symbol=s:1 __Key=trade.QuoteKey@1b6ea} which has type class com.ibm.ivj.ejb.runtime.AccessBeanHashtable|#]
          Hide
          Ken Cavanaugh added a comment -

          Thanks, that's the information I need. The copying of implementations of Map is controlled in the
          copyobject code by the ClassCopierFactoryPipelineImpl.mapClasses array, which lists the map implementations
          that should be copied by a special map copier, instead of reflectively. Unfortunately the current implementation
          requires that all superclasses of a class copied reflectively must also be copied reflectively, so
          use of a mapCopier forces a subclass of a class in mapClasses to use the fallback copier (which explains the
          regression).

          There are currently only two Map implementations that are known to need the map copier:

          • IdentityHashMap, due to the peculiarities of the NULL_KEY value in its implementation]
          • LinkedHashMap, in case a very long linked list causes a stack overflow (we could live
            with the possibility of stack overflow in most cases, though at least one customer has
            encountered it).

          GF 3.0 had only IdentityHashMap in the mapCopier list. For GF 3.1, I had all of the standard
          JDK Map implementations in the list. I am changing this for ORB b019 to be only
          IdentityHashMap and LinkedHashMap.

          Show
          Ken Cavanaugh added a comment - Thanks, that's the information I need. The copying of implementations of Map is controlled in the copyobject code by the ClassCopierFactoryPipelineImpl.mapClasses array, which lists the map implementations that should be copied by a special map copier, instead of reflectively. Unfortunately the current implementation requires that all superclasses of a class copied reflectively must also be copied reflectively, so use of a mapCopier forces a subclass of a class in mapClasses to use the fallback copier (which explains the regression). There are currently only two Map implementations that are known to need the map copier: IdentityHashMap, due to the peculiarities of the NULL_KEY value in its implementation] LinkedHashMap, in case a very long linked list causes a stack overflow (we could live with the possibility of stack overflow in most cases, though at least one customer has encountered it). GF 3.0 had only IdentityHashMap in the mapCopier list. For GF 3.1, I had all of the standard JDK Map implementations in the list. I am changing this for ORB b019 to be only IdentityHashMap and LinkedHashMap.
          Hide
          Ken Cavanaugh added a comment -

          Fixed with ORB 3.1.0-b019 integration in GF svn rev 43637.

          Show
          Ken Cavanaugh added a comment - Fixed with ORB 3.1.0-b019 integration in GF svn rev 43637.

            People

            • Assignee:
              Ken Cavanaugh
              Reporter:
              Scott Oaks
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: