db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: ArrayInputStream and performance
Date Tue, 28 Nov 2006 18:13:03 GMT
Daniel John Debrunner <djd@apache.org> writes:

> Knut Anders Hatlen wrote:
>> Daniel John Debrunner <djd@apache.org> 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

View raw message