harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [classlib][pack200] Decoupling I/O and processing for unpacking scenario
Date Mon, 21 Jul 2008 19:22:19 GMT
Thanks, Andrew!

As for memory footprint, It would be bigger. Actually I see only two
actions that contribute much to the footprint:
 1. Pre-reading of segments. It can be controlled through
Segment.setPreread(...), which is, BTW, disabled by default.
 2. Pre-building of classes. I gonna make another patch for option
that controls it after 5916 is applied.

After that, we might focus on memory footprint at all. I see different
ways to eliminate a lot of garbage produced, will discuss them later.

Thanks,
Aleksey.

On Mon, Jul 21, 2008 at 8:02 PM, 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
View raw message