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] Using BCEL for Pack200
Date Tue, 23 Oct 2007 18:01:12 GMT
I've got operands doing most of what they're supposed to do now with a
hacked ClassConstantPool. (Unfortunately, Sian and the rest of the world
can't see it yet because I'm still waiting on legal approval from my
employer. Sigh.)

Now I'm looking at building the ClassConstantPool. Right now, it appears
that no CPMethodRefs are being added. I kind of expect that they should be
added in Segment.buildClassFile(), similar to what happens with CPMethods -
but I'm not sure how the method references get located. How does a class
know which method refs it has?

Thanks again!

    Andrew Jr.


On 10/8/07, Alex Blewitt <alex.blewitt@gmail.com> wrote:
>
> 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
> expansion.
>
> 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 ...
>
> Alex.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message