Re: JEP 158

Hi Kirk, I'm CC'ing serviceability on this since this is really their JEP and discussions around it should go on the serviceability list, even though it seems you are mainly interested in GC logging at this point. I understand what you want and I see that the logging level won't help us get

Re: JEP 158

Hi, Thanks for the feedback! It is going to be hard to find the right balance between a system that provides great power and one that is simple to use and to implement. In general, I will lean more towards making it simple, but I want to make sure we cover the major use cases as well. It loo

Re: JEP 158

Hi Kirk, 20 jun 2012 kl. 10:33 skrev Kirk Pepperdine >: Hi Jesper, On 2012-06-20, at 9:32 AM, Jesper Wilhelmsson wrote: Hi Kirk, I'm CC'ing serviceability on this since this is really their JEP and discussions around it should go on the serviceability list, even

Re: JEP 158

On 06/20/2012 02:07 PM, Kirk Pepperdine wrote: Hi Staffan, Thanks for the feedback! It is going to be hard to find the right balance between a system that provides great power and one that is simple to use and to implement. In general, I will lean more towards making it simple, but I want to

Re: JEP 158

Hi Staffan, > Thanks for the feedback! > > It is going to be hard to find the right balance between a system that > provides great power and one that is simple to use and to implement. In > general, I will lean more towards making it simple, but I want to make sure > we cover the major use ca

Re: JEP 158

Hi Jesper, On 2012-06-20, at 9:32 AM, Jesper Wilhelmsson wrote: > Hi Kirk, > > I'm CC'ing serviceability on this since this is really their JEP and > discussions around it should go on the serviceability list, even though it > seems you are mainly interested in GC logging at this point. I'm

Re: JEP 158

Hi Staffan, I should have added, the existing frameworks are very developer oriented and that's ok except that more often than not if operational people that are looking at these logs and their perspective and purpose is often quite different. I would just like to bring a more operational POV i

Re: URGENT code review request for Solaris FDS fix (7175255)

Greetings, I've updated the fix to (hopefully) address Kelly's and David H's concerns. Here is the URL for code review round 1: http://cr.openjdk.java.net/~dcubed/fds_revamp/7175255-webrev/1/ Brief summary of changes relative to code review round 0: - removed definition of GENERATED from both

Re: URGENT code review request for Solaris FDS fix (7175255)

You still have repeated patterns like: 131 ( set -e ; \ 132 cd $(XLIBJVM_DIR) ; \ 133 $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ; \ 134 ) When 131 ( cd $(XLIBJVM_DIR) && $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ) does

Re: URGENT code review request for Solaris FDS fix (7175255)

On 6/20/12 10:41 AM, Kelly O'Hair wrote: You still have repeated patterns like: 131 ( set -e ; \ 132 cd $(XLIBJVM_DIR) ; \ 133 $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ; \ 134 ) When 131 ( cd $(XLIBJVM_DIR)&& $(ADD_GNU_DEBUGLI

Re: URGENT code review request for Solaris FDS fix (7175255)

On 6/20/12 10:44 AM, Daniel D. Daugherty wrote: On 6/20/12 10:41 AM, Kelly O'Hair wrote: You still have repeated patterns like: 131 ( set -e ; \ 132 cd $(XLIBJVM_DIR) ; \ 133 $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ; \ 134 ) When

Re: URGENT code review request for Solaris FDS fix (7175255)

Kelly, The JPRT job testing the latest HSX-24 version has finished and I have identical test results to the original version of this fix. The JPRT job testing the latest HSX-23.2 version is still running, but so far there are no issues. Could you let me know if this latest version resolves your

Re: URGENT code review request for Solaris FDS fix (7175255)

Looks fine. -kto On Jun 20, 2012, at 12:04 PM, Daniel D. Daugherty wrote: > Kelly, > > The JPRT job testing the latest HSX-24 version has finished and I > have identical test results to the original version of this fix. > The JPRT job testing the latest HSX-23.2 version is still running, > but

hg: jdk8/tl/langtools: 7174143: encapsulate doc comment table

Changeset: 5c0b3faeb0b0 Author:jjg Date: 2012-06-20 13:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c0b3faeb0b0 7174143: encapsulate doc comment table Reviewed-by: ksrini, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes

Re: URGENT code review request for Solaris FDS fix (7175255)

Thanks! Sorry this took three rounds. Dan On 6/20/12 2:13 PM, Kelly O'Hair wrote: Looks fine. -kto On Jun 20, 2012, at 12:04 PM, Daniel D. Daugherty wrote: Kelly, The JPRT job testing the latest HSX-24 version has finished and I have identical test results to the original version of this

Re: URGENT code review request for Solaris FDS fix (7175255)

Looks good to me Dan! Thanks, David On 21/06/2012 3:02 AM, Daniel D. Daugherty wrote: On 6/20/12 10:44 AM, Daniel D. Daugherty wrote: On 6/20/12 10:41 AM, Kelly O'Hair wrote: You still have repeated patterns like: 131 ( set -e ; \ 132 cd $(XLIBJVM_DIR) ; \ 133 $(ADD_GNU_DEBUGLINK) $(LIBJVM_

Re: URGENT code review request for Solaris FDS fix (7175255)

Thanks! Dan On 6/20/12 3:03 PM, David Holmes wrote: Looks good to me Dan! Thanks, David On 21/06/2012 3:02 AM, Daniel D. Daugherty wrote: On 6/20/12 10:44 AM, Daniel D. Daugherty wrote: On 6/20/12 10:41 AM, Kelly O'Hair wrote: You still have repeated patterns like: 131 ( set -e ; \ 132 c

Re: JEP 158

> >>> >>> I understand what you want and I see that the logging level won't help us >>> get there. I don't agree that the logging we have today can't fit nicely >>> into a hierarchical scheme though, it just needs to be more fine grained to >>> achieve what you want. >> >> I think to do this

hg: jdk8/tl/jdk: 7178483: Change version string for Embedded releases

Changeset: dfe5617c18b4 Author:dholmes Date: 2012-06-20 22:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfe5617c18b4 7178483: Change version string for Embedded releases Reviewed-by: dholmes, lancea Contributed-by: Gary Collins ! make/common/Defs-embedded.gmk