On Mon, May 3, 2010 at 11:24, Ulf Zibis <ulf.zi...@gmx.de> 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<ulf.zi...@gmx.de> 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 >>> >>> >>> >>> >> >> > >
