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 17:00:45 GMT
With the 5916 patch applied correctly (using isolate v4), I see no
differences. Let's apply it.

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

> 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