Re: [jira] Commented: (AXIS-1771) Excessive Memory Use During Serialization/Deserialization

[Nishant Kumar <ni...@itellix.com>]

you are right the identity of Integers won't be maintained.

but this object sharing is generally meant for beans not for integers.
it is important for beans because they can be modified. so when you
change a bean property you will want it to reflect everywhere.
but Integers, Strings are immutable so for all business purpose
indentical and equal imply the same.

but the reason i suggested this is that in the code string were treated
as primitives. ie identity of strings were not being maintained even
before my suggested change. so why not apply the same for primitive
wrappers.

thanks,
nishant.

On Wed, 2005-01-19 at 13:08, David Jencks wrote:
> I'm a beginner at this, but..
> 
> given the class
> 
> public class Foo {
> private Integer bar1;
> private Integer bar2;
> 
> public Foo(Integer bar1, Integer bar2) {
> this.bar1 = bar1;
> this.bar2 = bar2;
> }
> 
> //getters and setters elided
> 
> public boolean degenerate() {
> return bar1 == bar2;
> }
> 
> and the instance
> 
> Integer one = new Integer(1);
> Foo foo1 = new Foo(one, one);
> 
> assert foo1.degenerate();
> 
> after serialization and deserialization, resulting in foo2,
> 
> assert !foo2.degenerate();
> 
> Is this a problem?
> 
> thanks
> david jencks
> 
> 
> On Jan 18, 2005, at 10:40 PM, nishant kumar (JIRA) wrote:
> 
> >      [  
> > http://issues.apache.org/jira/browse/AXIS-1771? 
> > page=comments#action_57757 ]
> >
> > nishant kumar commented on AXIS-1771:
> > -------------------------------------
> >
> > deserialization is taking so much memory because serialization has  
> > created too many multirefs. even for ints. this happens because the  
> > int is wrapped as Integer and the code thinks that it is not a  
> > primitive. so just added a method isPrimitiveWrapper which is used to  
> > prevent creation of multirefs for primitive wrappers.
> >
> > using this the size of the encoded string was reduced from 1170kb to  
> > 966kb and the memory utilization during deserialization was also  
> > reduced by 2MB.
> >
> > here is a solution for this.
> > just create
> >
> > Index: src/org/apache/axis/encoding/SerializationContext.java
> > @@ -566,6 +566,22 @@
> >          return getTypeMapping().getTypeQName(cls);
> >      }
> >
> > +
> > +       private boolean isPrimitiveWrapper(Object value)
> > +       {
> > +               if (value == null) return true;
> > +               Class javaType = value.getClass();
> > +               if (javaType == Integer.class) return true;
> > +               if (javaType == Long.class) return true;
> > +               if (javaType == Double.class) return true;
> > +               if (javaType == Float.class) return true;
> > +               if (javaType == Boolean.class) return true;
> > +               if (javaType == Short.class) return true;
> > +               if (javaType == Character.class) return true;
> > +               if (javaType == Byte.class) return true;
> > +               return false;
> > +       }
> > +
> >      /**
> >       * Indicates whether the object should be interpretted as a  
> > primitive
> >       * for the purposes of multi-ref processing.  A primitive value
> > @@ -800,7 +816,7 @@
> >              // Objects appear equal.
> >
> >              if (doMultiRefs && isEncoded() &&
> > -                    (value != forceSer) && !isPrimitive(value)) {
> > +                    (value != forceSer) && !isPrimitive(value) &&  
> > !isPrimitiveWrapper(value)) {
> >                  if (multiRefIndex == -1)
> >                      multiRefValues = new HashMap();
> >
> >
> >> Excessive Memory Use During Serialization/Deserialization
> >> ---------------------------------------------------------
> >>
> >>          Key: AXIS-1771
> >>          URL: http://issues.apache.org/jira/browse/AXIS-1771
> >>      Project: Axis
> >>         Type: Bug
> >>   Components: Basic Architecture
> >>     Versions: 1.2RC2
> >>  Environment: JDK 1.4.2, Mac OS X, Linux, Windows
> >>     Reporter: Peter Molettiere
> >>     Assignee: Venkat Reddy
> >>  Attachments: SerializationContext.java.diff, memory-use-test.tgz
> >>
> >> Axis uses pathological amounts of memory during the  
> >> serialization/deserialization process.
> >> We see about a 30 to 1 ratio of memory used during (de)serialization  
> >> to in-memory representation of the objects being (de)serialized. So  
> >> ser/deser in axis of a 2M graph of objects uses 288M of memory!  
> >> Further, the memory used seems to scale linearly with the size of the  
> >> object graph being serialized.
> >> The memory used does seem to be released once serialization is done,  
> >> so this isn't a leak.
> >> Using the attached example code, (based on the code used to  
> >> demonstrate AXIS-1423) you can see this behavior. The test  
> >> automatically runs with a max heap size of 1024M, and runs out of  
> >> memory serializing a 28M object graph.
> >> As provided, it generates the following output:
> >> Buildfile: build.xml
> >> build:
> >>     [javac] Compiling 1 source file to /Users/pietro/Work/Axis Memory  
> >> Test/build/classes
> >> run:
> >>      [java] - Unable to find required classes  
> >> (javax.activation.DataHandler and javax.mail.internet.MimeMultipart).  
> >> Attachment support is disabled.
> >>      [java] Created tree with 5 levels and 3 children at each level
> >>      [java] Axis used 13 MBytes to serialize 230 KBytes, a ratio of  
> >> 30.0
> >>      [java] GC freed 13 MBytes
> >>      [java] Created tree with 5 levels and 4 children at each level
> >>      [java] Axis used 71 MBytes to serialize 1 MBytes, a ratio of 31.0
> >>      [java] GC freed 71 MBytes
> >>      [java] Created tree with 5 levels and 5 children at each level
> >>      [java] Axis used 288 MBytes to serialize 2 MBytes, a ratio of  
> >> 51.0
> >>      [java] GC freed 287 MBytes
> >>      [java] Created tree with 5 levels and 6 children at each level
> >>      [java] Axis used 671 MBytes to serialize 11 MBytes, a ratio of  
> >> 29.0
> >>      [java] GC freed 675 MBytes
> >>      [java] Created tree with 5 levels and 7 children at each level
> >>      [java] Out of Memory serializing 28 MBytes tree.
> >>      [java] Java Result: 1
> >> BUILD SUCCESSFUL
> >> Total time: 2 minutes 51 seconds
> >> Note that the ratios are halved from the reported values, since it  
> >> includes both serialization and deserialization of the object graph.  
> >> So axis uses 30.5M to serialize a 1M message, and another 30.5M to  
> >> deserialize it, resulting in the reported 71M reported above. Also,  
> >> notice that the ratio stays close to 30 to 1 regardless of object  
> >> graph size. This is the linear scaling I mention above.
> >> Note also, that if you tweak the code to generate very small object  
> >> graphs, you see extremely high ratios, but I would expect this due to  
> >> simple one-time overhead to operate on very small amounts of data.  
> >> That's why I start with the graph size that I do.
> >>
> >
> > -- 
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> >    http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > If you want more information on JIRA, or have a bug to report see:
> >    http://www.atlassian.com/software/jira
> >
>