harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Cornwall" <andrew.pack...@gmail.com>
Subject Re: [classlib][pack200] Decoupling I/O and processing for unpacking scenario
Date Mon, 21 Jul 2008 16:53:07 GMT
Hmm... I don't see a *performance* degradation, but I am seeing a problem
with resources when 5916 is applied. I've got at least one JAR file that is
missing resources when unpacked with 5916, but is not when 5916 isn't
applied. I'll have to look further.


On Mon, Jul 21, 2008 at 9:02 AM, Andrew Cornwall <andrew.pack200@gmail.com>
wrote:

> I can confirm no performance degradation with 5916. We should be careful to
> keep an eye on memory usage, though - doing all the reads first, then all
> the processing, then all the writes may cause us to get bigger, which could
> be an issue with large pack archives.
>
>
> On Mon, Jul 21, 2008 at 8:54 AM, Aleksey Shipilev <
> aleksey.shipilev@gmail.com> wrote:
>
>> Sian, Andrew,
>>
>> Can we commit HARMONY-5916 (I/O-processing decoupling)? It's rather a
>> huge patch, so it's inconvenient to use with rapidly-changed trunk,
>> and my measurements show no performance degradation in ST version.
>> Andrew, can you confirm no degradation?
>>
>> I had just updated patch to reflect latest changes.
>>
>> Thanks,
>> Aleksey.
>>
>> On Fri, Jul 18, 2008 at 9:20 PM, Andrew Cornwall
>> <andrew.pack200@gmail.com> wrote:
>> > I've been playing with HEAD + HARMONY-5916 + HARMONY-5918 on a dual-core
>> > machine (which is probably what the majority will have at least for
>> now). On
>> > my 467-file test case, it takes 57 seconds (vs 38 for the nonthreaded
>> > version).
>> >
>> > It also looks as if it's doing something funny with resources (and
>> possibly
>> > even some .class files). I see many more differences in output classes
>> than
>> > I see with the nonthreaded version. (This may be a difference in output
>> > order of the JAR file: my diff tool is pretty limited).
>> >
>> > On Fri, Jul 18, 2008 at 8:46 AM, Sian January <
>> sianjanuary@googlemail.com>
>> > wrote:
>> >
>> >> According to the spec, "The value #archive_size is either zero or
>> declares
>> >> the number of bytes in the archive segment, starting immediately after
>> >> #archive_size_lo and before #archive_next_count and ending with the
>> last
>> >> band, the *file_bits band. (That is, a non-zero size includes the size
>> of
>> >> #archive_next_count, *file_bits, and everything in between.) "
>> >>
>> >> So you'll need to minus a few bytes for the values you've already read
>> from
>> >> the second half of the header.
>> >>
>> >>
>> >> On 18/07/2008, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
>> >> >
>> >> > Sian,
>> >> >
>> >> > On Fri, Jul 18, 2008 at 5:29 PM, Sian January
>> >> > <sianjanuary@googlemail.com> wrote:
>> >> > >> Awesome! Am I understanding correctly: this value determines
the
>> size
>> >> > >> of segment? If yes, can you point me how to access this value?
Is
>> >> > >> there API in current implementation?
>> >> > > Yes - use SegmentHeader.getArchiveSize()
>> >> >
>> >> > Does spec cover any alignment/padding constraints for segments?
>> >> > What exactly archive size specify?
>> >> >
>> >> > I'm doing this one [1]:
>> >> > 1. Reading the header of segment (moved from readSegment).
>> >> > 2. Check the field value, then either
>> >> > 3a. Read the segment into byte array and wrap it with BAIS, then
>> >> > read from BAIS
>> >> > 3b. Read the segment from global input stream
>> >> >
>> >> > I can only read first segment, second fails to read with the "bad
>> >> > header" exception.
>> >> >
>> >> > Thanks,
>> >> > Aleksey.
>> >> >
>> >> > [1]
>> >> >    void unpackRead(InputStream in) throws IOException,
>> Pack200Exception {
>> >> >        if (!in.markSupported())
>> >> >            in = new BufferedInputStream(in);
>> >> >
>> >> >        header = new SegmentHeader(this);
>> >> >        header.read(in);
>> >> >
>> >> >        int size = (int)header.getArchiveSize();
>> >> >
>> >> >        if (size != 0) {
>> >> >            byte[] data = new byte[size];
>> >> >            in.read(data);
>> >> >            bin = new ByteArrayInputStream(data);
>> >> >
>> >> >            readSegment(bin);
>> >> >        } else {
>> >> >            readSegment(in);
>> >> >        }
>> >> >    }
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Unless stated otherwise above:
>> >> IBM United Kingdom Limited - Registered in England and Wales with
>> number
>> >> 741598.
>> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> 3AU
>> >>
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message