hg: jdk8/tl/langtools: 8003562: Provide a CLI tool to analyze class dependencies
Changeset: 0c244701188e Author:mchung Date: 2012-12-28 22:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0c244701188e 8003562: Provide a CLI tool to analyze class dependencies Reviewed-by: jjg, alanb, ulfzibis, erikj ! make/build.properties ! makefiles/BuildLangtools.gmk ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Dependency.java + src/share/classes/com/sun/tools/jdeps/Archive.java + src/share/classes/com/sun/tools/jdeps/ClassFileReader.java + src/share/classes/com/sun/tools/jdeps/JdepsTask.java + src/share/classes/com/sun/tools/jdeps/Main.java + src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + src/share/classes/com/sun/tools/jdeps/resources/jdk.properties + src/share/classes/com/sun/tools/jdeps/resources/version.properties-template ! test/Makefile + test/tools/jdeps/Basic.java + test/tools/jdeps/Test.java + test/tools/jdeps/p/Foo.java
hg: jdk8/tl: 8003562: Provide a CLI tool to analyze class dependencies
Changeset: c37401e77c80 Author:mchung Date: 2012-12-28 22:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c37401e77c80 8003562: Provide a CLI tool to analyze class dependencies Reviewed-by: jjg, alanb, ulfzibis, erikj ! common/bin/compare_exceptions.sh.incl
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 0cfcba56cfa7 Author:jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author:smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5e29b62288 Merge
Re: RFR (XS): 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs
Thanks for the review! And, yes, I asked myself that same question about what should actually be listed in vmstructs when I found this. The only criterion I know is that if the SA uses it needs to be there. However, I think there's a fairly large bunch of data and types that are in the vmstructs arrays which are not used by the SA at all. We know we don't like the SA + vmStructs "mess" and want something else to replace it. Meanwhile I guess fixing what's there will have to do. Cheers, Mikael On 12/28/2012 3:40 PM, David Holmes wrote: Mikael, This looks good to me. It does make me wonder (not for the first time) exactly what criteria determines which fields from which classes appear in VMStructs? David On 29/12/2012 8:24 AM, Mikael Vidstedt wrote: Please review the following change. Background: The _unloading field is a static field in ClassLoaderDataGraph (in classLoaderData.hpp) and should therefore be defined using static_field, as opposed to nonstatic_field, in vmStructs. Apart from changing from nonstatic_field to static_field I also added an assert in the CHECK_NONSTATIC_VM_STRUCT_ENTRY macro to make sure any field offsets are within the bounds of the corresponding structs. The assert triggers for _unloading before the change to static_field. The change passes JPRT. http://cr.openjdk.java.net/~mikael/8005592/webrev.00/ Thanks, Mikael
Re: RFR (S): 8004747: Remove last_entry from VM_STRUCT macros
Thanks David! Still need a 2nd reviewer! Cheers, Mikael On 12/28/2012 3:34 PM, David Holmes wrote: Mikael, That all sounds fine to me. Thanks, David On 29/12/2012 3:48 AM, Mikael Vidstedt wrote: David, I did two things (both on linux/x86_64 only): 1. I compared the pre-processor output manually. Unfortunately there are line numbers sprinkled around in the pre-processed file which makes comparing the output a bit more complex than it should be. Modulo the line numbers and some white space changes the outputs matche. 2. I wrote a small test which mimics what the SA does - it looks up the four exported structures dynamically and reads the data. Apart from the "address" field in the VMStructEntry entries the outputs almost [1] match. The address field is expected to vary since it reflects the actual placement in memory of various static variables. Are there other experiments you can think of? Cheers, Mikael [1] Using this tool I actually found one bug in the table - one entry (ClassLoaderDataGraph::_unloading) is declared as nonstatic when it is indeed static. I'll file a separate bug for that. On 12/11/2012 8:16 PM, David Holmes wrote: Hi Mikael, This looks okay to me - I like the simplification. However as I don't perform mental macro substitution particularly well (okay, not at all ;-)) I was wondering if there was a simple validation test where we could compare the pre-processed output before and after? Thanks, David On 11/12/2012 7:01 AM, Mikael Vidstedt wrote: Please review the following change: Webrev: http://cr.openjdk.java.net/~mikael/8004747/webrev.00/ Background: This patch does 3 things (depending on how you count it): 1. Move the call to generating the last entry for the VM structures database The vmStructs functionality is a macro based way of creating a database of information about VM internal structures, types and constants. The database for structures is defined in runtime/vmStructs.cpp in an array called localHotSpotVMStructs. The content of the array is generated with calls to a few different macros (VM_STRUCTS, VM_STRUCTS_PARALLELGC, VM_STRUCTS_CMS, VM_STRUCTS_G1, VM_STRUCTS_CPU and VM_STRUCTS_OS_CPU respectively). Common for all these macros is the fact that the last argument passed in is another macro (GENERATE_VM_STRUCT_LAST_ENTRY) which is a generator for the end marker/last entry in the database; a special entry which can be easily located by an external consumer of the information. Even though the end marker generator macro (GENERATE_VM_STRUCT_LAST_ENTRY) is passed to all the VM_STRUCT* macros, the actual end marker must be generated once and only once. The way this is currently handled is that only the last VM_STRUCT macro, which happens to be VM_STRUCTS_OS_CPU, actually makes use of its last argument and adds it to the end of the array. Not only is this fairly complex to understand, it's also more fragile than it needs to be. This change removes the last argument for all the VM_STRUCT macros and instead explicitly inserts the end marker at the end of the localHotSpotVMStructs array. The same VM_STRUCTS macros are being used in VMStructs::init to do type checking. Instead of passing the end marker generator into the macros the last parameter is instead CHECK_SENTINEL, which is defined to expand to nothing, which means it can be safely removed. 2. Move the end marker generating for the VM types, VM int constants and VM long constants databases Repeat the exact above story, but replace anything called Structs/STRUCT with Types/TYPES, IntConstants/INT_CONSTANTS and LongConstants/LONG_CONSTANTS respectively. 3. Minor prettification In addition to the above the change also removes some superfluous backslashes from a few of the VM_STRUCT* macro calls. Thanks, Mikael
Re: RFR (XS): 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs
Mikael, This looks good to me. It does make me wonder (not for the first time) exactly what criteria determines which fields from which classes appear in VMStructs? David On 29/12/2012 8:24 AM, Mikael Vidstedt wrote: Please review the following change. Background: The _unloading field is a static field in ClassLoaderDataGraph (in classLoaderData.hpp) and should therefore be defined using static_field, as opposed to nonstatic_field, in vmStructs. Apart from changing from nonstatic_field to static_field I also added an assert in the CHECK_NONSTATIC_VM_STRUCT_ENTRY macro to make sure any field offsets are within the bounds of the corresponding structs. The assert triggers for _unloading before the change to static_field. The change passes JPRT. http://cr.openjdk.java.net/~mikael/8005592/webrev.00/ Thanks, Mikael
Re: RFR (S): 8004747: Remove last_entry from VM_STRUCT macros
Mikael, That all sounds fine to me. Thanks, David On 29/12/2012 3:48 AM, Mikael Vidstedt wrote: David, I did two things (both on linux/x86_64 only): 1. I compared the pre-processor output manually. Unfortunately there are line numbers sprinkled around in the pre-processed file which makes comparing the output a bit more complex than it should be. Modulo the line numbers and some white space changes the outputs matche. 2. I wrote a small test which mimics what the SA does - it looks up the four exported structures dynamically and reads the data. Apart from the "address" field in the VMStructEntry entries the outputs almost [1] match. The address field is expected to vary since it reflects the actual placement in memory of various static variables. Are there other experiments you can think of? Cheers, Mikael [1] Using this tool I actually found one bug in the table - one entry (ClassLoaderDataGraph::_unloading) is declared as nonstatic when it is indeed static. I'll file a separate bug for that. On 12/11/2012 8:16 PM, David Holmes wrote: Hi Mikael, This looks okay to me - I like the simplification. However as I don't perform mental macro substitution particularly well (okay, not at all ;-)) I was wondering if there was a simple validation test where we could compare the pre-processed output before and after? Thanks, David On 11/12/2012 7:01 AM, Mikael Vidstedt wrote: Please review the following change: Webrev: http://cr.openjdk.java.net/~mikael/8004747/webrev.00/ Background: This patch does 3 things (depending on how you count it): 1. Move the call to generating the last entry for the VM structures database The vmStructs functionality is a macro based way of creating a database of information about VM internal structures, types and constants. The database for structures is defined in runtime/vmStructs.cpp in an array called localHotSpotVMStructs. The content of the array is generated with calls to a few different macros (VM_STRUCTS, VM_STRUCTS_PARALLELGC, VM_STRUCTS_CMS, VM_STRUCTS_G1, VM_STRUCTS_CPU and VM_STRUCTS_OS_CPU respectively). Common for all these macros is the fact that the last argument passed in is another macro (GENERATE_VM_STRUCT_LAST_ENTRY) which is a generator for the end marker/last entry in the database; a special entry which can be easily located by an external consumer of the information. Even though the end marker generator macro (GENERATE_VM_STRUCT_LAST_ENTRY) is passed to all the VM_STRUCT* macros, the actual end marker must be generated once and only once. The way this is currently handled is that only the last VM_STRUCT macro, which happens to be VM_STRUCTS_OS_CPU, actually makes use of its last argument and adds it to the end of the array. Not only is this fairly complex to understand, it's also more fragile than it needs to be. This change removes the last argument for all the VM_STRUCT macros and instead explicitly inserts the end marker at the end of the localHotSpotVMStructs array. The same VM_STRUCTS macros are being used in VMStructs::init to do type checking. Instead of passing the end marker generator into the macros the last parameter is instead CHECK_SENTINEL, which is defined to expand to nothing, which means it can be safely removed. 2. Move the end marker generating for the VM types, VM int constants and VM long constants databases Repeat the exact above story, but replace anything called Structs/STRUCT with Types/TYPES, IntConstants/INT_CONSTANTS and LongConstants/LONG_CONSTANTS respectively. 3. Minor prettification In addition to the above the change also removes some superfluous backslashes from a few of the VM_STRUCT* macro calls. Thanks, Mikael
RFR (XS): 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs
Please review the following change. Background: The _unloading field is a static field in ClassLoaderDataGraph (in classLoaderData.hpp) and should therefore be defined using static_field, as opposed to nonstatic_field, in vmStructs. Apart from changing from nonstatic_field to static_field I also added an assert in the CHECK_NONSTATIC_VM_STRUCT_ENTRY macro to make sure any field offsets are within the bounds of the corresponding structs. The assert triggers for _unloading before the change to static_field. The change passes JPRT. http://cr.openjdk.java.net/~mikael/8005592/webrev.00/ Thanks, Mikael
Re: RFR (S): 8004747: Remove last_entry from VM_STRUCT macros
David, I did two things (both on linux/x86_64 only): 1. I compared the pre-processor output manually. Unfortunately there are line numbers sprinkled around in the pre-processed file which makes comparing the output a bit more complex than it should be. Modulo the line numbers and some white space changes the outputs matche. 2. I wrote a small test which mimics what the SA does - it looks up the four exported structures dynamically and reads the data. Apart from the "address" field in the VMStructEntry entries the outputs almost [1] match. The address field is expected to vary since it reflects the actual placement in memory of various static variables. Are there other experiments you can think of? Cheers, Mikael [1] Using this tool I actually found one bug in the table - one entry (ClassLoaderDataGraph::_unloading) is declared as nonstatic when it is indeed static. I'll file a separate bug for that. On 12/11/2012 8:16 PM, David Holmes wrote: Hi Mikael, This looks okay to me - I like the simplification. However as I don't perform mental macro substitution particularly well (okay, not at all ;-)) I was wondering if there was a simple validation test where we could compare the pre-processed output before and after? Thanks, David On 11/12/2012 7:01 AM, Mikael Vidstedt wrote: Please review the following change: Webrev: http://cr.openjdk.java.net/~mikael/8004747/webrev.00/ Background: This patch does 3 things (depending on how you count it): 1. Move the call to generating the last entry for the VM structures database The vmStructs functionality is a macro based way of creating a database of information about VM internal structures, types and constants. The database for structures is defined in runtime/vmStructs.cpp in an array called localHotSpotVMStructs. The content of the array is generated with calls to a few different macros (VM_STRUCTS, VM_STRUCTS_PARALLELGC, VM_STRUCTS_CMS, VM_STRUCTS_G1, VM_STRUCTS_CPU and VM_STRUCTS_OS_CPU respectively). Common for all these macros is the fact that the last argument passed in is another macro (GENERATE_VM_STRUCT_LAST_ENTRY) which is a generator for the end marker/last entry in the database; a special entry which can be easily located by an external consumer of the information. Even though the end marker generator macro (GENERATE_VM_STRUCT_LAST_ENTRY) is passed to all the VM_STRUCT* macros, the actual end marker must be generated once and only once. The way this is currently handled is that only the last VM_STRUCT macro, which happens to be VM_STRUCTS_OS_CPU, actually makes use of its last argument and adds it to the end of the array. Not only is this fairly complex to understand, it's also more fragile than it needs to be. This change removes the last argument for all the VM_STRUCT macros and instead explicitly inserts the end marker at the end of the localHotSpotVMStructs array. The same VM_STRUCTS macros are being used in VMStructs::init to do type checking. Instead of passing the end marker generator into the macros the last parameter is instead CHECK_SENTINEL, which is defined to expand to nothing, which means it can be safely removed. 2. Move the end marker generating for the VM types, VM int constants and VM long constants databases Repeat the exact above story, but replace anything called Structs/STRUCT with Types/TYPES, IntConstants/INT_CONSTANTS and LongConstants/LONG_CONSTANTS respectively. 3. Minor prettification In addition to the above the change also removes some superfluous backslashes from a few of the VM_STRUCT* macro calls. Thanks, Mikael
Re: RFR JDK-8005120
Greetings: I modified windows source code files so they pass size_t for buffer sizes and socklen_t for address structures. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/ Please let me know what you think. Thanks! On 12/26/2012 02:56 PM, John Zavgren wrote: Greetings: I modified the windows code so that it uses socklen_t to specify the lengths of data structures, parameter lengths, etc. instead of ints (which can be negative.) http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/ Thanks! John Zavgren On 12/20/2012 05:47 PM, John Zavgren wrote: Greetings: I modified my changes so that windows knows the definition of the POSIX data type: socklen_t, and now all the system calls are using the "doctrinaire" data types. Please consider the following update. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ Thanks! John Zavgren On 20/12/2012 13:49, John Zavgren wrote: Greetings: I agree that the "correct" way to fix this problem is to use POSIX data types, e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on windows machines: - build monologue - c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2146: syntax error : missing ')' before identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2081: 'socklen_t' : name in formal parameter list illegal c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2061: syntax error : identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ';' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ')' - build monologue - I used alternative types, e.g., uint32_t, etc. as a way to avoid the limitations of windows. What is the recommended way to accommodate this windows limitation? Shall I use a typedef statement to define "socklen_t"? We don't suffer from this issue in the networking native code. The unix and windows implementations are distinct. I see the vm defines socklen_t in a windows specific header, hotspot/src/os/windows/vm/jvm_windows.h, as typedef int socklen_t; ...and it is then used in shared code, like jvm.cpp, and the hpi, by optionally including #ifdef TARGET_OS_FAMILY_windows # include "jvm_windows.h" #endif We could use a similar, but more simplistic, approach here. -Chris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-dev@openjdk.java.net, john.zavg...@oracle.com, net-...@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Yes, and the networking native code too. I think it is best to use socklen_t for the unix code. From what I can see making these changes, to use socklen_t, should be relatively localized. -Chris. Depending on the OS (and version?) we should be using socklen_t not int and not uint32_t. David On 20/12/2012 2:35 AM, Chris Hegarty wrote: John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected 'uint32_t *' but argument is of type 'int *' ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_accept': ../../../../src/share/transport/socket/socketTransport.c:371:33: warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected 'uint32_t *' but argument is of type 'int *' Do you see these in your build? -Chris. On 12/19/2012 03:42 PM, Alan Bateman wrote: John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15:36, John Zavgren wrote: Greetings: Please consider the following change to the two files: src/share/transport/socket/sysSocket.h src/solaris/transport/socket/socket_md.c that eliminate compiler warnings that stem from the fact that the variables that the native code passes to various system calls were not declared correctly. They were declared as integers, but they must be "unsigned" integers because they are used to define buffer lengths. Were one to supply a negative value as an argument, it woul
hg: jdk8/tl/jdk: 7120365: DiffHBTest.java fails due to ConcurrentModificationException
Changeset: 46675076f753 Author:sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java
hg: jdk8/tl/jdk: 8003265: Need to clone array of input/output parameters
Changeset: 4472a641b4dc Author:xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java
hg: jdk8/tl/jdk: 7109274: Restrict the use of certificates with RSA keys less than 1024 bits
Changeset: 645d774b683a Author:xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh
