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] Using BCEL for Pack200
Date Wed, 24 Oct 2007 08:41:32 GMT
Hi Andrew,

On 23/10/2007, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
>
> 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?


I know the method refs are transmitted as part of the bytecode bands.  I
can't see them anywhere else in the spec but you could probably work it out
from that if you need to.

Thanks,

Sian

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



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