Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <604480064.1226561324310.JavaMail.jira@brutus>
Date: Wed, 12 Nov 2008 23:28:44 -0800 (PST)
From: "Wenlong Li (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-6002) Startup cost is high for Harmony
In-Reply-To: <1001978583.1224684584498.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wenlong Li updated HARMONY-6002:
--------------------------------

    Attachment: loaded_class_release.txt

Here are the loaded classes and jars during startup. we can package these classes into one jar file, and read other classes/jars on demand.

> Startup cost is high for Harmony
> --------------------------------
>
>                 Key: HARMONY-6002
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6002
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>         Environment: Windows system. Core 2 Quad-core machine
>            Reporter: Wenlong Li
>         Attachments: loaded_class_release.txt
>
>
> The startup time is long for the simple helloworld program. On a Core 2 Quad-core processor, running the simple helloworld program will take more than 300 ms. 
> For the startup benchmarks in SPECJVM2008, the startup cost of Harmony is also very high. For example, only several operations can be executed per minute.
> I am going to address the startup cost problem. At this moment, there are several approaches in my mind.
> (a) Add instrumentation code in Harmony to identify the hot functions. Also use VTune to identify the performance bottleneck
> (b) Reduce the number of loaded classes. The startup cost is proportional to the number of loaded classes. This approach may be helpful in improving startup performance, but may not be an effective solution.
> (c) Check the class lookup operation, and see whether there is some optimization opportunity.
> (d) Check the class file reading, and see whether I/O is the bottleneck.
> (e) Check whether memory access affects performance, and apply software prefetch technique
> These are my priliminary thoughts, and I would like to hear comments and advice to fix this problem. Any suggestion are welcome and appreciated. 

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