axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nishant kumar (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Updated: (AXIS-1771) Excessive Memory Use During Serialization/Deserialization
Date Wed, 19 Jan 2005 06:40:17 GMT
     [ http://issues.apache.org/jira/browse/AXIS-1771?page=history ]

nishant kumar updated AXIS-1771:
--------------------------------

    Attachment: SerializationContext.java.diff

as mentioned in my last comment

> 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


Mime
View raw message