Daniel John Debrunner <[EMAIL PROTECTED]> writes:
> Knut Anders Hatlen wrote:
>> Daniel John Debrunner <[EMAIL PROTECTED]> writes:
>>
>>> Knut Anders Hatlen wrote:
>>>> They use a pattern of first copying the instance
>>>> variables into local variables, then do the work on the local
>>>> variables, and finally write back to the instance variables. While I
>>>> find that a little confusing because I would expect the run-time
>>>> compiler to be able to perform that kind of optimization itself,
>>>> that's a different issue from what is discussed in this thread.
>>> Can the run-time optimizer/compiler perform such an optimization when
>>> the instance variable is not final? I would have thought not.
>>
>> Yes, I believe it can. Java's memory model basically allows the
>> compiler to assume that the variables are accessed by a single thread
>> as long as it doesn't hit a memory barrier (like a volatile variable
>> or a synchronized block).
>
> How effective can this be when the accesses to the instance field are
> intermixed with method calls of other objects, especially when those
> methods are interface calls?
I don't know the details about how the optimizations are performed in
those cases, but it shouldn't be a problem for the methods in
ArrayInputStream though, since they barely have method calls. A
typical method looks like this:
public final char readChar() throws IOException {
int pos = position;
byte[] data = pageData;
if (pos >= (end -1))
throw new EOFException(); // end of file
int c = ((data[pos++] & 0xff) << 8) | (data[pos++] & 0xff);
position = pos;
return (char) c;
}
And I would assume that this equivalent method would run just as fast:
public final char readChar() throws IOException {
if (position >= end - 1)
throw new EOFException();
return (char) (((pageData[position++] & 0xff) << 8) |
(pageData[position++] & 0xff));
}
Although I doubt that it would run any faster. But perhaps the jar
file would be a couple of bytes smaller! :)
--
Knut Anders
