harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: [classlib] [pack200] Using BCEL for Pack200
Date Mon, 08 Oct 2007 21:58:37 GMT
I'm pretty sure that the 'resolve' on the bytecode was going down a
bad road. I had a thought that the original ByteCode would be some
kind of flyweight. However, the bytecode needs an operand, so zero-arg
bytecodes (e.g. return) are OK, but you'd need an operand to store the
non-zero arg bytecodes.

> BcBands.unpack() says:
>                        // TODO a lot of this needs to be encapsulated in the
>                        // place that
>                        // calculates what the arguments are, since (a) it
> will
>                        // need
>                        // to know where to get them, and (b) what to do with
>                        // them
>                        // once they've been gotten. But that's for another
>                        // time.
> and also:
>             // TODO Move creation of code attribute until after constant
>                    // pool resolved
> but ByteCode also has a resolve() method. Was your intent to resolve
> bytecode operands somewhere else outside of unpack() or in resolve()?

So, 'unpacking' is taking the bytecodes out of the bc_bands. For each
non-abstract method, there's a corresponding bytecode entry. Some are
'compressed' -- so I recall that there's one for super.<init>, which
would be 2 or 3 'real' bytecodes but only 1 pack200 code (see
bytecodes 202-205). So unpacking the bytecodes involves some level of

Now, the bytecode stuff is untyped whereas the pack200 bytecode stuff
is typed. So ldc from an ordinary file is an index into the class's
constant pool entry, but in Pack200 the operand is typed into one of
the {int,string,double}... pools, so it needs to know which one. I
can't recall off the top of my head, but something like '18'
corresponds to 'ldc int' and 238 corredponds to 'ldc double'.

In each case, the operand is an index into the class's constant pool
of the particular type. So if you have a class constant pool with
{1,2,3.0,"hello"}, then an index of '1' for int will be '1', and an
index for '1' for double will be '3.0', whilst an index of '1' for a
String will be "hello". So you need to know what type the bytecode is
refering to do the resolution. I was thinking that I'd export a
ByteCode+ConstantPool reference, so that after 'resolve' (i.e. map all
references to valid orders) you'd have the right index ID.

> Also, I don't understand the distinction between entries and others in
> ClassConstantPool. I was expecting either one ArrayList, or perhaps a unique
> ArrayList for each type in the class constant pool (i.e., one for ints,
> another for Strings, another for UTF8s, etc.) This may just be due to my
> lack of familiarity with the Pack200 spec - can you shine any light on this?

I'm sure there was a good reason at the time :-)

I don't recall anything specific about the pack200 implementation that
needed them. The only thing I can say is that according to the
implementation, the ConstantPoolEntrys are put into 'entries' and
ClassFileEntry subtypes that aren't ConstantPoolEntry are put into
'other' :-)

I might have set it up this way so that I could dump Methods with
bytecode into a ClassConstantPool and then resolve everything
together. In fact, the ByteCode is a subtype of ClassFileEntry, so it
might be why I had that. For the life of me, I can't remember why
though ...


View raw message