Classfile format changes for more efficient processing

[Michael Ernst]

Eric Bruneton suggests some classfile format changes that will make it more
efficient to process (e.g., read and write) class files.  See below for his
full message.  I plan to accept all of these suggestions.  Here are my
comments, in a slightly different order than Eric's:

(c) Putting instruction annotations on the Code attribute rather than the
method_info structure is logical; the current design was an oversight.

(a) I hadn't considered requiring instruction annotations to be sorted, but
I have no objection to this and I am inclined to trust Eric's concerns
about speed.

(b) Changing the order of fields in the "type_annotation" structure, so
that the new JSR 308 fields come before the original fields inherited from
the "annotation" structure, puts the most interesting and relevant
information first.  I am willing to make this change.  I should note that
this suggestion is orthogonal to those made by John Rose, which we are also
planning to implement in whole or in part, so the "type_annotation"
structure will change slightly again.

Expert Group, let me know if you have any further comments or concerns.

Eric, thanks for trying an implementation and making these suggestions
based on it!

		    -Mike


> Subject: prototype implementation of JSR 308 in OW2 ASM
> From: Eric Bruneton <ebruneton at free.fr>
> To: type-annotations-spec-comments at openjdk.java.net,
	FORAX <remi.forax at univ-mlv.fr>
> Date: Thu, 13 Sep 2012 07:19:50 +0200>
>
> Hi,
>
> For your information, I added a prototype "implementation" of JSR 308 in
> the ASM_5_FUTURE branch of the OW2 ASM repository:
>
> http://websvn.ow2.org/listing.php?repname=asm&path=%2Fbranches%2FASM_5_FUTURE%2F
>
> Added code compared to HEAD:
>
> http://websvn.ow2.org/comp.php?repname=asm&compare[]=%2Fbranches%2FASM_5_FUTURE@1642&compare[]=%2Fbranches%2FASM_5_FUTURE@1643
>
> This prototype does not implement the exact specification in its current
> state. I used 3 modifications to make the implementation easier and more
> efficient. They are the following:
>
> a) in Section 3, I assumed that the elements in the "annotations" array of
> the Runtime[In]VisibleTypeAnnotations_attribute are sorted by increasing
> order of bytecode offset (for target_type >= 0x86; the others can be in any
> order, and also interleaved with instruction annotations).
> b) in Section 3.1, in the type_annotation structure, I put the target_type
> and target_info fields *before* the original fields from the "annotation"
> structure.
> c) in sections 3.3.7 to 3.3.10, I replaced "A
> Runtime[In]visibleTypeAnnotations attribute containing a ***_target appears
> in the attributes table of a method_info structure." with "... in the
> attributes table of a Code attribute.". I also replaced, in Section 3, "A
> type annotation is stored in a Runtime[In]visibleTypeAnnotations attribute
> on the smallest enclosing class, field, or method." with "... class, field,
> method, or
> Code structure.".
>
> Changes a) and c) improve the performance of class parsing in ClassReader,
> by avoiding multiple parsing of the annotations structure, and also by
> avoiding sorting passes. Also change c) seems more natural, independently
> of any implementation consideration, since existing attributes that refer
> to bytecode are currently stored as attributes of the Code attribute (like
> LineNumberTable, LocalVariableTable, LocalVariableTypeTable and
> StackMapTable).
>
> Change b) improves the performance of class generation in
> ClassWriter. Indeed, with the proposed ASM 5 API, the target is known
> before the annotation, and so it is easier to store it first in the
> type_annotation structure. This change also improves the parsing
> performance in ClassReader.
>
> Do you think it would be possible to make these changes in the
> specification? Especially change b), which is really critical to get good
> class generation performance with ASM?
>
> Eric