You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org> on 2005/03/18 00:55:20 UTC
[jira] Resolved: (AXIS-1771) Excessive Memory Use During Serialization/Deserialization
[ http://issues.apache.org/jira/browse/AXIS-1771?page=history ]
Davanum Srinivas resolved AXIS-1771:
------------------------------------
Resolution: Fixed
Closing issue.
-- dims
> 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
> Priority: Blocker
> Attachments: MTC_venkat.java, MemoryTesterClient.java, MemoryTesterClient.java, SOAPmsg_multiref_false.xml, SOAPmsg_multiref_true.xml, SerializationContext.java.diff, axis-memory-use.gif, memory-use-test.tgz, memory-use-test.tgz, recursion.png
>
> 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