From Ulf.Zibis at gmx.de Mon May 3 04:40:44 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 03 May 2010 13:40:44 +0200 Subject: Performance of locally copied members ? Message-ID: <4BDEB63C.7060004@gmx.de> Hi, in class String I often see member variables copied to local variables. In java.nio.Buffer I don't see that (e.g. for "position" in nextPutIndex(int nb)). Now I'm wondering. From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile variables in a cache for each thread, so e.g. even in CPU register for few ones. From this knowing, I don't understand, why doing the local caching manually in String (and many other classes), instead trusting on the JVM. Can anybody help me in understanding this ? -Ulf From martinrb at google.com Mon May 3 10:29:47 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 May 2010 10:29:47 -0700 Subject: Performance of locally copied members ? In-Reply-To: <4BDEB63C.7060004@gmx.de> References: <4BDEB63C.7060004@gmx.de> Message-ID: It's a coding style made popular by Doug Lea. It's an extreme optimization that probably isn't necessary; you can expect the JIT to make the same optimizations. (you can try to check the machine code yourself!) Nevertheless, copying to locals produces the smallest bytecode, and for low-level code it's nice to write code that's a little closer to the machine. Also, optimizations of finals (can cache even across volatile reads) could be better. John Rose is working on that. For some algorithms in j.u.c, copying to a local is necessary for correctness. Martin On Mon, May 3, 2010 at 04:40, Ulf Zibis wrote: > Hi, > > in class String I often see member variables copied to local variables. > In java.nio.Buffer I don't see that (e.g. for "position" in nextPutIndex(int > nb)). > Now I'm wondering. > > From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile > variables in a cache for each thread, so e.g. even in CPU register for few > ones. > From this knowing, I don't understand, why doing the local caching manually > in String (and many other classes), instead trusting on the JVM. > > Can anybody help me in understanding this ? > > -Ulf > > > From Ulf.Zibis at gmx.de Mon May 3 11:24:57 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 03 May 2010 20:24:57 +0200 Subject: Performance of locally copied members ? In-Reply-To: References: <4BDEB63C.7060004@gmx.de> Message-ID: <4BDF14F9.9030904@gmx.de> Am 03.05.2010 19:29, schrieb Martin Buchholz: > It's a coding style made popular by Doug Lea. > It's an extreme optimization that probably isn't necessary; > you can expect the JIT to make the same optimizations. > (you can try to check the machine code yourself!) > Nevertheless, copying to locals produces the smallest > bytecode, and for low-level code it's nice to write code > that's a little closer to the machine. > Much thanks! Can I guess, that you agree, that j.n.X-Buffer classes are enough low-level, to "correct" the code in that manner? > Also, optimizations of finals (can cache even across volatile > reads) could be better. John Rose is working on that. > > For some algorithms in j.u.c, > copying to a local is necessary for correctness. > What is j.u.c ? -Ulf > Martin > > On Mon, May 3, 2010 at 04:40, Ulf Zibis wrote: > >> Hi, >> >> in class String I often see member variables copied to local variables. >> In java.nio.Buffer I don't see that (e.g. for "position" in nextPutIndex(int >> nb)). >> Now I'm wondering. >> >> From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile >> variables in a cache for each thread, so e.g. even in CPU register for few >> ones. >> From this knowing, I don't understand, why doing the local caching manually >> in String (and many other classes), instead trusting on the JVM. >> >> Can anybody help me in understanding this ? >> >> -Ulf >> >> >> >> > > From martinrb at google.com Mon May 3 11:42:55 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 May 2010 11:42:55 -0700 Subject: Performance of locally copied members ? In-Reply-To: <4BDF14F9.9030904@gmx.de> References: <4BDEB63C.7060004@gmx.de> <4BDF14F9.9030904@gmx.de> Message-ID: On Mon, May 3, 2010 at 11:24, Ulf Zibis wrote: > Am 03.05.2010 19:29, schrieb Martin Buchholz: >> >> It's a coding style made popular by Doug Lea. >> It's an extreme optimization that probably isn't necessary; >> you can expect the JIT to make the same optimizations. >> (you can try to check the machine code yourself!) >> Nevertheless, copying to locals produces the smallest >> bytecode, and for low-level code it's nice to write code >> that's a little closer to the machine. >> > > Much thanks! > Can I guess, that you agree, that j.n.X-Buffer classes are enough low-level, > to "correct" the code in that manner? I think that yes, in those classes copying fields to locals would be preferred, but maybe not worth it unless already making changes there (which we are). >> Also, optimizations of finals (can cache even across volatile >> reads) could be better. ?John Rose is working on that. >> >> For some algorithms in j.u.c, >> copying to a local is necessary for correctness. >> > > What is j.u.c ? java.util.concurrent. > -Ulf > > >> Martin >> >> On Mon, May 3, 2010 at 04:40, Ulf Zibis ?wrote: >> >>> >>> Hi, >>> >>> in class String I often see member variables copied to local variables. >>> In java.nio.Buffer I don't see that (e.g. for "position" in >>> nextPutIndex(int >>> nb)). >>> Now I'm wondering. >>> >>> ?From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile >>> variables in a cache for each thread, so e.g. even in CPU register for >>> few >>> ones. >>> ?From this knowing, I don't understand, why doing the local caching >>> manually >>> in String (and many other classes), instead trusting on the JVM. >>> >>> Can anybody help me in understanding this ? >>> >>> -Ulf >>> >>> >>> >>> >> >> > > From martinrb at google.com Mon May 3 13:49:18 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 May 2010 13:49:18 -0700 Subject: Performance of locally copied members ? In-Reply-To: References: <4BDEB63C.7060004@gmx.de> Message-ID: Osvaldo, Thanks for the interesting measurements. I have already assimilated this optimization into my own coding style, but have hesitated to publicize it or to require it of others, partly because one hopes that future JIT improvements will obsolete it. It seems likely that we "system programmers" will need to help the compiler make the best code forever, but the nature of that help changes (slowly). Martin On Mon, May 3, 2010 at 13:13, Osvaldo Doederlein wrote: > 2010/5/3 Martin Buchholz >> >> It's a coding style made popular by Doug Lea. >> It's an extreme optimization that probably isn't necessary; >> you can expect the JIT to make the same optimizations. > > It certainly is necessary - unfortunately. Testing my particle/octree-based > 3D renderer without this manual optimization (dumping FPS performance each > 100 frames, begin at 10th score after startup): > > JDK 6u21-b03, Hotspot Client: > 159.4896331738437fps > 161.29032258064515fps > 158.73015873015873fps > 160.0fps > 159.23566878980893fps > > JDK 6u21-b03, Hotspot Server: > 197.23865877712032fps > 204.91803278688525fps > 196.07843137254903fps > 200.40080160320642fps > 198.01980198019803fps > > Now let's cache 8 instance variables into local variables (most final, a > couple non-final ones too): > > JDK 6u21-b03, Hotspot Client: > 169.4915254237288fps > 172.1170395869191fps > 168.63406408094434fps > 168.0672268907563fps > 170.64846416382252fps > > JDK 6u21-b03, Hotspot Server: > 197.62845849802372fps > 200.40080160320642fps > 196.8503937007874fps > 199.6007984031936fps > 203.2520325203252fps > > So, the manual optimization makes no difference for Hotspot Server; but hell > it does for Client - 6% better performance in this test; and the test is not > only the complex, deeply nested rendering loops that use those cacheable > variables to read the input data and update the output pixel and Z buffers - > there's also other code that burns significant CPU and doesn't use these > variables, remarkably buffer filling and copying steps. This means the > speedup in the optimized code should be much higher than 6%, I only reported > / cared to measure the application's global performance. > > We'll need to deal with HotSpot Client for years to come, not to mention > smaller platforms (JavaME, JavaFX Mobile&TV) which JIT compilers are even > lesser than JavaSE's C1. Tuned bytecode is also faster to interpret, which > benefits warm-up time too. Please keep your dirty purist hands off the API > code that Doug and others micro-optimized; it is necessary. :) > > And my +1 to add the same opts to other perf-critical APIs. Even most > important for java.nio as under C1, it doesn't currently benefit from > intrinsic compilation of critical DirectBuffer methods. > > A+ > Osvaldo > > >> >> (you can try to check the machine code yourself!) >> Nevertheless, copying to locals produces the smallest >> bytecode, and for low-level code it's nice to write code >> that's a little closer to the machine. >> >> Also, optimizations of finals (can cache even across volatile >> reads) could be better. ?John Rose is working on that. >> >> For some algorithms in j.u.c, >> copying to a local is necessary for correctness. >> >> Martin >> >> On Mon, May 3, 2010 at 04:40, Ulf Zibis wrote: >> > Hi, >> > >> > in class String I often see member variables copied to local variables. >> > In java.nio.Buffer I don't see that (e.g. for "position" in >> > nextPutIndex(int >> > nb)). >> > Now I'm wondering. >> > >> > From JMM (Java-Memory-Model) I learned, that jvm can hold non-volatile >> > variables in a cache for each thread, so e.g. even in CPU register for >> > few >> > ones. >> > From this knowing, I don't understand, why doing the local caching >> > manually >> > in String (and many other classes), instead trusting on the JVM. >> > >> > Can anybody help me in understanding this ? >> > >> > -Ulf >> > >> > >> > > > From ahughes at redhat.com Fri May 28 06:12:23 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 28 May 2010 14:12:23 +0100 Subject: Rawtypes warning in sun.nio.ch.CompletedFuture Message-ID: The static method withFailure in sun.nio.ch.CompletedFuture creates a CompletedFuture as a raw type rather than with the V type introduced in the method signature: static CompletedFuture withFailure(Throwable exc) { // exception must be IOException or SecurityException if (!(exc instanceof IOException) && !(exc instanceof SecurityException)) exc = new IOException(exc); return new CompletedFuture(null, exc); } This causes a rawtypes warning and the build to fail (due to the use of -Werror) when JAVAC_MAX_WARNINGS is turned on. Adding the appropriate type to the creation of CompletedFuture (as I assumed was originally intended by its introduction) fixes the issue. I also removed the SuppressWarnings annotations as they don't actually suppress any warnings. The webrev is: http://cr.openjdk.java.net/~andrew/warnings/webrev.02/ created against current tl. Is this ok to push? If so, can I have a bug ID for it? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Alan.Bateman at oracle.com Fri May 28 06:45:25 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 May 2010 14:45:25 +0100 Subject: Rawtypes warning in sun.nio.ch.CompletedFuture In-Reply-To: References: Message-ID: <4BFFC8F5.7010204@oracle.com> Andrew John Hughes wrote: > The static method withFailure in sun.nio.ch.CompletedFuture creates a > CompletedFuture as a raw type rather than with the V type introduced > in the method signature: > > static CompletedFuture withFailure(Throwable exc) { > // exception must be IOException or SecurityException > if (!(exc instanceof IOException) && !(exc instanceof > SecurityException)) > exc = new IOException(exc); > return new CompletedFuture(null, exc); > } > > This causes a rawtypes warning and the build to fail (due to the use > of -Werror) when JAVAC_MAX_WARNINGS is turned on. Adding the > appropriate type to the creation of CompletedFuture (as I assumed was > originally intended by its introduction) fixes the issue. > > I also removed the SuppressWarnings annotations as they don't actually > suppress any warnings. > > The webrev is: > > http://cr.openjdk.java.net/~andrew/warnings/webrev.02/ > > created against current tl. > > Is this ok to push? If so, can I have a bug ID for it? > > Thanks, > Thanks for catching this (and the unnecessary SuppressWarnings too - they may have been left over from a previous version where they were needed). Your change looks good to me and I've created this bug to track it: 6956840: (ch) Rawtype warning when compiling sun.nio.ch.CompletedFuture Regards, Alan. From robert at komogvind.dk Sun May 30 08:00:54 2010 From: robert at komogvind.dk (Robert Larsen) Date: Sun, 30 May 2010 17:00:54 +0200 Subject: Performance of locally copied members ? In-Reply-To: References: <4BDEB63C.7060004@gmx.de> Message-ID: <4C027DA6.5060701@komogvind.dk> On 2010-05-03 19:29, Martin Buchholz wrote: > It's a coding style made popular by Doug Lea. > It's an extreme optimization that probably isn't necessary; > you can expect the JIT to make the same optimizations. > (you can try to check the machine code yourself!) > I have often times wanted to do that. Is there some clever way of getting the actual machine code that the JIT compiler generates ? From forax at univ-mlv.fr Sun May 30 08:10:16 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 30 May 2010 17:10:16 +0200 Subject: Performance of locally copied members ? In-Reply-To: <4C027DA6.5060701@komogvind.dk> References: <4BDEB63C.7060004@gmx.de> <4C027DA6.5060701@komogvind.dk> Message-ID: <4C027FD8.80603@univ-mlv.fr> Le 30/05/2010 17:00, Robert Larsen a ?crit : > On 2010-05-03 19:29, Martin Buchholz wrote: >> It's a coding style made popular by Doug Lea. >> It's an extreme optimization that probably isn't necessary; >> you can expect the JIT to make the same optimizations. >> (you can try to check the machine code yourself!) > I have often times wanted to do that. Is there some clever way of > getting the actual machine code that the JIT compiler generates ? There are two tools: LogCompilation that print JIT decision http://wikis.sun.com/display/HotSpotInternals/LogCompilation+overview PrintAssembly that prints the final assembly http://wikis.sun.com/display/HotSpotInternals/PrintAssembly R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100530/13835e6d/attachment.html