You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Aleksey Shipilev <al...@gmail.com> on 2008/08/06 00:59:43 UTC
[classlib][pack200][performance] Some ClassConstantPool contents may not be needed (was: Re: [classlib][pack200][performance] Profiling unpacking scenario)
On Wed, Aug 6, 2008 at 2:44 AM, Andrew Cornwall
<an...@gmail.com> wrote:
> I'm not sure about [5]=5931 - if I remember right, I'd taken out ByteCode
> processing in add(), and that led to problems resolving bytecodes which
> referred to things in the classpool. But that was a while ago; I'm
> interested in trying it and seeing if there are any differences in my wad of
> 40M or so testcases.
I know the reason of this.
Before HARMONY-5906, adding nested entries rely on "entries" contents:
1. Traverse all "entries"
2. Get their nested entries into temporal
3. Put their nested entries to "entries" (via CCP.add)
4. Repeat until "entries" stops growing.
If you eliminating ByteCode in CCP.add, then you breaking the
recursion on step 3.
After HARMONY-5906, the algorithm for adding nested entries was
rewritten to more optimal:
1. Put all entries into "parents"
2. Traverse "parents"
3. Get "parents" nested entries and put them to "children"
4. Put all "parents" to "entries" (via CCP.add)
5. Overwrite "parents" with "children"
6. Repeat until "entries" stops growing
Here you can see that eliminating ByteCode in CCP.add() does NOT break
the recursion, since ByteCode remain in "parents"/"children".
Thanks,
Aleksey.
Re: [classlib][pack200][performance] Some ClassConstantPool contents may not be needed (was: Re: [classlib][pack200][performance] Profiling unpacking scenario)
Posted by Sian January <si...@googlemail.com>.
That would be good if it's possible. I think it's going to require a
bit more work though. I just did a quick test to try and eliminate
Attributes and CPMembers in the same way as you did for Bytecode and
there were lots of test failures. Haven't looked into them in detail,
but it looks like the code that builds the class files is depending on
all those things being in the ClassConstantPool.
On 27/08/2008, Aleksey Shipilev <al...@gmail.com> wrote:
> Sian,
>
> Even after the HARMONY-5931 [1], which brings up another +40% boost to
> pack200, ClassConstantPool contents:
> - 80% are ConstantPoolEntry subclasses' instances
> - 20% are not ConstantPoolEntry subclasses' instances
>
> I wonder whether we can eliminate remaining 20% too, then eliminate
> the "others" collection in CCP and simplify the code. The exact
> contents you can see in the JIRA [1], there are various attributes...
>
> Thanks,
> Aleksey.
>
> [1] https://issues.apache.org/jira/browse/HARMONY-5931
>
>
> On Wed, Aug 6, 2008 at 2:59 AM, Aleksey Shipilev
> <al...@gmail.com> wrote:
> > On Wed, Aug 6, 2008 at 2:44 AM, Andrew Cornwall
> > <an...@gmail.com> wrote:
> >> I'm not sure about [5]=5931 - if I remember right, I'd taken out ByteCode
> >> processing in add(), and that led to problems resolving bytecodes which
> >> referred to things in the classpool. But that was a while ago; I'm
> >> interested in trying it and seeing if there are any differences in my wad of
> >> 40M or so testcases.
> > I know the reason of this.
> >
> > Before HARMONY-5906, adding nested entries rely on "entries" contents:
> > 1. Traverse all "entries"
> > 2. Get their nested entries into temporal
> > 3. Put their nested entries to "entries" (via CCP.add)
> > 4. Repeat until "entries" stops growing.
> >
> > If you eliminating ByteCode in CCP.add, then you breaking the
> > recursion on step 3.
> >
> > After HARMONY-5906, the algorithm for adding nested entries was
> > rewritten to more optimal:
> > 1. Put all entries into "parents"
> > 2. Traverse "parents"
> > 3. Get "parents" nested entries and put them to "children"
> > 4. Put all "parents" to "entries" (via CCP.add)
> > 5. Overwrite "parents" with "children"
> > 6. Repeat until "entries" stops growing
> >
> > Here you can see that eliminating ByteCode in CCP.add() does NOT break
> > the recursion, since ByteCode remain in "parents"/"children".
> >
> > Thanks,
> > Aleksey.
> >
>
--
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
Re: [classlib][pack200][performance] Some ClassConstantPool contents may not be needed (was: Re: [classlib][pack200][performance] Profiling unpacking scenario)
Posted by Aleksey Shipilev <al...@gmail.com>.
Sian,
Even after the HARMONY-5931 [1], which brings up another +40% boost to
pack200, ClassConstantPool contents:
- 80% are ConstantPoolEntry subclasses' instances
- 20% are not ConstantPoolEntry subclasses' instances
I wonder whether we can eliminate remaining 20% too, then eliminate
the "others" collection in CCP and simplify the code. The exact
contents you can see in the JIRA [1], there are various attributes...
Thanks,
Aleksey.
[1] https://issues.apache.org/jira/browse/HARMONY-5931
On Wed, Aug 6, 2008 at 2:59 AM, Aleksey Shipilev
<al...@gmail.com> wrote:
> On Wed, Aug 6, 2008 at 2:44 AM, Andrew Cornwall
> <an...@gmail.com> wrote:
>> I'm not sure about [5]=5931 - if I remember right, I'd taken out ByteCode
>> processing in add(), and that led to problems resolving bytecodes which
>> referred to things in the classpool. But that was a while ago; I'm
>> interested in trying it and seeing if there are any differences in my wad of
>> 40M or so testcases.
> I know the reason of this.
>
> Before HARMONY-5906, adding nested entries rely on "entries" contents:
> 1. Traverse all "entries"
> 2. Get their nested entries into temporal
> 3. Put their nested entries to "entries" (via CCP.add)
> 4. Repeat until "entries" stops growing.
>
> If you eliminating ByteCode in CCP.add, then you breaking the
> recursion on step 3.
>
> After HARMONY-5906, the algorithm for adding nested entries was
> rewritten to more optimal:
> 1. Put all entries into "parents"
> 2. Traverse "parents"
> 3. Get "parents" nested entries and put them to "children"
> 4. Put all "parents" to "entries" (via CCP.add)
> 5. Overwrite "parents" with "children"
> 6. Repeat until "entries" stops growing
>
> Here you can see that eliminating ByteCode in CCP.add() does NOT break
> the recursion, since ByteCode remain in "parents"/"children".
>
> Thanks,
> Aleksey.
>