Re: [patch] Stat vs slurp vs linux 2.6.22

[Mark Wielaard <mark@klomp.org>]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Hi Andrew,

On Wed, 2007-07-25 at 11:40 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> >>> It might make sense to rewrite slurp as a normal java class so these
> >>> cross C/Java error handling issues. Is there a reason for slurp to have
> >>> to be written in C/CNI?
> >>>   
> >> -> memory pressure; notice how it does a callback
> >> -> performance
> >>     
> > Interesting. It does feel a little like a premature optimization though,
> > seeing that we are finding bugs in it because of the Java/C/CNI mixture
> > of error and memory handling that are hard to track down.
> >
> We're talking here about Scan, not slurp; the first implementation did 
> use File et.al.  It was changed from java to a builder to reduce memory 
> pressure and produced a dramatic performance boost.
> 
> Scan, by not double allocating memory read also keeps memory pressure down.

Does Scan refer to some old class used before slurp? I couldn't easily
track the history in CVS since the files seem to have moved a lot. Or
are you talking about the scanInt() and scanLong() functions of slurp?

In the later case there is no reason why reading the whole thing into a
buffer and then extracting the data out of it would be more or less
efficient in some other language. If you would really like to keep the
memory pressure down you could even just use a DataInputStream so you
don't need to read in a buffer at all and get reading primitive
datatypes for free.

> Going forward, the less memory dropped on the floor by the core, the 
> easier it will be to push more of this into C++.

I am not sure I follow what you are saying here. I agree that writing
memory efficient code is good, but I don't see where C++ comes in. Since
most of frysk is actually written in java, we want to provide a higher
level interface in java for the core, most of the nasty bugs come from
the C side with memory resource corruption and exception handling errors
and we might want to look at using JNI instead of CNI it makes sense to
rely less on C instead of more to make things easier for us all and
safer for the user.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]