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/01/19 04:28:19 UTC

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

     [ http://issues.apache.org/jira/browse/AXIS-1771?page=history ]

Davanum Srinivas reassigned AXIS-1771:
--------------------------------------

    Assign To: Venkat Reddy

Venkat,

i took the liberty of assigning this to you :)

-- 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
>  Attachments: 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