Re: Fragmentation: Is there a solution yet?

I got it.. Thankyou very much..It was really a nice response..


Kunal Shah
Development
SensorLogic | M2M made easy.
972-934-7375 x 2121
972-934-7376 (fax)
[email protected]
www.Sensorlogic.com
----- Original Message ----- 
From: "Jim Rudnicki" <jdrlist-3i//[email protected]>
To: "Kunal Shah" <[email protected]>
Sent: Thursday, June 03, 2004 12:47 PM
Subject: Re: [TINI]Fragmentation: Is there a solution yet?


> What I mean by memory usage is this:
>
> - your app creates a set of objects containing your reports
> they occupy 10 k of memory
>
> - your app writes the data in those objects to the file system
> now the file system occupies an additional 10k of memory and total = 20k
>
> - your app nulls the objects releasing the memory
> total use is back down to 10k
>
> - later app needs the data to send to client, and it reads in the files
> total use is back to 20k
>
> - when app finishes sending data to client, it nulls the objects
> total use is back to 10k
>
> A producer consumer pattern like this is a fair way to do things: a
monitor
> process/thread takes some readings and
> creates reports( maybe HTML pages ) - later the HTTP server comes along
and
> delivers the reports to the client.
> My point about a pattern like this, is that writing the objects to the
file
> system does not save RAM at all.  This pattern is actually worse because
for
> transient periods it uses twice as much memory and is sure to scatter the
> filesystem.  <big>if</big> your application was like this, I would
recommend
> not placing the temporary results into the filesystem -- keep everything
in
> Java objects, i.e. the JVM's memory.
>
> You mention you need persistence.  In that case you have to use the
> filesystem and a reuse approach will solve your problem.
>
> I am not recommending anything low level as necessary -- just design
issues
> that become more important when you start developing for embedded systems
> with very long run times.
>
> Jim
>
>

_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini