hg: jdk7/hotspot-rt/hotspot: 7003782: Update JVMTI version to 1.2 for jdk7

Changeset: 684faacebf20 Author:kamg Date: 2010-12-06 20:21 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/684faacebf20 7003782: Update JVMTI version to 1.2 for jdk7 Summary: Update minor version to 1.2 for jdk7 Reviewed-by: phh, dcubed ! src/share/vm/prims/jvmti.

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 964eae6d1cab Author:mduigou Date: 2010-12-06 19:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/964eae6d1cab 7004205: fixes handling of sane-gcc-compiler on 32-bit linux and solaris. Previously committed as 6998016 and 6998012 Reviewed-by: ohair, dholmes ! make

hg: jdk7/tl/jdk: 6986825: policytool can not save file.

Changeset: 34f8b6669273 Author:weijun Date: 2010-12-07 09:51 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34f8b6669273 6986825: policytool can not save file. Reviewed-by: wetmore ! src/share/classes/sun/security/tools/policytool/PolicyTool.java

hg: jdk7/hotspot-rt/hotspot: 4 new changesets

Changeset: 631f79e71e90 Author:tonyp Date: 2010-08-24 17:24 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/631f79e71e90 6974966: G1: unnecessary direct-to-old allocations Summary: This change revamps the slow allocation path of G1. Improvements include the follow

Re: request for review (S): rev JVMTI version number

Thumbs up from me. Don't forget to update the copyright years in jvmti.xml and jvmtiH.xsl. Dan On 12/6/2010 1:53 PM, Keith McGuigan wrote: http://cr.openjdk.java.net/~kamg/7003782/webrev.03/ Comme ça? -- - Keith On Dec 6, 2010, at 11:29 AM, Daniel D. Daugherty wrote: On 12/6/2010 8:22 A

hg: jdk7/tl/jdk: 6989148: (fs) zip provider should be available "out of the box"

Changeset: 9758119b818c Author:sherman Date: 2010-12-06 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9758119b818c 6989148: (fs) zip provider should be available "out of the box" Summary: zip filesystem provider update, add zipfs.jar into ext dir Reviewed-by: alanb !

Re: request for review (S): rev JVMTI version number

http://cr.openjdk.java.net/~kamg/7003782/webrev.03/ Comme ça? -- - Keith On Dec 6, 2010, at 11:29 AM, Daniel D. Daugherty wrote: On 12/6/2010 8:22 AM, Keith McGuigan wrote: This change updates the JVMTI revision number from 1.1 to 1.2, when Hotspot is placed in a jdk >= 7. http://cr.o

hg: jdk7/tl/jdk: 6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty

Changeset: e7ab4e27f1e1 Author:vinnie Date: 2010-12-06 18:52 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7ab4e27f1e1 6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty Reviewed-by: mullan ! src/share/classes/java

Re: request for review (S): rev JVMTI version number

On 12/6/2010 10:09 AM, Alan Bateman wrote: Daniel D. Daugherty wrote: : Then the agent would be wrong. :-) If the agent is smart enough to ask the new version, then it should be allowed to use that new version. By restricting JDK6 to version 1.1, you would be precluding a tool vendor from havin

Re: request for review (S): rev JVMTI version number

On Dec 6, 2010, at 11:29 AM, Daniel D. Daugherty wrote: src/share/vm/prims/jvmtiEnv.cpp Since JVM/TI version 1.0, 1.1 and (presumably) 1.2 are compatible with each other, you don't need to do this check. The relevant part of the JVM/TI spec is: http://download.oracle.com/javase/6/docs/

Re: request for review (S): rev JVMTI version number

Daniel D. Daugherty wrote: : Then the agent would be wrong. :-) If the agent is smart enough to ask the new version, then it should be allowed to use that new version. By restricting JDK6 to version 1.1, you would be precluding a tool vendor from having a single binary that could work on JDK5, J

Re: request for review (S): rev JVMTI version number

On 12/6/2010 9:43 AM, Alan Bateman wrote: Daniel D. Daugherty wrote: : > The returned environment may have a different version than the > requested version but the returned environment must be compatible. If a client asks for version 1.0 or version 1.1, then it is okay to return v

Re: request for review (S): rev JVMTI version number

Daniel D. Daugherty wrote: : > The returned environment may have a different version than the > requested version but the returned environment must be compatible. If a client asks for version 1.0 or version 1.1, then it is okay to return version 1.2 as long as the common parts betw

Re: request for review (S): rev JVMTI version number

On 12/6/2010 8:22 AM, Keith McGuigan wrote: This change updates the JVMTI revision number from 1.1 to 1.2, when Hotspot is placed in a jdk >= 7. http://cr.openjdk.java.net/~kamg/7003782/webrev.00/ Thanks for any review. src/share/vm/prims/jvmti.xml No comments. src/share/vm/prims/jvmti

Re: request for review (S): rev JVMTI version number

Keith McGuigan wrote: This change updates the JVMTI revision number from 1.1 to 1.2, when Hotspot is placed in a jdk >= 7. http://cr.openjdk.java.net/~kamg/7003782/webrev.00/ Thanks for any review. -- - Keith It's probably not an issue but if I'm a jdk5, then can I still request JVMTI 1.0?

request for review (S): rev JVMTI version number

This change updates the JVMTI revision number from 1.1 to 1.2, when Hotspot is placed in a jdk >= 7. http://cr.openjdk.java.net/~kamg/7003782/webrev.00/ Thanks for any review. -- - Keith

hg: jdk7/tl/langtools: 3 new changesets

Changeset: 5fb14e67c371 Author:mcimadamore Date: 2010-12-06 11:49 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5fb14e67c371 7003744: Compiler error concerning final variables Summary: Flow analysis does not cleanup init/uninint bit masks after for-loop Reviewed-by: jj