Bytecode generation, Source code mappings, JCov, Future (Patch)

[Alex Rau]

Here's a patch which enables the compiler to generate trace  
information. By using -Xtrace as compiler argument the compiler  
generates .trace files beside the .class files. A trace file consists  
of n Integer tupel < trace serial id, source code offset start,  
source code offset end> with fields (standard java) big-endian  
encoding. The trace serial ids are referenced in the byte code of  
each class in an attribute TraceID ( embedded in the code attribute  
of every method). This patch provides functional tests except for  
adding the attribute in the class file (difficult to test). I have to  
very the latter that it works as it should and/or find a way to test  
that.

However it should be sufficient to discuss the implementation. As  
soon as the patch is acceptable I'll submit the SCA.

Some implementation comments:

- the current encoding of the trace files are *not* ASCII files as I  
initially said to workaround the open question how Integer's should  
be represented in ASCII (fixed length vs. variable length with field  
separators)
- the output is written by a separate TraceWriter class beside  
ClassWriter. I think in general this is fine, however TraceWriter and  
ClassWriter both are more coupled to CRTable than I like. I think  
CRTable knows a little bit too much about representation in class and  
trace files
- existing JCov stuff is mostly untouched and reused for creating the  
trace files

Best Regards,

  Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tracepatch.diff
Type: application/octet-stream
Size: 80348 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080421/dff9f6b6/tracepatch.diff 
-------------- next part --------------


PS: to be applied in ./langtools/ with patch -p1 < tracepatch.diff



On 19.04.2008, at 20:34, John Rose wrote:

> On Apr 19, 2008, at 4:27 AM, Alex Rau wrote:
>> what John meant with token serial numbers
>
> Serial = sequentially assigned.  For some definition of token,  
> first token in file gets serial number 1, second gets 2, etc.  If  
> complete file has N tokens, last token serial number is N.  It's  
> almost the same as byte offset, just (a) more compact and (b) more  
> stable under semantically null edits.  FWIW.
>
> Use byte offsets for simplicity!
>
> -- John