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 <[EMAIL PROTECTED]> wrote: > On Wed, Aug 6, 2008 at 2:44 AM, Andrew Cornwall > <[EMAIL PROTECTED]> 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. >
