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 Wed, 24 Oct 2007 23:02:11 GMT
On 24/10/2007, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
> 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 :-)

You can say that again :-)

As far as I understand, it works like this; given a bytecode band
which contains (say) invokevirtual (c.f. invokespecial/invokestatic),
the operand corresponds to an index into bc_methodref. This in turn is
an index into cp_Method (c.f. cp_IMethod). I suspect they're in order,
so the first time you see an invokevirtual, you select the first entry
in bc_methodref; the second reference to invokevirtual is the next one
and so forth.

Once you've figured out which the methods are being called, they'll
need to be assembled in the class's bytecode. You'll need to infer a
CONSTANT_Methodref (10)   which is a pair of class_index and
name_and_type (and possibly, infer a CONSTANT_NameAndType (12) as
well). I never got this far, so it's all a guess :-)

NB the methods in the local class are treated differently; the
invokespecial  (183) is rewritten as invokespecial_this (207) (c.f.
static/virtual) then instead of pulling the arg from the bc_methodref,
it comes from bc_methodref_this. It's basically the same idea, but
instead of using 0..size(bc_method), it applies a filter on the set of
methods for those that exist in 'this' (which you'll know by now,
since it's defined in the method_descr ones). Sounds confusing, but
think of it like this:

methods: a b c d e
indexes 0 1 2 3 4

invokespecial c
invokespecial 3
-> 183 183 ... 2 4 (in bc_methodref)

OTOH if you only have 'c'  and 'e' in the current class, and it's
calling them in this, then
invokespecial_this c
invokespecial_this e
-> 207 207 .... 0 1 (in bc_methodref_this)

The attributes (and attribute layouts) aren't relevant to the method
calls here. In fact, forget the idea of 'calls' in the attribute calls
right now, and just hope to decode things without attributes :-)
Basically, for a method that has annotations (either parameter
annotations or others like @Serializable etc., there will be
attributes in there. If there aren't any, then you won't have to worry
about the attribute fields. IIRC the attribute layouts are defined in
a kind of mini-DSL, so an attribute 'call' would be a reference to a
predefined attribute layout; say, 1->ABCDEFG and 2->GEGEGEG, then an
attribute call would be '1' which corresponds to an attribute layout
ABCDEFG. Of course, what that attribute layout means is anyone's guess

Does any of that help?


View raw message