Oliver Deakin wrote:
Mark Hindess wrote:
In message <4a7031f1.3020...@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
