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 21:26:20 GMT
It appears that this is stored with the attributes (I think RSH). Alex, if
you're reading this - any hints on how AttributeLayouts/Attributes work? The
spec is not the clearest :-)

    Andrew Jr.


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