harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [classlib][pack200] Decoupling I/O and processing for unpacking scenario
Date Tue, 22 Jul 2008 09:44:17 GMT
Ok - I will review the patch today.

On 21/07/2008, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
>
> 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
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>



-- 
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