harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vm] Implement on-demand class library parsing to avoid unnecessary jar/zip parsing during startup (HARMONY-6039)
Date Fri, 12 Dec 2008 16:07:50 GMT
Wenlong Li wrote:
> The performance of on-demand library parsing is mostly from I/O (seek
> the jar, open the jar, read content for each class in the jar, etc).
> When disk cache is warm-up, the I/O impact is small, and then we see
> small performance improvement.

Ok, so that says that better indexing of the bytes we need to load on
start-up won't necessarily help.  We need to reduce the number of bytes
we load, or optimize the layout to help the loading speed up, right?

Or do you mean the time is spent loading the ZIP directories (rather
than class file bytes)?

Do you have some trace that shows what's happening?

> You see the bootclasspath property is pre-defined in
> working_classlib\depends\files, so I pre-define another property file
> which saves the class library info for each package. I assume the
> library in each module will not change over time, just like the
> bootclasspath property file. Of course, when new module is added, we
> need update these properties. Question is how Harmony revises the
> bootclasspath property now?

It is defined by parsing the bootclass.properties file.

> I will think about how to automatically extract the package info from
> manifest of each module, and save them in my defined property file at
> compiling time.
> Suggestion and comments are welcome and appreciated. :)

Don't bother yet :-)  Seriously.

If you say that the time is taken to seek and read the bytes for the ZIP
file directory...
  ...then why stop at building the index to show where packages are?
  ...why not build a full class level index?

If you are saying that the time is spent loading the actual class files
from disk, and not parsing the ZIP directory entries to search for the
location of the bytes then this won't help and we need to layout the
bytes in a way that optimizes for start-up reading - or allow overlapped
reading and defer to the OS - or ?


View raw message