Re: Indenting code?
On 14/09/2012 01:21, Brad Wetmore wrote: Netbean's automatic formatting does a pretty good job with new code. However, I think the general advice is to not change existing code just because. When you're dealing with multiple release families, it makes the merges much more difficult. Brad One think that Paul Sandoz suggested recently is that we should have a NB template that folks can use to avoid some discussions/debates on styles. It would be great for someone to run with that, the hard part is of course that it will be impossible to get agreement. Personally I find NB's defaults okay but there are several cases where its indenting is horrible. Anyway, the main advice I think is to keep things locally consistent where possible. Also major refactoring or formatting in a bug fix is a royal pain for reviewers. -Alan
Re: Indenting code?
One useful feature in Netbeans is that you can select a block of code and just (re)format that. So, there's no need to worry about affecting the rest of the file you are editing. - Michael On 14/09/12 01:59, Weijun Wang wrote: On 09/14/2012 08:21 AM, Brad Wetmore wrote: Netbean's automatic formatting does a pretty good job with new code. That's Alt-Shift-F, which I rarely dare to press, because it change existing codes. In fact, NetBeans is doing very smart indentation while you are coding, at least it adheres to the Sun/Oracle convention. The only thing I need to care about is breaking long lines. I also turn on Options|Editor|General|Remove Trailing Whitespace From Modified Lines Only. However, I think the general advice is to not change existing code just because. When you're dealing with multiple release families, it makes the merges much more difficult. Yes, yes, yes, and it makes code reviewers wondering what really changed. -Max Brad On 9/13/2012 6:18 AM, John Zavgren wrote: Greetings: I have a simple question about how to enforce code styles for: java, c, and c++. I know there are style guides that legislate the indentation, "curly brace and parenthesis management", etc. I'm looking for a simple automatic way to transform any source code file so that it's image is guaranteed to be "correct". No thinking required. What I normally do is use an open source tool named "indent", e.g., indent -bap -bbb -bl -nce -l80 file1.cpp file2.h file3.c file4.java And, I put an "indent" target in my make files. Consequently whenever I make something, the very first step is to format the code, and I know that when I do a check in later on... I never have to think about whether or not the code conforms to a style guide... because the options I gave to "indent" implemented this guide. (You can do similar things with emacs too.) Any ideas? Thanks! John Zavgren john.zavg...@oracle.com
hg: jdk8/tl/jdk: 3 new changesets
Changeset: eae1384cff39 Author:mullan Date: 2012-09-14 10:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eae1384cff39 7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status) Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java Changeset: 34bcbb110bb0 Author:mullan Date: 2012-09-14 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34bcbb110bb0 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c11cec5a9306 Author:mullan Date: 2012-09-14 10:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c11cec5a9306 Merge - test/sun/misc/URLClassPath/ClassnameCharTest.sh
Re: Indenting code?
On 14/09/12 12:20, Alan Bateman wrote: On 14/09/2012 01:21, Brad Wetmore wrote: Netbean's automatic formatting does a pretty good job with new code. However, I think the general advice is to not change existing code just because. When you're dealing with multiple release families, it makes the merges much more difficult. Brad One think that Paul Sandoz suggested recently is that we should have a NB template that folks can use to avoid some discussions/debates on styles. It would be great for someone to run with that, the hard part is of course that it will be impossible to get agreement. Personally I find NB's defaults okay but there are several cases where its indenting is horrible. I did play with NB somewhat trying to get it follow, exactly, the preferred style in some areas of the JDK code. I was able to get it close, or at least better than the default, but I don't believe it is possible to get it to do exactly what we want. -Chris. Anyway, the main advice I think is to keep things locally consistent where possible. Also major refactoring or formatting in a bug fix is a royal pain for reviewers. -Alan
hg: jdk8/tl/jdk: 7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo
Changeset: 22d7a9f73a59 Author:mchung Date: 2012-09-14 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22d7a9f73a59 7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo Reviewed-by: alanb, sla, egahlin ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ThreadInfo.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java + src/share/classes/sun/management/LockInfoCompositeData.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java
Re: Indenting code?
On Sep 14 2012, at 09:27 , Chris Hegarty wrote: > On 14/09/12 12:20, Alan Bateman wrote: >> On 14/09/2012 01:21, Brad Wetmore wrote: >>> Netbean's automatic formatting does a pretty good job with new code. >>> However, I think the general advice is to not change existing code >>> just because. When you're dealing with multiple release families, it >>> makes the merges much more difficult. >>> >>> Brad >> One think that Paul Sandoz suggested recently is that we should have a >> NB template that folks can use to avoid some discussions/debates on >> styles. It would be great for someone to run with that, the hard part is >> of course that it will be impossible to get agreement. Personally I find >> NB's defaults okay but there are several cases where its indenting is >> horrible. > > I did play with NB somewhat trying to get it follow, exactly, the preferred > style in some areas of the JDK code. I was able to get it close, or at least > better than the default, but I don't believe it is possible to get it to do > exactly what we want. Please report issues with the NB formatter not following "Code Conventions for the Java Programming Language" on this issue: http://netbeans.org/bugzilla/show_bug.cgi?id=124169
Re: Indenting code?
While it is true that NB and Eclipse and other IDEs offer auto formatting and that will suit some us, I also no that there are some amongst us who still use emacs and vi and possibly other non-IDE editors. The first thing to agree on is what standard are we coding to. I had assumed it was the old Sun Java coding standards ( http://www.oracle.com/technetwork/java/codeconv-138413.html) Is that the case? If not, I suggest that we /don't /open this up to a full-fledged discussion of what the standard should be. I've been involved in far too many such religious debates over the years that end up reminding me of the famous Belushi-esque food fight scene from Animal House. Instead, if any question on any one individual point comes up, we look at the predominate approach in the existing code and use that. As Alan points out, local consistency is important to maintain. In the unlikely event that an entire piece of code is rewritten, then it's ok to bring it up to the current standard, otherwise don't mess with it. In other words, there are more important things to consider than whether any one piece of code meets the standard. Although that would be ideal, we do have to consider the consequences of major formatting changes, since those will impact the ease of interpreting diffs, and far more significant, ability to manage merging. If we agree that the old Sun Java coding standards are what we /are mostly/ using, then we can identify formatting templates for the major IDEs, and other tools as needed. Jim Also, this is broader than net-dev, so I'm moving the discussion to disc...@openjdk.java.net. Please respond there. On 09/14/2012 12:27 PM, Chris Hegarty wrote: On 14/09/12 12:20, Alan Bateman wrote: On 14/09/2012 01:21, Brad Wetmore wrote: Netbean's automatic formatting does a pretty good job with new code. However, I think the general advice is to not change existing code just because. When you're dealing with multiple release families, it makes the merges much more difficult. Brad One think that Paul Sandoz suggested recently is that we should have a NB template that folks can use to avoid some discussions/debates on styles. It would be great for someone to run with that, the hard part is of course that it will be impossible to get agreement. Personally I find NB's defaults okay but there are several cases where its indenting is horrible. I did play with NB somewhat trying to get it follow, exactly, the preferred style in some areas of the JDK code. I was able to get it close, or at least better than the default, but I don't believe it is possible to get it to do exactly what we want. -Chris. Anyway, the main advice I think is to keep things locally consistent where possible. Also major refactoring or formatting in a bug fix is a royal pain for reviewers. -Alan -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
hg: jdk8/tl/langtools: 7192073: (javac) minor refactoring of tree maker to help IDEs
Changeset: fabfd2710057 Author:ksrini Date: 2012-09-14 09:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fabfd2710057 7192073: (javac) minor refactoring of tree maker to help IDEs Reviewed-by: jjg Contributed-by: jan.lah...@oracle.com ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
Proposed changes for Bug 7193520
Greetings: This bug (7193520) was filed because there are obsolete checks in the openJDK native code that implements datagram sockets, e.g., src/solaris/native/java/net/PlainDatagramSocketImpl.c and it's Java counterpart: src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java The native code (PlainDatagramSocketImpl.c and "friends") runs real time checks for the Linux kernel version number. If the most significant two fields of the version number is "2.2" on the host platform, then these checks cause the socket to be created, used, and managed differently than if the Linux kernel version were newer. (These behavior changes were necessary because Linux kernel 2.2.X IP networking was was implemented differently and lacked features of the newer kernels.) However, the run time logic isn't actually needed anymore because openJDK doesn't support Linux kernel 2.2.X, and consequently one cannot run openJDK on these older OSes. The run time checks are never used. The proposed changes to the code (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate distracting dead wood, and it makes it run (slightly) faster, because the run time checks are eliminated. Thanks! and RSVP John Zavgren john.zavg...@oracle.com
Re: Indenting code?
Jim, IMHO, It's really boring task to format big peace of code manually. The worst scenario I could imagine - autoformat code by netbeans and then manually adjust it to some coding standard. Is it possible to: 1. Rich some common point between netbeans and old sun coding standard. 2. Provide a config for one of available opensource beautifiers (jalopy, uncrustify etc.) for people who don't use netbeans. 3. Write results as coding standard. -Dmitry On 2012-09-14 21:23, Jim Gish wrote: > While it is true that NB and Eclipse and other IDEs offer auto > formatting and that will suit some us, I also no that there are some > amongst us who still use emacs and vi and possibly other non-IDE > editors. The first thing to agree on is what standard are we coding > to. I had assumed it was the old Sun Java coding standards ( > http://www.oracle.com/technetwork/java/codeconv-138413.html) > > Is that the case? > > If not, I suggest that we /don't /open this up to a full-fledged > discussion of what the standard should be. I've been involved in far > too many such religious debates over the years that end up reminding me > of the famous Belushi-esque food fight scene from Animal House. > Instead, if any question on any one individual point comes up, we look > at the predominate approach in the existing code and use that. > > As Alan points out, local consistency is important to maintain. In the > unlikely event that an entire piece of code is rewritten, then it's ok > to bring it up to the current standard, otherwise don't mess with it. > In other words, there are more important things to consider than whether > any one piece of code meets the standard. Although that would be ideal, > we do have to consider the consequences of major formatting changes, > since those will impact the ease of interpreting diffs, and far more > significant, ability to manage merging. > > If we agree that the old Sun Java coding standards are what we /are > mostly/ using, then we can identify formatting templates for the major > IDEs, and other tools as needed. > > Jim > > Also, this is broader than net-dev, so I'm moving the discussion to > disc...@openjdk.java.net. Please respond there. > On 09/14/2012 12:27 PM, Chris Hegarty wrote: >> On 14/09/12 12:20, Alan Bateman wrote: >>> On 14/09/2012 01:21, Brad Wetmore wrote: Netbean's automatic formatting does a pretty good job with new code. However, I think the general advice is to not change existing code just because. When you're dealing with multiple release families, it makes the merges much more difficult. Brad >>> One think that Paul Sandoz suggested recently is that we should have a >>> NB template that folks can use to avoid some discussions/debates on >>> styles. It would be great for someone to run with that, the hard part is >>> of course that it will be impossible to get agreement. Personally I find >>> NB's defaults okay but there are several cases where its indenting is >>> horrible. >> >> I did play with NB somewhat trying to get it follow, exactly, the >> preferred style in some areas of the JDK code. I was able to get it >> close, or at least better than the default, but I don't believe it is >> possible to get it to do exactly what we want. >> >> -Chris. >> >>> Anyway, the main advice I think is to keep things locally consistent >>> where possible. Also major refactoring or formatting in a bug fix is a >>> royal pain for reviewers. >>> >>> -Alan > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.g...@oracle.com > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
Re: Proposed changes for Bug 7193520
John, Changes look good for me. Few nits below. PlainDatagramSocketImpl.c 318 brackets is not necessary anymore 1644 whole #ifdef could be removed struct ip_mreqn mreqn; is not necessary anymore, 2283 the same 2294 #ifdef is not necessary anymore -Dmitry On 2012-09-14 22:22, John Zavgren wrote: > Greetings: > > > This bug (7193520) was filed because there are obsolete checks in the openJDK > native code that implements datagram sockets, e.g., > src/solaris/native/java/net/PlainDatagramSocketImpl.c > and it's Java counterpart: > src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java > > The native code (PlainDatagramSocketImpl.c and "friends") runs real time > checks for the Linux kernel version number. If the most significant two > fields of the version number is "2.2" on the host platform, then these checks > cause the socket to be created, used, and managed differently than if the > Linux kernel version were newer. (These behavior changes were necessary > because Linux kernel 2.2.X > IP networking was was implemented differently and lacked features of the > newer kernels.) > > However, the run time logic isn't actually needed anymore because openJDK > doesn't support Linux kernel 2.2.X, and consequently one cannot run openJDK > on these older OSes. The run time checks are never used. > > The proposed changes to the code > (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate distracting > dead wood, and it makes it run (slightly) faster, because the run time checks > are eliminated. > > > Thanks! > and > RSVP > John Zavgren > john.zavg...@oracle.com > > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
Re: Proposed changes for Bug 7193520
Thanks. - Original Message - From: dmitry.samers...@oracle.com To: john.zavg...@oracle.com Cc: net-dev@openjdk.java.net Sent: Friday, September 14, 2012 3:08:57 PM GMT -05:00 US/Canada Eastern Subject: Re: Proposed changes for Bug 7193520 John, Changes look good for me. Few nits below. PlainDatagramSocketImpl.c 318 brackets is not necessary anymore 1644 whole #ifdef could be removed struct ip_mreqn mreqn; is not necessary anymore, 2283 the same 2294 #ifdef is not necessary anymore -Dmitry On 2012-09-14 22:22, John Zavgren wrote: > Greetings: > > > This bug (7193520) was filed because there are obsolete checks in the openJDK > native code that implements datagram sockets, e.g., > src/solaris/native/java/net/PlainDatagramSocketImpl.c > and it's Java counterpart: > src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java > > The native code (PlainDatagramSocketImpl.c and "friends") runs real time > checks for the Linux kernel version number. If the most significant two > fields of the version number is "2.2" on the host platform, then these checks > cause the socket to be created, used, and managed differently than if the > Linux kernel version were newer. (These behavior changes were necessary > because Linux kernel 2.2.X > IP networking was was implemented differently and lacked features of the > newer kernels.) > > However, the run time logic isn't actually needed anymore because openJDK > doesn't support Linux kernel 2.2.X, and consequently one cannot run openJDK > on these older OSes. The run time checks are never used. > > The proposed changes to the code > (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate distracting > dead wood, and it makes it run (slightly) faster, because the run time checks > are eliminated. > > > Thanks! > and > RSVP > John Zavgren > john.zavg...@oracle.com > > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
Re: Proposed changes for Bug 7193520
I agree with all the changes you recommend except the last one... see below. - Original Message - From: dmitry.samers...@oracle.com To: john.zavg...@oracle.com Cc: net-dev@openjdk.java.net Sent: Friday, September 14, 2012 3:08:57 PM GMT -05:00 US/Canada Eastern Subject: Re: Proposed changes for Bug 7193520 John, Changes look good for me. Few nits below. PlainDatagramSocketImpl.c 318 brackets is not necessary anymore 1644 whole #ifdef could be removed struct ip_mreqn mreqn; is not necessary anymore, 2283 the same 2294 #ifdef is not necessary anymore --- This is the original code near line number 2294 #ifdef __linux__ mname.imr_address.s_addr = (isOldKernel ? mreqn.imr_address.s_addr : in.s_addr); #else mname.imr_interface.s_addr = in.s_addr; #endif --- When Linux is the OS, the structure field name to be set is "imr_address", whereas when other OSes are used, the field name is: imr_interface. Am I understanding your suggestion correctly? Thanks! John -Dmitry On 2012-09-14 22:22, John Zavgren wrote: > Greetings: > > > This bug (7193520) was filed because there are obsolete checks in the openJDK > native code that implements datagram sockets, e.g., > src/solaris/native/java/net/PlainDatagramSocketImpl.c > and it's Java counterpart: > src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java > > The native code (PlainDatagramSocketImpl.c and "friends") runs real time > checks for the Linux kernel version number. If the most significant two > fields of the version number is "2.2" on the host platform, then these checks > cause the socket to be created, used, and managed differently than if the > Linux kernel version were newer. (These behavior changes were necessary > because Linux kernel 2.2.X > IP networking was was implemented differently and lacked features of the > newer kernels.) > > However, the run time logic isn't actually needed anymore because openJDK > doesn't support Linux kernel 2.2.X, and consequently one cannot run openJDK > on these older OSes. The run time checks are never used. > > The proposed changes to the code > (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate distracting > dead wood, and it makes it run (slightly) faster, because the run time checks > are eliminated. > > > Thanks! > and > RSVP > John Zavgren > john.zavg...@oracle.com > > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
hg: jdk8/tl: 3 new changesets
Changeset: b85b44cced24 Author:jcoomes Date: 2012-09-05 12:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b85b44cced24 7196361: add hotspot/make/closed to hgforest.sh Reviewed-by: ohair ! make/scripts/hgforest.sh Changeset: 76844579fa4b Author:katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/76844579fa4b Added tag jdk8-b55 for changeset b85b44cced24 ! .hgtags Changeset: 56264ff5e1d5 Author:katleman Date: 2012-09-13 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/56264ff5e1d5 Added tag jdk8-b56 for changeset 76844579fa4b ! .hgtags
hg: jdk8/tl/jaxp: 2 new changesets
Changeset: f19d63b2119a Author:katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f19d63b2119a Added tag jdk8-b55 for changeset 7c2363666890 ! .hgtags Changeset: 40bbed6d2173 Author:katleman Date: 2012-09-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/40bbed6d2173 Added tag jdk8-b56 for changeset f19d63b2119a ! .hgtags
hg: jdk8/tl/jaxws: 2 new changesets
Changeset: 7813455ccdb0 Author:katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7813455ccdb0 Added tag jdk8-b55 for changeset 109c9e1f2d85 ! .hgtags Changeset: e099c1eea1ed Author:katleman Date: 2012-09-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e099c1eea1ed Added tag jdk8-b56 for changeset 7813455ccdb0 ! .hgtags
hg: jdk8/tl/langtools: 4 new changesets
Changeset: 363e9198b9de Author:lana Date: 2012-09-10 17:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/363e9198b9de Merge Changeset: 27ba086a9b60 Author:katleman Date: 2012-09-13 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27ba086a9b60 Added tag jdk8-b56 for changeset 363e9198b9de ! .hgtags Changeset: 8c3c714eb7de Author:lana Date: 2012-09-14 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c3c714eb7de Merge Changeset: a433bd8f3ba9 Author:lana Date: 2012-09-14 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a433bd8f3ba9 Merge
hg: jdk8/tl/corba: 2 new changesets
Changeset: bf1bb47414e1 Author:katleman Date: 2012-09-06 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/bf1bb47414e1 Added tag jdk8-b55 for changeset e8a0e84383d6 ! .hgtags Changeset: 1500fe4849e8 Author:katleman Date: 2012-09-13 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1500fe4849e8 Added tag jdk8-b56 for changeset bf1bb47414e1 ! .hgtags
hg: jdk8/tl/hotspot: 23 new changesets
Changeset: 153776c4cb6f Author:amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: be82ef218872 Author:sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script Changeset: b3602ff9c1b8 Author:dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b3602ff9c1b8 Merge Changeset: bb3f6194fedb Author:brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vita...@gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author:johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fa9253dcd4df Author:johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author:brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/220b59f8413f Merge Changeset: a1c7f6472621 Author:kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: a5dd6e3ef9f3 Author:twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 7f813940ac35 Author:twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 83b6305a5638 Author:coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.pune...@oracle.com ! test/compiler/6894807/Test6894807.
Re: Proposed changes for Bug 7193520
On 14/09/2012 19:22, John Zavgren wrote: : The proposed changes to the code (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate distracting dead wood, and it makes it run (slightly) faster, because the run time checks are eliminated. It's good to remove this old and long unused code. There is also some Linux 2.4 specific code in there too and maybe that should be removed too. I agree with Dmitry's comment that the braces aren't needed at L318 + 324 of PlainDatagramSocketImpl.c. -Alan.
hg: jdk8/tl/jdk: 7189926: Reduce test size for default run. Add additional run enabling alternative hashing.
Changeset: 92f3cda88d8e Author:mduigou Date: 2012-09-11 07:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92f3cda88d8e 7189926: Reduce test size for default run. Add additional run enabling alternative hashing. Reviewed-by: alanb ! test/java/util/Map/Collisions.java
Re: Proposed changes for Bug 7193520
John, linux has both ip_mreq and ip_mreqn structs, but after better consideration, I think it's better to *leave this code as is* because ip_mreq is obsoleted and general direction should be to use ip_mreqn for all OS that have it but these changes clearly out of scope of this CR, -Dmitry On 2012-09-15 00:06, John Zavgren wrote: > I agree with all the changes you recommend except the last one... see below. > - Original Message - > From: dmitry.samers...@oracle.com > To: john.zavg...@oracle.com > Cc: net-dev@openjdk.java.net > Sent: Friday, September 14, 2012 3:08:57 PM GMT -05:00 US/Canada Eastern > Subject: Re: Proposed changes for Bug 7193520 > > John, > > Changes look good for me. > Few nits below. > > > PlainDatagramSocketImpl.c > > > 318 brackets is not necessary anymore > > 1644 whole #ifdef could be removed > struct ip_mreqn mreqn; > is not necessary anymore, > > 2283 the same > > 2294 #ifdef is not necessary anymore > --- This is the original code near line number 2294 > #ifdef __linux__ > mname.imr_address.s_addr = > (isOldKernel ? mreqn.imr_address.s_addr : in.s_addr); > > #else > mname.imr_interface.s_addr = in.s_addr; > #endif > --- > When Linux is the OS, the structure field name to be set is "imr_address", > whereas when other OSes are used, the field name is: imr_interface. > Am I understanding your suggestion correctly? > > Thanks! > John > > > -Dmitry > > > > On 2012-09-14 22:22, John Zavgren wrote: >> Greetings: >> >> >> This bug (7193520) was filed because there are obsolete checks in the >> openJDK native code that implements datagram sockets, e.g., >> src/solaris/native/java/net/PlainDatagramSocketImpl.c >> and it's Java counterpart: >> src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java >> >> The native code (PlainDatagramSocketImpl.c and "friends") runs real time >> checks for the Linux kernel version number. If the most significant two >> fields of the version number is "2.2" on the host platform, then these >> checks cause the socket to be created, used, and managed differently than if >> the Linux kernel version were newer. (These behavior changes were necessary >> because Linux kernel 2.2.X >> IP networking was was implemented differently and lacked features of the >> newer kernels.) >> >> However, the run time logic isn't actually needed anymore because openJDK >> doesn't support Linux kernel 2.2.X, and consequently one cannot run openJDK >> on these older OSes. The run time checks are never used. >> >> The proposed changes to the code >> (http://cr.openjdk.java.net/~chegar/7193520/webrev.00/) eliminate >> distracting dead wood, and it makes it run (slightly) faster, because the >> run time checks are eliminated. >> >> >> Thanks! >> and >> RSVP >> John Zavgren >> john.zavg...@oracle.com >> >> >> >> > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
