harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [classlib][archive] java.util.jar specialists/authors wanted to clarify manifest chunks
Date Thu, 14 Feb 2008 11:15:19 GMT
Hello, Nathan,
Thanks for your interest. I'm trying to resolve a performance problem
described at HARMONY-4569. Gregory mentions that methods write() from
nextChunk() are called too many times, see lines 187, 201 of
working_classlib/modules/archive/src/main/java/java/util/jar/InitManifest.java
This slows down Harmony VM in debug and interpreter modes and may
affect overall Eclipse startup since many jars are read in the
process. I'm trying to collect more data.

As far as I was able to advance reviewing the complex code it seemed
that either code or my understanding may be improved.
  * "chunks" hash table is used only for jar verification. Do we need
to initialize it for any manifest when this cost us much invocations?
Instead of using write() methods for creating chunks one may think of
remembering chunk positions in the stream, which should be read into
byte array using big buffers instead of individual writes.
  * It seems that manifests longer than 1024 characters may result in
"string too long" exception - the buffer they are read in just gets as
much characters from stream as possible, and reports error if the
stream is not read fully.
  * I don't know a reason why manifests are read in different
encodings. The spec [1] mentions UTF-8 only. Nice to know.
  * Close functionality of readLines and nextChunk containing long
conditional sequences may be rewritten in more transparent and
documented way. Generally idea behind "rewriting" of chunks is above
of my understanding: I have not noticed in the specification that line
breaks or anything else should be "rewritten" using eight-if algorithm
instead of taken as is. BTW, I have noticed that Tim was behind
readability improvements of the code. I wonder what was there before
and will check it after lunch.
  * The whole class InitManifest seems to be redundant and may be
replaced with a set of static methods. It seems that specific
functionality for two calls to InitManifest should be kept in the
place where InitManifest is called rather than passed to InitManifest
as a parameter for internal check.

I appreciate your comments and help.

[1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html

On Feb 14, 2008 6:00 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> Can you point out the painful bits (line numbers, etc)?
>
>
> On Feb 13, 2008 11:01 AM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > Hello folks,
> >
> > Do we have original
> > working_classlib/modules/archive/src/main/java/java/util/jar/ module
> > contributors on board? Could anyone clarify the reasons behind heavy
> > solution to copy manifest chunks into a separate hash table descried
> > at HARMONY-4569? Aren't entity hash table the only object which should
> > be populated?
> >
> > --
> > With best regards,
> > Alexei
> >
> > [1] http://issues.apache.org/jira/browse/HARMONY-4569
> >
>



-- 
With best regards,
Alexei

Mime
View raw message