Knut Anders Hatlen wrote:
Daniel John Debrunner <[EMAIL PROTECTED]> writes:
Knut Anders Hatlen wrote:
I can't answer your question, but I will add that I find much of the
code that uses ArrayInputStream very confusing. ArrayInputStream is
supposed to wrap a byte array to provide encapsulation and easy access
to the data through the InputStream interface. However, many (most?)
of the callers inline the accesses to the data (presumably for
performance reasons), so we end up with lots of methods looking like
this:
public X readSomething(ArrayInputStream ais, byte[] data, int offset...) {
// lots of direct manipulation of the byte array
// ...
// ...
// ...
// finally, make sure that the state of the stream is brought to a
// consistent state:
ais.setPosition(offset + numberOfManipulatedBytes);
}
I could only find one method that looked something like the above:
StoredFieldHeader.readFieldLengthAndSetStreamPosition
Could you provide a list of the others so I can see what the issue is?
You are quite right; most of the methods that inline the accesses
don't call setPosition(). I think I must have confused the callers of
ArrayInputStream methods with the internal implementation of
ArrayInputStream. 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.
I put in a lot of the store inline optimization, regretting the
"ugliness" of it at the time - but it was all driven by profiler results
at the time. When looking at it you
should realize it was tuned to the state of jvm's, probably 5 years ago.
Some may not be needed any more, but at the time these kinds of changes
helped the cached scan performance of the store by close to 10 times on
some hardware/jvm's.
The mentioned method (readFieldLengthAndSetStreamPosition) seems to be
the one that causes most calls to ArrayInputStream. All of the calls
are to setPosition(). If the boundary checking in setPosition() has an
unreasonably high resource consumption, it is always an option to
check the usages of readFieldLengthAndSetStreamPosition, and if it can
be proven safe to skip the boundary checking, that method could use an
unchecked variant of setPosition().
It would be fine to use an unchecked and/or an ASSERT based check for
readFieldLengthAndSetStreamPosition. The "store" module owns this
access and is not counting on limit checks to catch anything here.
