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 Wed, 24 Oct 2007 17:31:55 GMT
Whoops, I take it back. The references are in Segment.cpBands, but don't get
added to the ClassConstantPool in Segment.buildClassFile(int). How does
Pack200 decide which method references from cp_All get put in a class
constant pool?

On 10/24/07, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
>
> Tim: yes, the ACQ is on file :-)
>
> Sian: I know the indices of the method refs are in the bytecode bands, but
> it appears that CPMethodRefs for things like println() (methods called by
> the class, but not defined in the class) aren't being added to cp_All.
>
>     Andrew Jr.
>
>
> On 10/24/07, Sian January <sianjanuary@googlemail.com> wrote:
> >
> > 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