harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li-Gang Wang (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4891) [drlvm][gc] heap exhaustion performance is five times slower than RI's one
Date Wed, 10 Oct 2007 09:05:50 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533665
] 

Li-Gang Wang commented on HARMONY-4891:
---------------------------------------

Alexei,
I looked through the freeMemory() implementation in GCv5. It couldn't be a perf problem cause
because it is just several addition operations.

And did you notice that the max heap size of RI in your test? It is about 63.56MB while it
is 256MB in GCv5. Smaller heap size means smaller space to be exhausted and collected, hence
results in shorter running time. Actually when I set -Xmx256M with RI, the comparison result
is as follows. GCv5's default setting of Xmx is 256M.
 
                                          GCv5                     GC of RI
Total heap memory       256M                     254M (although Xmx is set to 256M)
Heap utilization              98.633%               98.476% 
Execution time               87478ms              76619ms

My machine is a Pentium D dual core PC.

The perf ratio is 76619ms/87478ms = 87.6%, which has been larger than 70%. As to the perf
of the debug version, I think it is because debug version has many conditions to assure or
verify in most modules of DRLVM, which will take much time. It is not easy or not even necessary
to be tuned.

Alexei, would you like to check this? Thanks. 

 



> [drlvm][gc] heap exhaustion performance is five times slower than RI's one
> --------------------------------------------------------------------------
>
>                 Key: HARMONY-4891
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4891
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Windows, ia32
>            Reporter: Alexei Fedotov
>            Assignee: Xiao-Feng Li
>         Attachments: AbstractTest.java, GcTest.java, p-unit-0.12.jar, p-unit-extension-0.12.jar
>
>
> $ time win_ia32_msvc_release/deploy/jdk/jre/bin/java -cp bin/classes org.apache.harmony.test.stress.gc.share.GcTest
> [concurrent] Starting org.apache.harmony.test.stress.gc.share.GcTest
> [debug] total = 268435456, used = 2165188, ratio = 13, sizes = 1 - 2097152
> test() - [123709.342995ms,97.95109033584595%]
> total: 1, failures:0 (GREEN) - 123770.125835ms
> real    2m9.328s
> user    0m0.015s
> sys     0m0.000s
> $ time java -cp bin/classes org.apache.harmony.test.stress.gc.share.GcTest
> [concurrent] Starting org.apache.harmony.test.stress.gc.share.GcTest
> [debug] total = 66650112, used = 142120, ratio = 13, sizes = 1 - 2097152
> test() - [47643.880758ms,92.48719041912487%]
> total: 1, failures:0 (GREEN) - 47670.789275ms
> real    0m47.953s
> user    0m0.015s
> sys     0m0.000s
> The test itself runs exactly 30sec, and most of the time is taken by single-threaded
heap exhaustions to estimate the maximum size available for allocation.
> 1. It would be great to get within 70% of RI performance.
> 2. It would be great if one tunes debug build performance which is currently x40 times
slower. The debug build is used for regular stress test runs and this would help to save some
time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message