[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] JDK 1.6
|
Ron Bodkin wrote:
How will AspectJ support split bytecode verification (JSR 202)? I'm not sure
under what circumstances compiled code has to support it (presumably for
-1.6 code?).
Generally, 1.6 classes should be loaded faster with new verifier, so
falling back to old verifier will just make things slower.
If AspectJ ever using JSR/RET opcodes in the bytecode it is adding to
the instrumented methods it would have to be changed to explicit code
inlining.
Generally, methods generated for 1.6 bytecode are larger (since
compiler inlining all subroutines instead of using JSR/RET), so risk to
hit into the method size limit is higher now and may require special
handling on AspectJ side (eg. split methods or at least raise an error
during compilation time).
If I remember right, I understood that code defined by a
-javaagent will be verified with this change in Mustang: if that's right,
then it would impose a need for AspectJ load-time weaving to construct
verification proofs when weaving (just what we need: another time-consuming
operation for LTW :-/). I know that Eugene Kuleshov and the ASM team spent a
fair bit of time working on supporting split verification in ASM...
From bytecode point of view, methods of 1.6 bytecode should contain
special data structures (StackMapTable attribute) and most of the
transformations allied by AspectJ will break these data structures. So,
options are:
1. downgrade bytecode version to 1.5
2. incrementally update StackMapTable content. Definitely possible for
some transformations (we did it for ASM's local variable transformer
that allow to insert local variables in the middle of method), but it is
unclear if possible or reasonable easy to implement for all
transformations used by AspectJ
3. recalculate StackMapTable content after method transformation. Can be
expensive and require full type resolution.
Options 2 (in some cases) and 3 require type resolution (common super
type lookup when merging branches) and this would require to use class
repository to avoid unexpected classloading. Though, such repository
should be already in use by AspectJ.
regards,
Eugene
-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
Sent: Friday, July 28, 2006 11:43 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] JDK 1.6
Not quite true. The AspectJ 1.5.x compiler inside AJDT is based on the
Eclipse 3.1.0 compiler. In the next couple of months we will move to
the 3.2 compiler and gain some of its support for 1.6. There are
further things that need doing for weaving 1.6 bytecode.
Andy.
