Performance of locally copied members ?

[Martin Buchholz]

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