Re: Request for review - removal of unused dlinfo variable in java_md.c

2011-10-11 Thread Steve Poole
On Mon, 2011-10-10 at 08:04 -0700, Kumar Srinivasan wrote: That was quick! Thanks to all for the quick turn around. Approved. Kumar hi all, Please find attached a trivial patch to remove an unused variable in jdk/src/solaris/bin/java_md.c The present of the variable causes the

Re: Request for review - removal of unused dlinfo variable in java_md.c

2011-10-11 Thread Kelly O'Hair
Please keep in mind that this was a very small, obviously safe, one line change. More significant changes could take longer. Just to set expectations. ;^) -kto On Oct 11, 2011, at 8:40 AM, Steve Poole wrote: On Mon, 2011-10-10 at 08:04 -0700, Kumar Srinivasan wrote: That was quick! Thanks

Re: Patch to Throwable and StackTraceElement (reduced CPU usage)

2011-10-11 Thread David Holmes
Hi Patrick, On 11/10/2011 3:39 PM, Patrick Reinhart wrote: In my opinion, this could be even written in this ways: for (StackTraceElement traceElement : trace) s.append(\tat ).println(traceElement); I think you are confusing your streams and your StringBuilders - s is a stream. David

Re: Patch to Throwable and StackTraceElement (reduced CPU usage)

2011-10-11 Thread Patrick Reinhart
Hi David, Well in the case of a normal Stream you are absolutely right, but in the Throwable case it's a PrintStream (or PrintWriter) with both do implement the java.lang.Appendable interface (as introduced in 1.5). This interface defines the append() method suggested in my examples.

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

2011-10-11 Thread Ulf Zibis
Hi Sherman, I didn't read anything from you since longer time. You are in holidays? Am 30.09.2011 22:46, schrieb Xueming Shen: I believe we changed from (b1 xyz) to (b1 x) == -2 back to 2009(?) because the benchmark shows the shift version is slightly faster. Do you have any number shows

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

2011-10-11 Thread Ulf Zibis
Am 11.10.2011 13:36, schrieb Ulf Zibis: I believe we changed from (b1 xyz) to (b1 x) == -2 back to 2009(?) because the benchmark shows the shift version is slightly faster. Do you have any number shows any difference now. My non-scientific benchmark still suggests the shift type is faster

hg: jdk8/tl/jdk: 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719

2011-10-11 Thread chris . hegarty
Changeset: 5bfe2de1157b Author:chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys !

Re: i18n dev testcase failure java/util/Locale/Bug6989440.java

2011-10-11 Thread Chris Hegarty
David, I'm not sure where we can file bugs on jtreg, probably have to wait for Jon to come back on line and drop him a mail. This is even worse that I originally though. Any thread that throws an unchecked exception followed by another thread starting a thread ( or invoking any operation on

Re: i18n dev testcase failure java/util/Locale/Bug6989440.java

2011-10-11 Thread Kumar Srinivasan
You can file it as follows: Product: jct_tools Category: jct_tools Subcategory: regtest and for a good measure add jon to the interest list. Kumar David, I'm not sure where we can file bugs on jtreg, probably have to wait for Jon to come back on line and drop him a mail. This is even

Re: Codereview request for 7096080: UTF8 update and new CESU-8 charset

2011-10-11 Thread Xueming Shen
On 10/11/2011 04:36 AM, Ulf Zibis wrote: Am 30.09.2011 22:46, schrieb Xueming Shen: I believe we changed from (b1 xyz) to (b1 x) == -2 back to 2009(?) because the benchmark shows the shift version is slightly faster. Do you have any number shows any difference now. My non-scientific

detect server VM in reg test?

2011-10-11 Thread Weijun Wang
Hi All I have a test consuming quite a lot of memory and seems to be only working on server vms. I've added String vm = System.getProperty(java.vm.name); if (!vm.equals(Java HotSpot(TM) Server VM)) { System.out.println(The test only runs on server VMs);

Re: Patch to Throwable and StackTraceElement (reduced CPU usage)

2011-10-11 Thread David Holmes
On 11/10/2011 9:34 PM, Patrick Reinhart wrote: Hi David, Well in the case of a normal Stream you are absolutely right, but in the Throwable case it's a PrintStream (or PrintWriter) with both do implement the java.lang.Appendable interface (as introduced in 1.5). This interface defines the

Re: detect server VM in reg test?

2011-10-11 Thread David Holmes
Hi Max, On 12/10/2011 5:15 AM, Weijun Wang wrote: I have a test consuming quite a lot of memory and seems to be only working on server vms. I've added String vm = System.getProperty(java.vm.name); if (!vm.equals(Java HotSpot(TM) Server VM)) { System.out.println(The test only runs on server

Re: detect server VM in reg test?

2011-10-11 Thread Weijun Wang
On 10/11/2011 2:51 PM, David Holmes wrote: Hi Max, On 12/10/2011 5:15 AM, Weijun Wang wrote: I have a test consuming quite a lot of memory and seems to be only working on server vms. I've added String vm = System.getProperty(java.vm.name); if (!vm.equals(Java HotSpot(TM) Server VM)) {

Re: Patch to Throwable and StackTraceElement (reduced CPU usage)

2011-10-11 Thread Mike Skells
Hi David, Patrick, re explicit StringBuilders I did try that but the overheads of calling the PrintStreamOrWriter are minimally about the same ( for a StringWriter that I use for the test) but this will clearly depend on the writer that you are using. In my config the end result was slower than

Re: detect server VM in reg test?

2011-10-11 Thread David Holmes
On 12/10/2011 8:21 AM, Weijun Wang wrote: On 10/11/2011 2:51 PM, David Holmes wrote: Searching for contains(Server) would be less error-prone as the above will not work on 64-bit. But there is a better property to use: sun.management.compiler which will report eg Hotspot Client Compiler.

Re: detect server VM in reg test?

2011-10-11 Thread Alan Bateman
Weijun Wang wrote: : The test BigCRL fails on all c1 (without*) and succeeds on all c2 (with*). It does look like it's easy to get more memory from c2. Have you considered passing the max heap size to the @run tag so that you aren't dependent on the default heap size? -Alan.

Re: Patch to Throwable and StackTraceElement (reduced CPU usage)

2011-10-11 Thread David Holmes
Hi Mike, On 12/10/2011 10:05 AM, Mike Skells wrote: snip The majority of the CPu reduction comes from removing the creation of implicit StringBuilders and their resizing Patrick - this is why you idea doesn't really provide the answer, there is still a StringBuilder created for each line of