[kaffe] DataInputStream related merge

[Dalibor Topic]

Hi Jukka,

--- Jukka Santala <jsantala at morphine.tml.hut.fi>
wrote:
> On Wed, 23 Oct 2002, Dalibor Topic wrote:
> > > Actually, the switch to method b fixed one bug
> by
> > > introducing another ;)
> > Yeah, sorry about that. Could you try the attached
> > patch and see if it works in your context? It is
> an
> > attempt to get the best of both worlds, and runs
> your
> > test case as expected.
> 
> Thanks for the fast response, yeah the patch does
> work... However, it's
> starting to get worrisomely complex. In particular,
> if for some reason
> there's a break in the stream right between the cr
> and lf, which could
> easily happen with IP-frames etc., it'll lead to
> hard to track down
> problems. It may be best to apply that for now, but
> on the logn run I'd
> still like to see skipNextLF moved to lower level,
> possibly native code.

The proposed solution is not optimal, but I'll apply
it for now, as it solves your problem, and is less
invasive than the other patch. I don't know a lot
about kaffe's networking libraries, so I can't tell
how easily the midstream corruption could happen. Note
that in most cases nothing bad will happen, unless
someone tries to read from the underlying stream while
DataInputStream is not done with it. In my eyes
"stealing" streams is bad programming practice, but I
haven't looked at the XML processing code that
triggered the error, so I can't tell how reasonable my
opinion on "stealing" streams is.

> This remaidns me of a related optimization issue, is
> there any kind of
> plicy/guideline on native code vs. Java in the
> default lib? It seems
> implemnting at least some of the more trivial IO
> classes in native code
> could yield significant speed-ups for them.

There is no policy as far as I know. I tend to prefer
to do things in Java, as that is easier to maintain
for me, and avoids all the auto* trickery as much as
possible (broken strtod, memove etc. functions on
different platforms). 

For example, replacing the native System.arraycopy by
a pure java version yielded a significant performance
improvement for the SciMark2 benchmark on i386-linux
with jit3. I didn't expect that.

Other people (IBM) have implemented the BigNum classes
in java.math in pure java and were faster than the
native versions. Just because it's in Java doesn't
have to mean it's slow ;)

Do you have some specific classes/methods in mind that
you'd like to see go native?

best regards,

dalibor topic

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/