Re: [classlib][jdwp] Use java 6 branch JDWP in java 5 builds?

[Oliver Deakin <ol...@googlemail.com>]

Oliver Deakin wrote:
> Mark Hindess wrote:
>> In message <4A...@apache.org>, Gregory Shimansky writes:
>>  
>>> Oliver Deakin said the following on 29.07.2009 15:20:
>>>    
>>>> Hi all,
>>>>
>>>> After determining the cause of HARMONY-6246 [1] I discovered that 
>>>> it has already been fixed in the Java 6 branch, where I recently 
>>>> applied the contribution in HARMONY-6187 [2]. This got me thinking 
>>>> - there have been a number of bug fixes, performance improvements 
>>>> and portability changes made which were applied in that 
>>>> contribution and it is likely we will hit some of the same issues 
>>>> again in the Java 5 branch which have already been fixed in Java 6.
>>>>
>>>> Is it possible for us just to use the updated Java 6 branch JDWP in 
>>>> our Java 5 builds as well? Not only would we benefit from the code 
>>>> improvements made there, we would have one unified code base for 
>>>> JDWP (and possibly the whole of jdktools?).
>>>>
>>>> Any comments on this idea?
>>>>       
>>> If JDWP agent with Java6 update doesn't demand that VM support new 
>>> features of JVMTI (that is it can work with Java5 VM), I think it is 
>>> a good idea. Backporting all of the bugfixes may be quite difficult 
>>> since it is necessary to separate pure bugfixes from Java6 
>>> enhancements in [2].
>>>
>>>    
>>>> [1] https://issues.apache.org/jira/browse/HARMONY-6246
>>>> [2] https://issues.apache.org/jira/browse/HARMONY-6187
>>>>       
>>
>> Does the current combination of DRLVM and java6 branch JDWP work
>> consistently?  That is, do all of hardcoded (?) capabilities[0] that
>> JDWP claims are supported work with DRLVM as expected?
>>
>> Does any of the Java 5 JDWP functionality require 6.0 JVMTI calls?
>>   
>
> I need to do a bit more investigation on this - I would hope the Java 
> 5 functionality wouldn't require any JVMTI calls from Java 6, but will 
> need to confirm that. When I get a chance Ill have a look at the new 
> JVMTI functions introduced into Java 6 and where they are used in JDWP.

Ok, I wrote a quick Java class to scan all the source from the Java 5 
and 6 JDWP trees and pull out the JVMTI functions called, then compare 
the two lists to each other to see the differences. I found that in the 
Java 6 version we use the following 10 functions not available in Java 5 
JVMTI:

GetClassVersionNumbers
ForceEarlyReturnDouble/Float/Void/Long/Int/Object
GetOwnedMonitorStackDepthInfo
FollowReferences
GetConstantPool

I had a scan through the JDWP source containing these function calls and 
they all reside in JDWP event handlers which are Java 6 only, so I 
believe in a Java 5 debugging environment no Java 6 JVMTI calls should 
ever be made.

Im going to start investigating the test failures I see running the JDWP 
suites with the Java 6 agent to make sure they are not caused by any 
other use of Java 6 features I may have missed.

Regards,
Oliver

>
> Regards,
> Oliver
>
>> Assuming the answers to the above are yes, yes and no, then I see no
>> problem.  If anyone needs a JDWP for a Java 5 VM then we'd just need
>> to #ifdef the reporting of the capabilities to stop 6.0 calls being
>> invoked.
>>
>> Regards,
>>  Mark.
>>
>> [0] particularly java 6 ones such as canGetInstanceInfo,
>>     canRequestMonitorEvents, canGetMonitorFrameInfo,
>>    canUseSourceNameFilters, canGetConstantPool, and canForceEarlyReturn
>>
>>
>>
>>   
>

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [classlib][jdwp] Use java 6 branch JDWP in java 5 builds?

[Oliver Deakin <ol...@googlemail.com>]

Mark Hindess wrote:
> In message <4A...@googlemail.com>, Oliver Deakin writes:
>   
>> [snip]Im going to start investigating the test failures I see running the JDWP 
>> suites with the Java 6 agent to make sure they are not caused by any 
>> other use of Java 6 features I may have missed.
>>     
>
> I'm just doing another merge of jdktools/trunk to
> jdktools/branches/java6 and out of curiosity I checked the diff between
> trunk and java6 (excluding modules/jpda) and there were no differences
> except the merge changes I am testing.
>   

That's good to know, thanks.

> I wonder if we really need a java6 jdktools branch - we could always
> recreate it if we need it and at the moment it just seems to be
> overhead.
>   

Yep, I agree - Im looking at the JDWP test failures in the Java 6 branch 
at the moment and will be raising JIRAs for them. If they can be 
resolved then I think we will be in a good position to take JDWP in the 
Java 6 branch as head and remove that branch altogether.

Regards,
Oliver

> Regards,
>  Mark
>
>
>
>   

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [classlib][jdwp] Use java 6 branch JDWP in java 5 builds?

[Mark Hindess <ma...@googlemail.com>]

In message <4A...@googlemail.com>, Oliver Deakin writes:
>
> [snip]
>
> Ok, I wrote a quick Java class to scan all the source from the Java 5 
> and 6 JDWP trees and pull out the JVMTI functions called, then compare 
> the two lists to each other to see the differences. I found that in the 
> Java 6 version we use the following 10 functions not available in Java 5 
> JVMTI:
> 
> GetClassVersionNumbers
> ForceEarlyReturnDouble/Float/Void/Long/Int/Object
> GetOwnedMonitorStackDepthInfo
> FollowReferences
> GetConstantPool
> 
> I had a scan through the JDWP source containing these function calls and 
> they all reside in JDWP event handlers which are Java 6 only, so I 
> believe in a Java 5 debugging environment no Java 6 JVMTI calls should 
> ever be made.

Excellent.  I don't see much point in maintaining two copies.
 
> Im going to start investigating the test failures I see running the JDWP 
> suites with the Java 6 agent to make sure they are not caused by any 
> other use of Java 6 features I may have missed.

I'm just doing another merge of jdktools/trunk to
jdktools/branches/java6 and out of curiosity I checked the diff between
trunk and java6 (excluding modules/jpda) and there were no differences
except the merge changes I am testing.

I wonder if we really need a java6 jdktools branch - we could always
recreate it if we need it and at the moment it just seems to be
overhead.

Regards,
 Mark