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

[Alex Rau]

The patch sent 2 days ago was not sane (some changes were not diffed  
correctly). Here's a corrected patch.

Regards Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tracepatch.diff
Type: application/octet-stream
Size: 35203 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080423/88e46bf2/tracepatch.diff 
-------------- next part --------------

On 21.04.2008, at 19:07, Alex Rau wrote:

> 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
>
> <tracepatch.diff>
>
> 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
>