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

[Jonathan Gibbons]

Alex,

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


I'm sorry, it doesn't work that way. For legal reasons, we cannot look  
at your patch until you have signed the SCA.

Separately, although the work sounds like it has potential, I don't  
think it is appropriate to consider it for submission at this time.  
You are proposing adding a new output file format for the compiler,  
which is a step that should not be undertaken lightly. I'm not saying  
it needs anything as big as a JSR, but the file format should at least  
go through some sort of design review by the likely consumers of such  
a file. If nothing else, the Serviceability team should be involved,  
so that other JDK tools which might want to use the file are considered.

I've started a thread on serviceability-dev for anyone interested.

-- Jon




On Apr 23, 2008, at 3:19 AM, Alex Rau wrote:

> The patch sent 2 days ago was not sane (some changes were not diffed  
> correctly). Here's a corrected patch.
>
> Regards Alex
> <tracepatch.diff>
> 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
>>
>