From eamonn.mcmanus at sun.com Tue Apr 1 05:46:43 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 01 Apr 2008 12:46:43 +0000 Subject: hg: jdk7/tl/jdk: 6610917: Define a generic NotificationFilter Message-ID: <20080401124655.CCAC0273F4@hg.openjdk.java.net> Changeset: 2965459a8ee7 Author: emcmanus Date: 2008-04-01 14:45 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2965459a8ee7 6610917: Define a generic NotificationFilter Summary: Adds javax.management.QueryNotificationFilter Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java + src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/javax/management/ObjectName.java + src/share/classes/javax/management/QueryNotificationFilter.java + test/javax/management/query/QueryNotifFilterTest.java From maurizio.cimadamore at sun.com Wed Apr 2 03:24:10 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:24:10 +0000 Subject: hg: jdk7/tl/langtools: 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Message-ID: <20080402102412.78BED27447@hg.openjdk.java.net> Changeset: 6e4cefcce80a Author: mcimadamore Date: 2008-04-02 11:20 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e4cefcce80a 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Summary: improved glb on type-inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6569789/T6569789.java From maurizio.cimadamore at sun.com Wed Apr 2 03:39:05 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:39:05 +0000 Subject: hg: jdk7/tl/langtools: 6509042: javac rejects class literals in enum constructors Message-ID: <20080402103907.1C6302744C@hg.openjdk.java.net> Changeset: aeaa0f482b28 Author: mcimadamore Date: 2008-04-02 11:38 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aeaa0f482b28 6509042: javac rejects class literals in enum constructors Summary: javac now distinguish between enum class literals and static fields Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/enum/T6509042.java From maurizio.cimadamore at sun.com Wed Apr 2 03:44:57 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:44:57 +0000 Subject: hg: jdk7/tl/langtools: 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Message-ID: <20080402104459.333CB27451@hg.openjdk.java.net> Changeset: adaa3fc51b60 Author: mcimadamore Date: 2008-04-02 11:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/adaa3fc51b60 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Summary: fixed lookup of field/methods on intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6531090/T6531090a.java + test/tools/javac/generics/6531090/T6531090b.java From Mandy.Chung at Sun.COM Thu Apr 3 00:20:44 2008 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Thu, 03 Apr 2008 00:20:44 -0700 Subject: 6610094: Add generic support for platform MXBeans of any type Message-ID: <47F4854C.7030806@sun.com> Please review the fix for: 6610094: Add generic support for platform MXBeans of any type Problem: The java.lang.management API defines the management interfaces for the Java virtual machine. The management interface for other components in the platform will reside in its own package. For example, the management interface for the logging facility is java.util.logging.LoggingMXBean. There is no easy way to find out what management interfaces are defined in the Java platform. In addition, when a new management interface is added in the platform, it needs to provide a factory method to obtain the platform MXBeans (e.g. java.util.logging.LogManager.getLoggerMXBean()). We expect that NIO and the new module system will define their management interfaces in JDK7. Solution: Add a new java.lang.management.PlatformManagedObject interface which provides a method to return the object name. All existing MXBean interfaces will be modified to extend this interface. (Note: In the interface summary, the methods count for the *MXBean interfaces reflects the number of methods added resulting from extending the PlatformManagedObject interface) Add new methods the in java.lang.management.ManagementFactory class: 1) A method to return the list of platform MXBeans that implement a given management interface in the running JVM 2) A method to return the list of platform MXBean proxies that implement a given management interface and in the given remote MBeanServerConnection 3) A method to return all MXBean interfaces for monitoring and managing the Java platform Webrev: Attached webrev.zip. This webrev also contains some code clean up including to throw AssertionError instead of InternalError. Thanks Mandy -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip.gz Type: application/x-tar Size: 1374483 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20080403/aa39b4b0/attachment.tar From Daniel.Fuchs at Sun.COM Thu Apr 3 09:44:23 2008 From: Daniel.Fuchs at Sun.COM (Daniel Fuchs) Date: Thu, 03 Apr 2008 18:44:23 +0200 Subject: 6610094: Add generic support for platform MXBeans of any type In-Reply-To: <47F4854C.7030806@sun.com> References: <47F4854C.7030806@sun.com> Message-ID: <47F50967.9040908@sun.com> Hy Mandy, Here are my comment. 1) ManagementFactory.java: lines 103-106 I am not sure I really like the idea of adding new methods to existing interfaces. 2) Logging.java: The implementation of getObjectName() is strange - I would have expected the ObjectName to be stored in a static final field. ObjectNames are immutable, so it is safe to have a static - you don't need to return a new object each time. Eamonn as recently added a public internal utility method to create an ObjectName from a String (com.sun.jmx.mbeanserver.Util.newObjectName(String)) http://hg.openjdk.java.net/jdk7/tl/jdk/file/2965459a8ee7/src/share/classes/com/sun/jmx/mbeanserver/Util.java so you could probably call that to initialize your static field... 3) ClassLoadingImpl.java, CompilationImpl.java, HotSpotDiagnostic.java, MemoryImpl.java, OperatingSystemImpl.java, RuntimeImpl.java, ThreadImpl.java OK I see you're using another Util.newObjectName() here - but the ObjectName could still be a static final field in these classes. 4) I see that sun.management.ManagementFactory is still there. Shouldn't it be merged with ManagementFactoryHelper? 5) I was a bit puzzled by the fact that PlatformComponent defines several components which contain each a different implementation of the same MBean (all sharing the same ObjectName). For instance if we look at OPRATING_SYSTEM, SUN_OPERATING_SYSTEM, SUN_UNIX_OPERATING_SYSTEM, it took me a while to understand that registration in getPlatformMBeanServer() worked because all these enum pointed towards the same MBean instance... Maybe some comment would have helped... ;-) 6) Maybe there should be a special case in the unit test which should try to guess which of the *OPERATING_SYSTEM case should be implemented, and verify that it is indeed the correct implementation which is registered, and compare with the result of the three calls: ManagementFactory.getPlatformMXBeans(java.lang.management.OperatingSystemMXBean.class); ManagementFactory.getPlatformMXBeans(com.sun.management.OperatingSystemMXBean.class); ManagementFactory.getPlatformMXBeans(com.sun.management.UnixOperatingSystemMXBean.class); Best regards, -- daniel http://blogs.sun.com/jmxetc Mandy Chung wrote: > Please review the fix for: > 6610094: Add generic support for platform MXBeans of any type > > Problem: > > The java.lang.management API defines the management interfaces for the Java > virtual machine. The management interface for other components in the > platform > will reside in its own package. For example, the management interface > for the > logging facility is java.util.logging.LoggingMXBean. > > There is no easy way to find out what management interfaces are defined in > the Java platform. In addition, when a new management interface is > added in > the platform, it needs to provide a factory method to obtain the platform > MXBeans (e.g. java.util.logging.LogManager.getLoggerMXBean()). We > expect that > NIO and the new module system will define their management interfaces in > JDK7. > > Solution: > > Add a new java.lang.management.PlatformManagedObject interface which > provides > a method to return the object name. All existing MXBean interfaces will be > modified to extend this interface. > > (Note: In the interface summary, the methods count for the *MXBean > interfaces > reflects the number of methods added resulting from extending the > PlatformManagedObject interface) > > Add new methods the in java.lang.management.ManagementFactory class: > 1) A method to return the list of platform MXBeans that implement a given > management interface in the running JVM > > 2) A method to return the list of platform MXBean proxies that implement > a given > management interface and in the given remote MBeanServerConnection > > 3) A method to return all MXBean interfaces for monitoring and managing the > Java platform > > Webrev: > Attached webrev.zip. This webrev also contains some code clean up > including to throw AssertionError instead of InternalError. > > Thanks > Mandy From Mandy.Chung at Sun.COM Thu Apr 3 13:49:00 2008 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Thu, 03 Apr 2008 13:49:00 -0700 Subject: 6610094: Add generic support for platform MXBeans of any type In-Reply-To: <47F50967.9040908@sun.com> References: <47F4854C.7030806@sun.com> <47F50967.9040908@sun.com> Message-ID: <47F542BC.4090508@Sun.com> Daniel Fuchs wrote: > Hy Mandy, > > Here are my comment. > > 1) ManagementFactory.java: lines 103-106 > I am not sure I really like the idea of adding new methods > to existing interfaces. This statement is a clarification in the specification for M&M support for the platform. For a platform management interface, only the JDK vendor will implement these interfaces and thus there is no compatibility issue. The other alternative to add new methods for existing MXBeans is to add new MXBean interfaces in new JDK releases which is overkilled. We considered these alternatives and decided in JDK 5 when we added the M&M API. > 2) Logging.java: The implementation of getObjectName() is > strange - I would have expected the ObjectName to be stored in > a static final field. > ObjectNames are immutable, so it is safe to have a static - you > don't need to return a new object each time. The MXBean interfaces can be used locally in the application in a non-JMX context. Thus the ObjectName is lazily created when needed. > Eamonn as recently added a public internal > utility method to create an ObjectName from a String > (com.sun.jmx.mbeanserver.Util.newObjectName(String)) > http://hg.openjdk.java.net/jdk7/tl/jdk/file/2965459a8ee7/src/share/classes/com/sun/jmx/mbeanserver/Util.java > > so you could probably call that to initialize your static > field... > Eamonn also mentioned that too. Thanks. > 3) ClassLoadingImpl.java, CompilationImpl.java, HotSpotDiagnostic.java, > MemoryImpl.java, OperatingSystemImpl.java, RuntimeImpl.java, > ThreadImpl.java > > OK I see you're using another Util.newObjectName() here - but > the ObjectName could still be a static final field in these classes. Same reason as above. > 4) I see that sun.management.ManagementFactory is still there. > Shouldn't it be merged with ManagementFactoryHelper? It was one class but it is splitted into 2 classes. I like Eamonn's suggestion to rename sun.management.ManagementFactory to something else so that the java.lang.management implementation is much cleaner. However, the HotSpot VM depends on a few methods in the sun.management.ManagementFactory class for constructing the memory pool and managers and so we have to keep this interface contract. > 5) I was a bit puzzled by the fact that PlatformComponent > defines several components which contain each a > different implementation of the same MBean (all sharing the > same ObjectName). > > For instance if we look at OPRATING_SYSTEM, SUN_OPERATING_SYSTEM, > SUN_UNIX_OPERATING_SYSTEM, it took me a while to understand that > registration in getPlatformMBeanServer() worked because all these > enum pointed towards the same MBean instance... > > Maybe some comment would have helped... ;-) Sure. I'll add some comment. > 6) Maybe there should be a special case in the unit test which > should try to guess which of the *OPERATING_SYSTEM case should > be implemented, and verify that it is indeed the > correct implementation which is registered, and compare with > the result of the three calls: > > ManagementFactory.getPlatformMXBeans(java.lang.management.OperatingSystemMXBean.class); > > ManagementFactory.getPlatformMXBeans(com.sun.management.OperatingSystemMXBean.class); > > ManagementFactory.getPlatformMXBeans(com.sun.management.UnixOperatingSystemMXBean.class); Good suggestion. I'll look into this. Thanks Mandy > > Best regards, > > -- daniel > http://blogs.sun.com/jmxetc > > > > Mandy Chung wrote: >> Please review the fix for: >> 6610094: Add generic support for platform MXBeans of any type >> >> Problem: >> >> The java.lang.management API defines the management interfaces for the >> Java >> virtual machine. The management interface for other components in the >> platform >> will reside in its own package. For example, the management interface >> for the >> logging facility is java.util.logging.LoggingMXBean. >> >> There is no easy way to find out what management interfaces are >> defined in >> the Java platform. In addition, when a new management interface is >> added in >> the platform, it needs to provide a factory method to obtain the platform >> MXBeans (e.g. java.util.logging.LogManager.getLoggerMXBean()). We >> expect that >> NIO and the new module system will define their management interfaces >> in JDK7. >> >> Solution: >> >> Add a new java.lang.management.PlatformManagedObject interface which >> provides >> a method to return the object name. All existing MXBean interfaces >> will be >> modified to extend this interface. >> >> (Note: In the interface summary, the methods count for the *MXBean >> interfaces >> reflects the number of methods added resulting from extending the >> PlatformManagedObject interface) >> >> Add new methods the in java.lang.management.ManagementFactory class: >> 1) A method to return the list of platform MXBeans that implement a given >> management interface in the running JVM >> >> 2) A method to return the list of platform MXBean proxies that >> implement a given >> management interface and in the given remote MBeanServerConnection >> >> 3) A method to return all MXBean interfaces for monitoring and >> managing the >> Java platform >> >> Webrev: >> Attached webrev.zip. This webrev also contains some code clean up >> including to throw AssertionError instead of InternalError. >> >> Thanks >> Mandy > From kumar.srinivasan at sun.com Thu Apr 3 18:10:20 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Fri, 04 Apr 2008 01:10:20 +0000 Subject: hg: jdk7/tl/langtools: 6570242: Regression test failures with Javac on win32. Message-ID: <20080404011022.14FE02754E@hg.openjdk.java.net> Changeset: ddd77d1c1b49 Author: ksrini Date: 2008-04-03 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ddd77d1c1b49 6570242: Regression test failures with Javac on win32. Summary: takes this test out of service until the reall bug is fixed Reviewed-by: jjg ! test/tools/javac/api/6431257/T6431257.java From bradford.wetmore at sun.com Mon Apr 7 14:38:37 2008 From: bradford.wetmore at sun.com (bradford.wetmore at sun.com) Date: Mon, 07 Apr 2008 21:38:37 +0000 Subject: hg: jdk7/tl/jdk: 14 new changesets Message-ID: <20080407214126.D82112765A@hg.openjdk.java.net> Changeset: a8d6215fa863 Author: weijun Date: 2008-03-20 11:57 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8d6215fa863 6670362: HTTP/SPNEGO should work across realms Reviewed-by: valeriep ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java Changeset: 74bc85c0f2a9 Author: valeriep Date: 2008-03-20 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74bc85c0f2a9 4898461: Support for ECB and CBC/PKCS5Padding Summary: Add support for ECB mode and PKCS5Padding Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + test/sun/security/pkcs11/Cipher/TestSymmCiphers.java Changeset: 66c2b0cfc896 Author: valeriep Date: 2008-03-20 17:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66c2b0cfc896 6572331: regression: cipher.wrap operation fails with CKR_ATTRIBUTE_VALUE_INVALID Summary: Check supported key size range and use encryption if needed Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyGenerator.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java Changeset: 84aced25a346 Author: valeriep Date: 2008-03-20 18:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84aced25a346 6599979: KeyStore.setEntry/setKeyEntry() do not override existing entry for secret key objects Summary: Override existing secret key entry when setEntry/setKeyEntry() is called Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: 05afbed1dc4f Author: valeriep Date: 2008-03-21 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05afbed1dc4f Merge Changeset: b22cbc65a360 Author: wetmore Date: 2008-03-28 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b22cbc65a360 Merge Changeset: 8805ae9d160c Author: valeriep Date: 2008-03-31 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8805ae9d160c 6681652: Two new regression test failures in pkcs11 code Summary: Fixed the test to not assume SunJCE provider being the provider for DES Reviewed-by: wetmore ! test/javax/crypto/Cipher/TestGetInstance.java Changeset: e1bf7407c933 Author: wetmore Date: 2008-03-31 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1bf7407c933 6469580: 1.5.0_08 JVM crashes in SignatureHandlerLibrary::add on Fujitsu Primepower platform Reviewed-by: andreas, valeriep, wetmore Contributed-by: chris.phillips at sun.com ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 17e93b7fb97d Author: valeriep Date: 2008-03-31 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/17e93b7fb97d 6682411: JCK test failed w/ ArrayIndexOutOfBoundException (-1) when decrypting with no data Summary: Fixed PKCS5Padding class with additional check and throw BadPaddingException if the check failed Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: c063b7fb55f7 Author: valeriep Date: 2008-03-31 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c063b7fb55f7 6682417: JCK test failed w/ ProviderException when decrypted data is not multiple of blocks Summary: Check for CKR_ENCRYPTED_DATA_LEN_RANGE and throw IllegalBlockSizeException Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 99b3301fc27c Author: valeriep Date: 2008-03-31 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99b3301fc27c Merge Changeset: df5d7e6ac15e Author: xuelei Date: 2008-04-02 22:44 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5d7e6ac15e 6668231: Presence of a critical subjectAltName causes JSSE's SunX509 to fail trusted checks Summary: make the critical extension known to end entity checker. Reviewed-by: wetmore, mullan ! src/share/classes/sun/security/validator/EndEntityChecker.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks Changeset: b70fc43afb8c Author: wetmore Date: 2008-04-06 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b70fc43afb8c 6683078: Update JCE framework and provider builds to work on read-only filesystems 6644659: Error in default target of make/javax/crypto in OpenJDK build Reviewed-by: valeriep, ohair ! make/com/sun/crypto/provider/Makefile ! make/common/shared/Defs.gmk ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: f4205a7bdfd4 Author: wetmore Date: 2008-04-07 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4205a7bdfd4 Merge From stephen.ryan at corp.aol.com Wed Apr 9 02:35:54 2008 From: stephen.ryan at corp.aol.com (Stephen Ryan) Date: Wed, 09 Apr 2008 10:35:54 +0100 Subject: jconsole question -- probably the wrong mailing list but here goes... Message-ID: <47FC8DFA.4080301@corp.aol.com> Hi, I was wondering if its possible to get the size of the classes loaded from jConsole. Im seeing a lot of GC's in the Eden Space in a server thats basically doing nothing. Im thinking that the jvm is trying to load classes in there that are just too close to the size of that space. Any help appreciated! Stephen. From Alan.Bateman at Sun.COM Wed Apr 9 03:02:01 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 09 Apr 2008 11:02:01 +0100 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FC8DFA.4080301@corp.aol.com> References: <47FC8DFA.4080301@corp.aol.com> Message-ID: <47FC9419.90507@sun.com> Stephen Ryan wrote: > Hi, > > I was wondering if its possible to get the size of the classes loaded > from jConsole. Im seeing a lot of GC's in the Eden Space in a server > thats basically doing nothing. Im thinking that the jvm is trying to > load classes in there that are just too close to the size of that space. > > Any help appreciated! > > Stephen. Classes are essentially allocated from the perm generation so I don't think this is what you are observing. Instead it is likely that you are observing the effect of the JMX agent in the target VM due to the polling by jconsole. Each time jconsole updates the display it must interact with agent in the agent VM so this means some objects are allocated which can lead to periodic scavenging that you observe. You can reduce the polling interval via jconsole's -interval=value option (interval is specified in seconds). The management interface for class loading doesn't include the size of the classes but if you try jstat then you can get this information (jstat -class for example). -Alan. From maurizio.cimadamore at sun.com Wed Apr 9 06:06:27 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 13:06:27 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409130634.DC303276F6@hg.openjdk.java.net> Changeset: 961ae2608114 Author: mcimadamore Date: 2008-04-09 13:19 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/961ae2608114 6531075: Missing synthetic casts when accessing fields/methods of intersection types including type variables Summary: bug when javac generates code involving intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6531075/T6531075.java Changeset: d032d5090fd5 Author: mcimadamore Date: 2008-04-09 13:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d032d5090fd5 5009937: hiding versus generics versus binary compatibility Summary: missing implementation of JLS 8.4.8.3 (different arguments with same erasure not always triggering a compiler error) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/5009937/T5009937.java + test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java Changeset: 57ba4f70f0d8 Author: mcimadamore Date: 2008-04-09 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/57ba4f70f0d8 6365166: javac (generic) unable to resolve methods Summary: Unignore regression test as this bug has been fixed by CR 6278587 Reviewed-by: jjg + test/tools/javac/generics/inference/6356673/T6365166.java Changeset: 25338c55e458 Author: mcimadamore Date: 2008-04-09 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/25338c55e458 6481655: Parser confused by combination of parens and explicit type args Summary: Bug in the parser caused by the fact that explicit type arguments are disabled when parsing parenthesized expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/Parser.java + test/tools/javac/generics/T6481655.java From stephen.ryan at corp.aol.com Wed Apr 9 06:24:37 2008 From: stephen.ryan at corp.aol.com (Stephen Ryan) Date: Wed, 09 Apr 2008 14:24:37 +0100 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FC9419.90507@sun.com> References: <47FC8DFA.4080301@corp.aol.com> <47FC9419.90507@sun.com> Message-ID: <47FCC395.40108@corp.aol.com> Hi Alan, Thanks for that but Im not sure its that at all. I've other servers being monitored and Ive never seen jConsole have this effect. I did a jmap on the server and saw some huge numbers. Im begining to think that theres bad code thats causing classes to be loaded too many times. The 'Classes' view in jConsole is showing me a constant rise in class numbers. I would have expected this to be more or less stable, considering that the server is serving about 4 requests per second. The CPU is pretty busy too.Busy garbage collecting the eden space I guess. I was considering increasing the eden space to see if that alleavates the problem, but if its a code problem, it wont help at all. Thanks! Stephen. Alan Bateman wrote: > Stephen Ryan wrote: > >> Hi, >> >> I was wondering if its possible to get the size of the classes loaded >> from jConsole. Im seeing a lot of GC's in the Eden Space in a server >> thats basically doing nothing. Im thinking that the jvm is trying to >> load classes in there that are just too close to the size of that space. >> >> Any help appreciated! >> >> Stephen. > > Classes are essentially allocated from the perm generation so I don't > think this is what you are observing. Instead it is likely that you > are observing the effect of the JMX agent in the target VM due to the > polling by jconsole. Each time jconsole updates the display it must > interact with agent in the agent VM so this means some objects are > allocated which can lead to periodic scavenging that you observe. You > can reduce the polling interval via jconsole's -interval=value option > (interval is specified in seconds). The management interface for class > loading doesn't include the size of the classes but if you try jstat > then you can get this information (jstat -class for example). > > -Alan. > -- Stephen Ryan Principal QA Engineer AOL Technologies Ireland Ltd. 3040 Lake Drive, City West Business Campus Saggart, County Dublin, Ireland Work: +353 1 4692115 stephen.ryan at corp.aol.com "To destroy the concept of money, is going to take money" -Stang From Luis-Miguel.Alventosa at Sun.COM Wed Apr 9 06:45:27 2008 From: Luis-Miguel.Alventosa at Sun.COM (Luis-Miguel Alventosa) Date: Wed, 09 Apr 2008 15:45:27 +0200 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FCC395.40108@corp.aol.com> References: <47FC8DFA.4080301@corp.aol.com> <47FC9419.90507@sun.com> <47FCC395.40108@corp.aol.com> Message-ID: <47FCC877.7060903@Sun.COM> Hi Stephen, Could you try to use jmap -dump and/or jmap -histo to see the names of the instances being created? You could also have a look at VisualVM in order to profile the application. https://visualvm.dev.java.net Regards, Luis > On 4/9/2008 3:24 PM, Stephen Ryan wrote: > > Hi Alan, > Thanks for that but Im not sure its that at all. I've other servers > being monitored and Ive never seen jConsole have this effect. I did a > jmap on the server and saw some huge numbers. Im begining to think that > theres bad code thats causing classes to be loaded too many times. The > 'Classes' view in jConsole is showing me a constant rise in class > numbers. I would have expected this to be more or less stable, > considering that the server is serving about 4 requests per second. The > CPU is pretty busy too.Busy garbage collecting the eden space I guess. > > I was considering increasing the eden space to see if that alleavates > the problem, but if its a code problem, it wont help at all. > > Thanks! > Stephen. > > Alan Bateman wrote: > >> Stephen Ryan wrote: >> >>> Hi, >>> >>> I was wondering if its possible to get the size of the classes loaded >>> from jConsole. Im seeing a lot of GC's in the Eden Space in a server >>> thats basically doing nothing. Im thinking that the jvm is trying to >>> load classes in there that are just too close to the size of that space. >>> >>> Any help appreciated! >>> >>> Stephen. >> >> Classes are essentially allocated from the perm generation so I don't >> think this is what you are observing. Instead it is likely that you >> are observing the effect of the JMX agent in the target VM due to the >> polling by jconsole. Each time jconsole updates the display it must >> interact with agent in the agent VM so this means some objects are >> allocated which can lead to periodic scavenging that you observe. You >> can reduce the polling interval via jconsole's -interval=value option >> (interval is specified in seconds). The management interface for class >> loading doesn't include the size of the classes but if you try jstat >> then you can get this information (jstat -class for example). >> >> -Alan. From stephen.ryan at corp.aol.com Wed Apr 9 06:57:25 2008 From: stephen.ryan at corp.aol.com (Stephen Ryan) Date: Wed, 09 Apr 2008 14:57:25 +0100 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FCC877.7060903@Sun.COM> References: <47FC8DFA.4080301@corp.aol.com> <47FC9419.90507@sun.com> <47FCC395.40108@corp.aol.com> <47FCC877.7060903@Sun.COM> Message-ID: <47FCCB45.3070107@corp.aol.com> Hi Luis. I just discovered visualvm this morning in my quest. Its has some nice features and all the same stuff that jconsole delivers as well. Heres the top chunk of what jmap -histo delivers. Also the classes loaded count is still increasing. Im starting to lean towards a bug in the code of my webserver. Size Count Class description ------------------------------------------------------- 70483456 210902 char[] 22539768 939157 java.lang.String 10608936 442039 java.util.HashMap$Entry 3876512 18922 java.util.HashMap$Entry[] 3823192 22119 * ConstMethodKlass 3046768 4349 byte[] 2724968 47155 java.lang.Object[] ... Luis-Miguel Alventosa wrote: > Hi Stephen, > > Could you try to use jmap -dump and/or jmap -histo to see the names > of the instances being created? > > You could also have a look at VisualVM in order to profile the > application. > > https://visualvm.dev.java.net > > Regards, > Luis > > > On 4/9/2008 3:24 PM, Stephen Ryan wrote: > > > > Hi Alan, > > Thanks for that but Im not sure its that at all. I've other servers > > being monitored and Ive never seen jConsole have this effect. I did a > > jmap on the server and saw some huge numbers. Im begining to think that > > theres bad code thats causing classes to be loaded too many times. The > > 'Classes' view in jConsole is showing me a constant rise in class > > numbers. I would have expected this to be more or less stable, > > considering that the server is serving about 4 requests per second. The > > CPU is pretty busy too.Busy garbage collecting the eden space I guess. > > > > I was considering increasing the eden space to see if that alleavates > > the problem, but if its a code problem, it wont help at all. > > > > Thanks! > > Stephen. > > > > Alan Bateman wrote: > > > >> Stephen Ryan wrote: > >> > >>> Hi, > >>> > >>> I was wondering if its possible to get the size of the classes loaded > >>> from jConsole. Im seeing a lot of GC's in the Eden Space in a server > >>> thats basically doing nothing. Im thinking that the jvm is trying to > >>> load classes in there that are just too close to the size of that > space. > >>> > >>> Any help appreciated! > >>> > >>> Stephen. > >> > >> Classes are essentially allocated from the perm generation so I don't > >> think this is what you are observing. Instead it is likely that you > >> are observing the effect of the JMX agent in the target VM due to the > >> polling by jconsole. Each time jconsole updates the display it must > >> interact with agent in the agent VM so this means some objects are > >> allocated which can lead to periodic scavenging that you observe. You > >> can reduce the polling interval via jconsole's -interval=value option > >> (interval is specified in seconds). The management interface for class > >> loading doesn't include the size of the classes but if you try jstat > >> then you can get this information (jstat -class for example). > >> > >> -Alan. > -- Stephen Ryan Principal QA Engineer AOL Technologies Ireland Ltd. 3040 Lake Drive, City West Business Campus Saggart, County Dublin, Ireland Work: +353 1 4692115 stephen.ryan at corp.aol.com "To destroy the concept of money, is going to take money" -Stang From Luis-Miguel.Alventosa at Sun.COM Wed Apr 9 07:11:27 2008 From: Luis-Miguel.Alventosa at Sun.COM (Luis-Miguel Alventosa) Date: Wed, 09 Apr 2008 16:11:27 +0200 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FCCB45.3070107@corp.aol.com> References: <47FC8DFA.4080301@corp.aol.com> <47FC9419.90507@sun.com> <47FCC395.40108@corp.aol.com> <47FCC877.7060903@Sun.COM> <47FCCB45.3070107@corp.aol.com> Message-ID: <47FCCE8F.2040707@Sun.COM> It looks like someone is adding lots of entries to a HashMap, probably with Strings as keys so try to find out in your code where this could happen. Regards, Luis > On 4/9/2008 3:57 PM, Stephen Ryan wrote: > > Hi Luis. > > I just discovered visualvm this morning in my quest. Its has some nice > features and all the same stuff that jconsole delivers as well. > > Heres the top chunk of what jmap -histo delivers. Also the classes > loaded count is still increasing. Im starting to lean towards a bug in > the code of my webserver. > > Size Count Class description > ------------------------------------------------------- > 70483456 210902 char[] > 22539768 939157 java.lang.String > 10608936 442039 java.util.HashMap$Entry > 3876512 18922 java.util.HashMap$Entry[] > 3823192 22119 * ConstMethodKlass > 3046768 4349 byte[] > 2724968 47155 java.lang.Object[] ... > > Luis-Miguel Alventosa wrote: > >> Hi Stephen, >> >> Could you try to use jmap -dump and/or jmap -histo to see the names >> of the instances being created? >> >> You could also have a look at VisualVM in order to profile the >> application. >> >> https://visualvm.dev.java.net >> >> Regards, >> Luis >> >> > On 4/9/2008 3:24 PM, Stephen Ryan wrote: >> > >> > Hi Alan, >> > Thanks for that but Im not sure its that at all. I've other servers >> > being monitored and Ive never seen jConsole have this effect. I did a >> > jmap on the server and saw some huge numbers. Im begining to think that >> > theres bad code thats causing classes to be loaded too many times. The >> > 'Classes' view in jConsole is showing me a constant rise in class >> > numbers. I would have expected this to be more or less stable, >> > considering that the server is serving about 4 requests per second. The >> > CPU is pretty busy too.Busy garbage collecting the eden space I guess. >> > >> > I was considering increasing the eden space to see if that alleavates >> > the problem, but if its a code problem, it wont help at all. >> > >> > Thanks! >> > Stephen. >> > >> > Alan Bateman wrote: >> > >> >> Stephen Ryan wrote: >> >> >> >>> Hi, >> >>> >> >>> I was wondering if its possible to get the size of the classes loaded >> >>> from jConsole. Im seeing a lot of GC's in the Eden Space in a server >> >>> thats basically doing nothing. Im thinking that the jvm is trying to >> >>> load classes in there that are just too close to the size of that >> space. >> >>> >> >>> Any help appreciated! >> >>> >> >>> Stephen. >> >> >> >> Classes are essentially allocated from the perm generation so I don't >> >> think this is what you are observing. Instead it is likely that you >> >> are observing the effect of the JMX agent in the target VM due to the >> >> polling by jconsole. Each time jconsole updates the display it must >> >> interact with agent in the agent VM so this means some objects are >> >> allocated which can lead to periodic scavenging that you observe. You >> >> can reduce the polling interval via jconsole's -interval=value option >> >> (interval is specified in seconds). The management interface for class >> >> loading doesn't include the size of the classes but if you try jstat >> >> then you can get this information (jstat -class for example). >> >> >> >> -Alan. From Alan.Bateman at Sun.COM Wed Apr 9 07:08:34 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 09 Apr 2008 15:08:34 +0100 Subject: jconsole question -- probably the wrong mailing list but here goes... In-Reply-To: <47FCCB45.3070107@corp.aol.com> References: <47FC8DFA.4080301@corp.aol.com> <47FC9419.90507@sun.com> <47FCC395.40108@corp.aol.com> <47FCC877.7060903@Sun.COM> <47FCCB45.3070107@corp.aol.com> Message-ID: <47FCCDE2.7080401@sun.com> Stephen Ryan wrote: > Hi Luis. > > I just discovered visualvm this morning in my quest. Its has some nice > features and all the same stuff that jconsole delivers as well. > > Heres the top chunk of what jmap -histo delivers. Also the classes > loaded count is still increasing. Im starting to lean towards a bug in > the code of my webserver. > > Size Count Class description > ------------------------------------------------------- > 70483456 210902 char[] > 22539768 939157 java.lang.String > 10608936 442039 java.util.HashMap$Entry > 3876512 18922 java.util.HashMap$Entry[] > 3823192 22119 * ConstMethodKlass > 3046768 4349 byte[] > 2724968 47155 java.lang.Object[] ... It might be better to move this to the Monitoring and Troubleshooting Tools forum [1] as it sounds like this isn't really an OpenJDK issue. A good start may be to run with -verbose:class to trace the classes as they are loaded. As this is a webserver maybe there are JSPs being compiled into classes and loaded. In that case the web container probably has its own class loaders then the classes may be unloaded in time. -Alan. [1] http://forum.java.sun.com/forum.jspa?forumID=538 From maurizio.cimadamore at sun.com Wed Apr 9 07:33:19 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 14:33:19 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409143326.2AB00276FB@hg.openjdk.java.net> Changeset: 447c300a24e7 Author: mcimadamore Date: 2008-04-09 14:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/447c300a24e7 6450290: Capture of nested wildcards causes type error Summary: A missing capture conversion makes javac to think that some expressions are well-formed even when they aren't Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/wildcards/T6450290.java Changeset: e7bf2e39b8fe Author: mcimadamore Date: 2008-04-09 14:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e7bf2e39b8fe 6657499: javac 1.6.0 fails to compile class with inner class Summary: Lookup of member inner classes silently fails leading to an unwanted erasure to take place Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/T6657499.java Changeset: 6522ea413d23 Author: mcimadamore Date: 2008-04-09 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6522ea413d23 6683438: Bad regression test for CR 6611449 Summary: The regression test for CR 6611449 contains some inconstistencies Reviewed-by: jjg ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out Changeset: a1d1f335633f Author: mcimadamore Date: 2008-04-09 15:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a1d1f335633f 6559182: Cast from a raw type with non-generic supertype to a raw type fails unexpectedly Summary: Javac doesn't conform to JLS 4.8 - all the supertypes of a raw type must be erased Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/Casting5.java From kumar.srinivasan at sun.com Thu Apr 10 09:06:19 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Thu, 10 Apr 2008 16:06:19 +0000 Subject: hg: jdk7/tl/jdk: 6684582: Launcher needs improved error reporting Message-ID: <20080410160631.189EB2776C@hg.openjdk.java.net> Changeset: c2019d1360ef Author: ksrini Date: 2008-04-10 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2019d1360ef 6684582: Launcher needs improved error reporting Summary: indicate the missing main class in the error message Reviewed-by: darcy, kbr ! src/share/bin/emessages.h ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/Arrrghs.sh From xueming.shen at sun.com Thu Apr 10 14:52:14 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 10 Apr 2008 21:52:14 +0000 Subject: hg: jdk7/tl/jdk: 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Message-ID: <20080410215236.1998C27805@hg.openjdk.java.net> Changeset: cb934dd5e073 Author: sherman Date: 2008-04-10 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb934dd5e073 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Summary: SJIS0213 support Reviewed-by: naoto ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/Makefile + make/tools/CharsetMapping/sjis0213.map ! make/tools/Makefile + make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/GenerateMapping.java + src/share/classes/sun/nio/cs/CharsetMapping.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/MS932_0213.java + src/share/classes/sun/nio/cs/ext/SJIS_0213.java From mandy.chung at sun.com Thu Apr 10 16:16:30 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 10 Apr 2008 23:16:30 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20080410231656.846562780A@hg.openjdk.java.net> Changeset: fd563c5dd750 Author: mchung Date: 2008-04-10 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd563c5dd750 6610094: Add generic support for platform MXBeans of any type (also fixed 6681031) Summary: Add new methods in ManagementFactory class to obtain platform MXBeans Reviewed-by: alanb, dfuchs, emcmanus ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/management/ClassLoadingMXBean.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/GarbageCollectorMXBean.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryManagerMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/OperatingSystemMXBean.java + src/share/classes/java/lang/management/PlatformComponent.java + src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/LockDataConverter.java ! src/share/classes/sun/management/ManagementFactory.java + src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/MemoryManagerImpl.java ! src/share/classes/sun/management/MemoryNotifInfoCompositeData.java ! src/share/classes/sun/management/MemoryPoolImpl.java ! src/share/classes/sun/management/MemoryUsageCompositeData.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/StackTraceElementCompositeData.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/Util.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/classes/sun/management/VMOptionCompositeData.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java + test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java + test/java/lang/management/OperatingSystemMXBean/PlatformMXBeanTest.java Changeset: bcf689d26c1c Author: mchung Date: 2008-04-10 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcf689d26c1c Merge From mandy.chung at sun.com Fri Apr 11 10:31:43 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Fri, 11 Apr 2008 17:31:43 +0000 Subject: hg: jdk7/tl/jdk: 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Message-ID: <20080411173155.3FCC9278E0@hg.openjdk.java.net> Changeset: 18eed13fe9f6 Author: mchung Date: 2008-04-11 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18eed13fe9f6 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Summary: Modified the jtreg tests to use ManagementFactoryHelper instead Reviewed-by: emcmanus ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java From xueming.shen at sun.com Mon Apr 14 21:50:38 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Tue, 15 Apr 2008 04:50:38 +0000 Subject: hg: jdk7/tl/jdk: 6635133: Exception thrown when using a Unicode escape Message-ID: <20080415045057.E6F5F27D44@hg.openjdk.java.net> Changeset: dd212ba9a0c6 Author: sherman Date: 2008-04-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd212ba9a0c6 6635133: Exception thrown when using a Unicode escape Summary: Update regex engine to handle unicode escape correctly in character class Reviewed-by: okutsu ! src/share/classes/java/util/regex/Pattern.java From tim.bell at sun.com Thu Apr 17 19:34:00 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:00 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20080418023400.9679227F16@hg.openjdk.java.net> Changeset: 05809a7eb190 Author: ohair Date: 2008-03-18 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/05809a7eb190 6674232: OPENJDK=false is same as OPENJDK=true Summary: If OPENJDK has a value, that value must be "true", empty value == undefined with GNU make. Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: cbc8ad9dd0e0 Author: ohair Date: 2008-03-25 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cbc8ad9dd0e0 6623832: Cleanup old j2se makefile targets Summary: Just removing unneeded makefile rules and 'control' logic. Reviewed-by: xdono ! Makefile ! make/jdk-rules.gmk Changeset: 9410f77cc30c Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9410f77cc30c Added tag jdk7-b25 for changeset cbc8ad9dd0e0 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:34:31 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:31 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20080418023433.AE7E427F1B@hg.openjdk.java.net> Changeset: 5e61d5df6258 Author: ohair Date: 2008-03-25 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5e61d5df6258 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted Reviewed-by: xdono ! src/share/classes/com/sun/corba/se/impl/corba/orb_config_design.txt ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 0043eb3d4e62 Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0043eb3d4e62 Added tag jdk7-b25 for changeset 5e61d5df6258 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:35:48 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:35:48 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b25 for changeset 7836be3e92d0 Message-ID: <20080418023551.EA96E27F22@hg.openjdk.java.net> Changeset: 8b0b3490194f Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b0b3490194f Added tag jdk7-b25 for changeset 7836be3e92d0 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:37:28 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:37:28 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b25 for changeset a3b3ba7d6034 Message-ID: <20080418023730.5E1FC27F29@hg.openjdk.java.net> Changeset: da43cb85fac1 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/da43cb85fac1 Added tag jdk7-b25 for changeset a3b3ba7d6034 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:38:01 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:38:01 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b25 for changeset 59fd8224ba2d Message-ID: <20080418023803.E442C27F32@hg.openjdk.java.net> Changeset: debd37e1a422 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/debd37e1a422 Added tag jdk7-b25 for changeset 59fd8224ba2d ! .hgtags From tim.bell at sun.com Thu Apr 17 19:39:08 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:39:08 +0000 Subject: hg: jdk7/tl/jdk: 12 new changesets Message-ID: <20080418024141.1488F27F37@hg.openjdk.java.net> Changeset: f1c168caf94f Author: ohair Date: 2008-03-18 11:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1c168caf94f 6674226: Warning errors in freetypecheck Summary: Just corrected some C code to remove warning errors from gcc. Reviewed-by: tbell ! make/tools/freetypecheck/freetypecheck.c Changeset: e564dc9241e5 Author: ohair Date: 2008-03-18 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e564dc9241e5 6611788: chmod a+x bin/winver.exe in make/tools/winver/Makefile fails on a read only file system Summary: Tell Mercurial this file has execute permission. Reviewed-by: tbell Changeset: ea98209ac149 Author: ohair Date: 2008-03-18 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea98209ac149 6674232: OPENJDK=false is same as OPENJDK=true Summary: OPENJDK should be empty (undefined) or "true". Reviewed-by: tbell ! make/common/Defs.gmk Changeset: e98ce66d7630 Author: ohair Date: 2008-03-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e98ce66d7630 6654458: /java/devtools findbugs doesn't work on windows Summary: Changes to both ant and findbugs version checking. Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 9ae5ccf6891c Author: ohair Date: 2008-03-19 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ae5ccf6891c 6611629: Avoid hardcoded cygwin paths for memory detection Summary: Use free with sygwin, mem or systeminfo otherwise, to get MB_OF_MEMORY on windows. Reviewed-by: tbell ! make/common/shared/Platform.gmk Changeset: 9b0d53aa8549 Author: ohair Date: 2008-03-25 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b0d53aa8549 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted. Reviewed-by: xdono ! make/common/shared/Sanity.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties ! src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.dtd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/sample/vm/clr-jvm/Makefile ! src/share/sample/vm/clr-jvm/README.txt ! src/share/sample/vm/clr-jvm/invoker.cs ! src/share/sample/vm/jvm-clr/README.txt ! src/share/sample/vm/jvm-clr/invoked.cs Changeset: 40b6f7fcac38 Author: ohair Date: 2008-03-26 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40b6f7fcac38 Merge Changeset: 75fca0b0ab83 Author: xdono Date: 2008-03-27 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75fca0b0ab83 Merge Changeset: 6e25a8a3f8c6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e25a8a3f8c6 Added tag jdk7-b25 for changeset 75fca0b0ab83 ! .hgtags Changeset: e6da580585e9 Author: tbell Date: 2008-04-07 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6da580585e9 Merge ! make/common/shared/Defs.gmk Changeset: 4708b9a13f24 Author: tbell Date: 2008-04-11 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4708b9a13f24 Merge Changeset: 74a42d77106b Author: tbell Date: 2008-04-15 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74a42d77106b Merge From tim.bell at sun.com Thu Apr 17 19:44:34 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:44:34 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20080418024440.5980927F3C@hg.openjdk.java.net> Changeset: 18f0b1b5ffd6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/18f0b1b5ffd6 Added tag jdk7-b25 for changeset 58039502942e ! .hgtags Changeset: c46d25a2350a Author: tbell Date: 2008-04-11 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c46d25a2350a Merge Changeset: 627deea1ea4f Author: tbell Date: 2008-04-15 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/627deea1ea4f Merge From keith.mcguigan at sun.com Thu Apr 17 21:22:54 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Fri, 18 Apr 2008 04:22:54 +0000 Subject: hg: jdk7/tl/jdk: 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Message-ID: <20080418042306.9898F27F49@hg.openjdk.java.net> Changeset: 2bfddc119eea Author: kamg Date: 2008-04-17 22:00 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bfddc119eea 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: sspitsyn, sbohne ! make/com/sun/Makefile + make/com/sun/tracing/Makefile + make/com/sun/tracing/dtrace/Makefile ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/sun/Makefile + make/sun/tracing/Makefile + make/sun/tracing/dtrace/Makefile + make/sun/tracing/dtrace/mapfile-vers + src/share/classes/com/sun/tracing/Probe.java + src/share/classes/com/sun/tracing/ProbeName.java + src/share/classes/com/sun/tracing/Provider.java + src/share/classes/com/sun/tracing/ProviderFactory.java + src/share/classes/com/sun/tracing/ProviderName.java + src/share/classes/com/sun/tracing/dtrace/ArgsAttributes.java + src/share/classes/com/sun/tracing/dtrace/Attributes.java + src/share/classes/com/sun/tracing/dtrace/DependencyClass.java + src/share/classes/com/sun/tracing/dtrace/FunctionAttributes.java + src/share/classes/com/sun/tracing/dtrace/FunctionName.java + src/share/classes/com/sun/tracing/dtrace/ModuleAttributes.java + src/share/classes/com/sun/tracing/dtrace/ModuleName.java + src/share/classes/com/sun/tracing/dtrace/NameAttributes.java + src/share/classes/com/sun/tracing/dtrace/ProviderAttributes.java + src/share/classes/com/sun/tracing/dtrace/StabilityLevel.java + src/share/classes/com/sun/tracing/dtrace/package-info.java + src/share/classes/com/sun/tracing/package-info.java + src/share/classes/sun/tracing/MultiplexProviderFactory.java + src/share/classes/sun/tracing/NullProviderFactory.java + src/share/classes/sun/tracing/PrintStreamProviderFactory.java + src/share/classes/sun/tracing/ProbeSkeleton.java + src/share/classes/sun/tracing/ProviderSkeleton.java + src/share/classes/sun/tracing/dtrace/Activation.java + src/share/classes/sun/tracing/dtrace/DTraceProbe.java + src/share/classes/sun/tracing/dtrace/DTraceProvider.java + src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java + src/share/classes/sun/tracing/dtrace/JVM.java + src/share/classes/sun/tracing/package-info.java ! src/share/javavm/export/jvm.h + src/share/native/sun/tracing/dtrace/JVM.c + src/share/native/sun/tracing/dtrace/jvm_symbols.h + src/solaris/native/sun/tracing/dtrace/jvm_symbols_md.c + src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c + test/com/sun/tracing/BasicFunctionality.java From keith.mcguigan at sun.com Mon Apr 21 11:59:20 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Mon, 21 Apr 2008 18:59:20 +0000 Subject: hg: jdk7/tl/jdk: 6691494: doc build broken in tracingdocs Message-ID: <20080421185944.5816F2707E@hg.openjdk.java.net> Changeset: 79b594e72df0 Author: kamg Date: 2008-04-21 11:24 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79b594e72df0 6691494: doc build broken in tracingdocs Summary: Wrong variable names in makefile Reviewed-by: tbell ! make/docs/Makefile From eamonn.mcmanus at sun.com Tue Apr 22 09:59:41 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 22 Apr 2008 16:59:41 +0000 Subject: hg: jdk7/tl/jdk: 6692027: Custom subclasses of QueryEval don't serialize Message-ID: <20080422165957.B51CE27100@hg.openjdk.java.net> Changeset: 92ea0ac77d2f Author: emcmanus Date: 2008-04-22 18:58 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92ea0ac77d2f 6692027: Custom subclasses of QueryEval don't serialize Summary: Remove non-public superclass of QueryEval Reviewed-by: dfuchs ! src/share/classes/javax/management/AndQueryExp.java ! src/share/classes/javax/management/BetweenQueryExp.java ! src/share/classes/javax/management/BinaryRelQueryExp.java ! src/share/classes/javax/management/NotQueryExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/OrQueryExp.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/QueryEval.java + test/javax/management/query/CustomQueryTest.java From Jonathan.Gibbons at Sun.COM Wed Apr 23 08:09:39 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 23 Apr 2008 08:09:39 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) Message-ID: <92216A93-617D-46D8-A7AE-E8B560888E62@sun.com> Hi Serviceability folk, The Subject line is from a thread on the compiler-dev list. You might be interested to check it out here: http://mail.openjdk.java.net/pipermail/compiler-dev/2008-April/thread.html#300 The thread concerns an interest in improving the information about source location generated by the compiler, javac, and more specifically, increasing the resolution of the info from line-based coordinates to source-based coordinates. The submitter is also talking about using side files for the info, which (if I recall correctly) I have heard folk such as Jim discuss before now. What would be the interest from the serviceability group about any such work? Is it "on your radar", "sometime eventually", or "it'll never happen"? :-) -- Jon P.S. Warning: the submitter has provided a patch on the compiler-dev thread but has not yet signed the SCA. From maurizio.cimadamore at sun.com Wed Apr 23 09:11:11 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 23 Apr 2008 16:11:11 +0000 Subject: hg: jdk7/tl/langtools: 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Message-ID: <20080423161112.B119D27376@hg.openjdk.java.net> Changeset: ec29a1a284ca Author: mcimadamore Date: 2008-04-23 17:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ec29a1a284ca 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Summary: A missing type-erasure in Lower.java causes the compiler to crash since JDK6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/foreach/T6682380.java From Jim.Holmlund at Sun.COM Wed Apr 23 19:53:55 2008 From: Jim.Holmlund at Sun.COM (Jim Holmlund) Date: Wed, 23 Apr 2008 19:53:55 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: <92216A93-617D-46D8-A7AE-E8B560888E62@sun.com> References: <92216A93-617D-46D8-A7AE-E8B560888E62@sun.com> Message-ID: <480FF643.2010706@Sun.COM> Just to summarize: - jcov is an internal to Sun tool. - to support jcov, a .class file attribute called the CharacterRangeTable attribute was defined and javac was changed to output it in response to the -Xjcov(I think) command line option: CharacterRangeTable_attribute { u2 attribute_name_index; u4 attribute_length; u2 character_range_table_length; { u2 start_pc; u2 end_pc; u4 character_range_start; u4 character_range_end; u2 flags; } character_range_table[character_range_table_length]; } The 'flags' field item describes the kind of range, eg statement, block, assignment, flow_controller .. - the CharacterRangeTable was never added to the VM Spec. - jcov used the old JVMPI. Robert rewrote it to do byte code instrumentation via java.lang.instrument. It still uses the CharacterRangeTable. As Robert mentioned, we have had requests from debuggers to include this kind of info in the .class file, for example to allow stepping thru terms of an expression, multiple statements on one line, etc. We planned to do something for this in JDK 6, eg, formalize the CharacterRangeTable attribute by adding it to the definition of the class file in the VM spec, and add functionality to JVM TI, JDWP, and JDI to allow debuggers to access this information. When Peter von der Ah? heard about this, he suggested that we not do this and instead proposed a solution that required no changes to be made to the JDK. His idea was that an IDE has the source code for a file in which fine grained stepping is desired, and the IDE can get the bytecodes from the debuggee VM via JDI (Method.bytecodes()). The IDE can then use the compiler APIs introduced in JDK 6 http://www.artima.com/lejava/articles/compiler_api.html to match the source code to the bytecodes to find the bytecodes that correspond to source constructs of interest. This idea was investigated by the NetBeans debugger team and found to be effective, so it was implemented as the 'expression stepping' feature in NetBeans 6.0: http://www.netbeans.org/features/java/debugger.html So, we ended up not needing character offset information in JPDA and so we didn't add the CharacterRangeTable attribute to the VM spec. Adding thisinformation to JPDA would be very low on our list of things to do, unless some needs arise that can't be handled by Peter's technique. I wonder if Alex could also use Peter's idea. Alex did mention that the tools he is interested in normally have the source code available so maybe he could. - jjh Jonathan Gibbons wrote: > Hi Serviceability folk, > > The Subject line is from a thread on the compiler-dev list. You might > be interested to check it out here: > http://mail.openjdk.java.net/pipermail/compiler-dev/2008-April/thread.html#300 > > > The thread concerns an interest in improving the information about > source location generated by the compiler, javac, and more > specifically, increasing the resolution of the info from line-based > coordinates to source-based coordinates. The submitter is also talking > about using side files for the info, which (if I recall correctly) I > have heard folk such as Jim discuss before now. > > What would be the interest from the serviceability group about any > such work? Is it "on your radar", "sometime eventually", or "it'll > never happen"? :-) > > -- Jon > > P.S. Warning: the submitter has provided a patch on the compiler-dev > thread but has not yet signed the SCA. > > From Jonathan.Gibbons at Sun.COM Wed Apr 30 09:04:08 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 30 Apr 2008 09:04:08 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: <9F9E3493-71C3-42C1-A2ED-BF2E5C391903@retroduction.org> References: <92216A93-617D-46D8-A7AE-E8B560888E62@sun.com> <480FF643.2010706@Sun.COM> <9F9E3493-71C3-42C1-A2ED-BF2E5C391903@retroduction.org> Message-ID: <022EB04B-F20F-4600-9827-7C89C7FB8D65@Sun.COM> Alex, I think Jim's comments go the desired granularity of the information that could be available. Although it is not *necessary* recompile on the fly, it may be *preferable*. to By compiling on demand and comparing byte codes, you can achieve as high a resolution as is desired, without having to have any static information at all, whether in class files or in "side files". In principle, you should be able to step through an expression, sub expression by sub expression. By contrast, with statically generated information, you get what you get -- and line-based info is not necessarily very good, and more detailed information is potentially very big. However, back on the side of static information, I guess there is potentially a performance issue. In a debugger, you're mostly dealing with "line at a time" code at human speeds, as the user steps through code, or sets up breakpoints. In profiling tools, you probably want info about the entire contents of the class file, "in batch time". But the problem remains with statically generated files -- how do you determine the resolution of the information that should be generated? -- Jon On Apr 29, 2008, at 11:41 PM, Alex Rau wrote: > Hi Jim, > > thanks for the detailed info. Unfortunately I've not had much time > this week to investigate deeply on your proposal (compiler API / > debugger API). Here are some things I came up so far - please > correct me in case I got something wrong: > > 1) The debugger API is based on a design with two virtual machines > involved ( the debugger vm and the vm which gets debugged). While > this fits perfectly a debugging or profiling scenario where two > virtual machines are always involved this does not properly line up > with my scenario where only one instance of a virtual machine > exists. Our software is based on top of a readily available > (compiled) build. It performs modifications on the byte code of the > build, runs all unit tests and generates xml reports (all done in > the mentioned single vm in one shot). That's all. A second vm is > just not existing and would mean much more overhead to our design > just for getting column information. > > 2) I could not yet find my way through the compiler and debugger API > from a technical point f view to really have the column information > in the end. I've already had a look on the netbeans sources and > (probably) found the right code location but I have to investigate > on that in more detail. However this indicates somehow that it's > getting much more tricky compared to the variant where the compiler > itself outputs the column information into the byte code via > additional attributes. A question here: is is necessary to recompile > on the fly during debugging to get the line/column information ? If > yes then this would make it even more difficult and would mean that > we have to support an additional compilation process while up to now > we strictly rely on already performed compilations. We work on byte > code exclusively and the sources are only required for the report > generation. > > 3) I think that line numbers and column information are actually > "attributes" of the compiler ( result ) in a broader sense. It > always depends on the compiler what values these attributes will > have. Compared to for example a duration of a method invocation > (profiling) or a certain value of a variable (debugging) the latter > are *always* runtime-dependent values. What I'd like to say is: > there are static ( runtime-independent, "compiler only"-dependent ) > attributes (line and column info) and dynamic attributes ( runtime > and execution dependent ) attributes (invocation duration, variable > value). I see a "natural" separation between those where static > attributes should be stored statically (e.g. in the byte code) and > dynamic attributes should be accessible dynamically (like the > debugger API allows). This does imply as well that while we are > interested in static attributes of the compiler it's really not > necessary to reread these attributes with every modification on > bytecode level. Having these information at a single point of time > (after the compilation is finished) is totally sufficient compared > to getting the information during runtime every time. > > > It looks to me that what I want to achieve belongs more to the > compiler than somewhere else. Any comments ? > > > Best regards, > > Alex > > > On 24.04.2008, at 04:53, Jim Holmlund wrote: > >> Just to summarize: >> - jcov is an internal to Sun tool. >> - to support jcov, a .class file attribute called the >> CharacterRangeTable attribute was >> defined and javac was changed to output it in response to the - >> Xjcov(I think) command line option: >> CharacterRangeTable_attribute { >> u2 attribute_name_index; >> u4 attribute_length; >> u2 character_range_table_length; >> { u2 start_pc; >> u2 end_pc; >> u4 character_range_start; >> u4 character_range_end; >> u2 flags; >> } character_range_table[character_range_table_length]; >> } >> The 'flags' field item describes the kind of range, eg statement, >> block, assignment, >> flow_controller .. >> >> - the CharacterRangeTable was never added to the VM Spec. >> >> - jcov used the old JVMPI. Robert rewrote it to do byte code >> instrumentation >> via java.lang.instrument. It still uses the CharacterRangeTable. >> >> As Robert mentioned, we have had requests from debuggers to include >> this kind of info in the .class file, for example to allow stepping >> thru terms of an expression, multiple statements on one line, etc. >> We planned to do something for this in JDK 6, eg, formalize the >> CharacterRangeTable attribute by adding it to the definition of the >> class file in the VM spec, and add functionality to JVM TI, JDWP, >> and JDI to allow debuggers to access this information. >> >> When Peter von der Ah? heard about this, he suggested that we not >> do this and instead proposed a solution that required no changes to >> be made to the JDK. His idea was that an IDE has the source code >> for a file in which fine grained stepping is desired, and the IDE >> can get the bytecodes from the debuggee VM via JDI >> (Method.bytecodes()). The IDE can then use the compiler APIs >> introduced in JDK 6 >> http://www.artima.com/lejava/articles/compiler_api.html >> to match the source code to the bytecodes to find the bytecodes >> that correspond to source constructs of interest. This idea was >> investigated by the NetBeans debugger team and found to be >> effective, so it was implemented as the 'expression stepping' >> feature in NetBeans 6.0: >> http://www.netbeans.org/features/java/debugger.html >> >> So, we ended up not needing character offset information in JPDA >> and so we didn't add the CharacterRangeTable attribute to the VM >> spec. Adding thisinformation to JPDA would be very low on our list >> of things to do, unless >> some needs arise that can't be handled by Peter's technique. >> >> I wonder if Alex could also use Peter's idea. Alex did mention that >> the tools he is interested >> in normally have the source code available so maybe he could. >> >> - jjh >> >> Jonathan Gibbons wrote: >>> Hi Serviceability folk, >>> >>> The Subject line is from a thread on the compiler-dev list. You >>> might be interested to check it out here: >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2008-April/thread.html#300 >>> >>> The thread concerns an interest in improving the information about >>> source location generated by the compiler, javac, and more >>> specifically, increasing the resolution of the info from line- >>> based coordinates to source-based coordinates. The submitter is >>> also talking about using side files for the info, which (if I >>> recall correctly) I have heard folk such as Jim discuss before now. >>> >>> What would be the interest from the serviceability group about any >>> such work? Is it "on your radar", "sometime eventually", or "it'll >>> never happen"? :-) >>> >>> -- Jon >>> >>> P.S. Warning: the submitter has provided a patch on the compiler- >>> dev thread but has not yet signed the SCA. >>> >>> > From alex at retroduction.org Tue Apr 29 23:41:09 2008 From: alex at retroduction.org (Alex Rau) Date: Wed, 30 Apr 2008 08:41:09 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: <480FF643.2010706@Sun.COM> References: <92216A93-617D-46D8-A7AE-E8B560888E62@sun.com> <480FF643.2010706@Sun.COM> Message-ID: <9F9E3493-71C3-42C1-A2ED-BF2E5C391903@retroduction.org> Hi Jim, thanks for the detailed info. Unfortunately I've not had much time this week to investigate deeply on your proposal (compiler API / debugger API). Here are some things I came up so far - please correct me in case I got something wrong: 1) The debugger API is based on a design with two virtual machines involved ( the debugger vm and the vm which gets debugged). While this fits perfectly a debugging or profiling scenario where two virtual machines are always involved this does not properly line up with my scenario where only one instance of a virtual machine exists. Our software is based on top of a readily available (compiled) build. It performs modifications on the byte code of the build, runs all unit tests and generates xml reports (all done in the mentioned single vm in one shot). That's all. A second vm is just not existing and would mean much more overhead to our design just for getting column information. 2) I could not yet find my way through the compiler and debugger API from a technical point f view to really have the column information in the end. I've already had a look on the netbeans sources and (probably) found the right code location but I have to investigate on that in more detail. However this indicates somehow that it's getting much more tricky compared to the variant where the compiler itself outputs the column information into the byte code via additional attributes. A question here: is is necessary to recompile on the fly during debugging to get the line/column information ? If yes then this would make it even more difficult and would mean that we have to support an additional compilation process while up to now we strictly rely on already performed compilations. We work on byte code exclusively and the sources are only required for the report generation. 3) I think that line numbers and column information are actually "attributes" of the compiler ( result ) in a broader sense. It always depends on the compiler what values these attributes will have. Compared to for example a duration of a method invocation (profiling) or a certain value of a variable (debugging) the latter are *always* runtime-dependent values. What I'd like to say is: there are static ( runtime-independent, "compiler only"-dependent ) attributes (line and column info) and dynamic attributes ( runtime and execution dependent ) attributes (invocation duration, variable value). I see a "natural" separation between those where static attributes should be stored statically (e.g. in the byte code) and dynamic attributes should be accessible dynamically (like the debugger API allows). This does imply as well that while we are interested in static attributes of the compiler it's really not necessary to reread these attributes with every modification on bytecode level. Having these information at a single point of time (after the compilation is finished) is totally sufficient compared to getting the information during runtime every time. It looks to me that what I want to achieve belongs more to the compiler than somewhere else. Any comments ? Best regards, Alex On 24.04.2008, at 04:53, Jim Holmlund wrote: > Just to summarize: > - jcov is an internal to Sun tool. > - to support jcov, a .class file attribute called the > CharacterRangeTable attribute was > defined and javac was changed to output it in response to the -Xjcov > (I think) command line option: > CharacterRangeTable_attribute { > u2 attribute_name_index; > u4 attribute_length; > u2 character_range_table_length; > { u2 start_pc; > u2 end_pc; > u4 character_range_start; > u4 character_range_end; > u2 flags; > } character_range_table[character_range_table_length]; > } > The 'flags' field item describes the kind of range, eg statement, > block, assignment, > flow_controller .. > > - the CharacterRangeTable was never added to the VM Spec. > > - jcov used the old JVMPI. Robert rewrote it to do byte code > instrumentation > via java.lang.instrument. It still uses the CharacterRangeTable. > > As Robert mentioned, we have had requests from debuggers to include > this kind of info in the .class file, for example to allow stepping > thru terms of an expression, multiple statements on one line, etc. > We planned to do something for this in JDK 6, eg, formalize the > CharacterRangeTable attribute by adding it to the definition of the > class file in the VM spec, and add functionality to JVM TI, JDWP, > and JDI to allow debuggers to access this information. > > When Peter von der Ah? heard about this, he suggested that we not > do this and instead proposed a solution that required no changes to > be made to the JDK. His idea was that an IDE has the source code > for a file in which fine grained stepping is desired, and the IDE > can get the bytecodes from the debuggee VM via JDI (Method.bytecodes > ()). The IDE can then use the compiler APIs introduced in JDK 6 > http://www.artima.com/lejava/articles/compiler_api.html > to match the source code to the bytecodes to find the bytecodes > that correspond to source constructs of interest. This idea was > investigated by the NetBeans debugger team and found to be > effective, so it was implemented as the 'expression stepping' > feature in NetBeans 6.0: > http://www.netbeans.org/features/java/debugger.html > > So, we ended up not needing character offset information in JPDA > and so we didn't add the CharacterRangeTable attribute to the VM > spec. Adding thisinformation to JPDA would be very low on our list > of things to do, unless > some needs arise that can't be handled by Peter's technique. > > I wonder if Alex could also use Peter's idea. Alex did mention that > the tools he is interested > in normally have the source code available so maybe he could. > > - jjh > > Jonathan Gibbons wrote: >> Hi Serviceability folk, >> >> The Subject line is from a thread on the compiler-dev list. You >> might be interested to check it out here: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2008-April/ >> thread.html#300 >> >> The thread concerns an interest in improving the information about >> source location generated by the compiler, javac, and more >> specifically, increasing the resolution of the info from line- >> based coordinates to source-based coordinates. The submitter is >> also talking about using side files for the info, which (if I >> recall correctly) I have heard folk such as Jim discuss before now. >> >> What would be the interest from the serviceability group about any >> such work? Is it "on your radar", "sometime eventually", or "it'll >> never happen"? :-) >> >> -- Jon >> >> P.S. Warning: the submitter has provided a patch on the compiler- >> dev thread but has not yet signed the SCA. >> >>