mlockall (Jack enforced client bloat)

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

mlockall (Jack enforced client bloat)

Dave Robillard
Hi all,

I've been looking into a memory consumption problem with an app of mine
that was consuming 35 megs of memory for no reason on startup.  A little
valgrinding later I found out the vast majority of memory used was stack
space (8 megs per thread).

I commented out the mlockall() call I had in my own code, memory
consumption went down from 35 megs to 2.5 megs!  (yes, 2.5, not 25)

Happy with this solution, I went through my code and explicitly mlock'ed
everything that should be, and all was well.  Until I activated the Jack
driver, which calls jack_activate() which calls mlockall() and loads
that 35 megs of useless crap into real memory again.

It is absolutely necessary for that mlockall() call to be called by
jack_activate?  Wouldn't it be much better for Jack to mlock everything
that needs to be explicitly like I did above?

The way it is now mlocks the entire process, locking into memory things
which have absolutely nothing to do with Jack at all (ie the stack of
threads that never go anywhere near the Jack thread).

I don't think this is acceptable behaviour at all... Thoughts?

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (Jack enforced client bloat)

Florian Paul Schmidt-2
On Tue, 25 Oct 2005 17:21:57 +1000
Dave Robillard <[hidden email]> wrote:

> Hi all,
>
> I've been looking into a memory consumption problem with an app of mine
> that was consuming 35 megs of memory for no reason on startup.  A little
> valgrinding later I found out the vast majority of memory used was stack
> space (8 megs per thread).
>
> I commented out the mlockall() call I had in my own code, memory
> consumption went down from 35 megs to 2.5 megs!  (yes, 2.5, not 25)
>
> Happy with this solution, I went through my code and explicitly mlock'ed
> everything that should be, and all was well.  Until I activated the Jack
> driver, which calls jack_activate() which calls mlockall() and loads
> that 35 megs of useless crap into real memory again.
>
> It is absolutely necessary for that mlockall() call to be called by
> jack_activate?  Wouldn't it be much better for Jack to mlock everything
> that needs to be explicitly like I did above?

Well, in jackd you have the choice of either not mlock'ing at all
(--no_mlock) which would make it the clients job to do the mlock'ing
(but some vital parts of jackd aren't mlock'ed then at all). Also
there's the --unlock option which unlocks common libraries.

I suppose another option which would only mlock jackd's vital parts and
none per client would be quite useful, too.

>
> The way it is now mlocks the entire process, locking into memory things
> which have absolutely nothing to do with Jack at all (ie the stack of
> threads that never go anywhere near the Jack thread).
>
> I don't think this is acceptable behaviour at all... Thoughts?

I wonder: how do you explicitly mlock only the stack of the relevant
threads? For data it's no problem, but the stack?

Flo


--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (Jack enforced client bloat)

Paul Davis
> Well, in jackd you have the choice of either not mlock'ing at all
> (--no_mlock) which would make it the clients job to do the mlock'ing
> (but some vital parts of jackd aren't mlock'ed then at all). Also
> there's the --unlock option which unlocks common libraries.

and if you can suggest extended heuristics for the unlock operation, i'd
be happy to add them. right now, it has a whitelist and a blacklist of
directories from which large libraries (> 1MB IIRC) should (not be)
unlocked. this typically hits GTK, Qt, Wine etc.

> I suppose another option which would only mlock jackd's vital parts and
> none per client would be quite useful, too.

maybe, but considering that for many clients, their jack-followed code
size is much larger than jackd's own code path, its not clear *how*
useful.

> I wonder: how do you explicitly mlock only the stack of the relevant
> threads? For data it's no problem, but the stack?

not to mention the actual *code* ...

--p




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (Jack enforced client bloat)

cannam

Presumably mlockall() can only lock those pages that are actually
allocated at the time the function is called?

As opposed to somehow ensuring that any subsequent huge heap allocations
you may make will get locked at the time of allocation, I mean.


Chris


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall (Jack enforced client bloat)

Dave Robillard
In reply to this post by Florian Paul Schmidt-2
On Tue, 2005-25-10 at 12:29 +0200, Florian Schmidt wrote:

> On Tue, 25 Oct 2005 17:21:57 +1000
> Dave Robillard <[hidden email]> wrote:
>
> > Hi all,
> >
> > I've been looking into a memory consumption problem with an app of mine
> > that was consuming 35 megs of memory for no reason on startup.  A little
> > valgrinding later I found out the vast majority of memory used was stack
> > space (8 megs per thread).
> >
> > I commented out the mlockall() call I had in my own code, memory
> > consumption went down from 35 megs to 2.5 megs!  (yes, 2.5, not 25)
> >
> > Happy with this solution, I went through my code and explicitly mlock'ed
> > everything that should be, and all was well.  Until I activated the Jack
> > driver, which calls jack_activate() which calls mlockall() and loads
> > that 35 megs of useless crap into real memory again.
[snip]
> I wonder: how do you explicitly mlock only the stack of the relevant
> threads? For data it's no problem, but the stack?
>

Hmm... good point, I guess I havn't.  There is a
pthread_attr_getstackaddr function, but I'm not sure how to use it or if
it even works in Linux.  I'll have a look into it.

I managed to eliminate a thread entirely, and shrink the thread's stack
sizes from 8 megs down to 0.5 (pthread_attr_setstacksize) which helped
quite a bit, but it still seems like a less than ideal situation to have
jack mlocking the entire process.  For one thing you just don't have
control over the stack size of some threads (alsa and liblo in my case),
so they still happily chew 8 megs a piece.

I guess Jack MIDI and OSC would make those threads go away entirely,
which would be even nicer :)


-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Dave Robillard
In reply to this post by Dave Robillard
Looks like making mlockall() in Jack go away isn't about to happen, but
is it necessary to call it for Jack clients that don't even have a
process callback?

LASH and patch bays, for example, chew vast amounts of memory because of
mlockall(), but they don't actually do any audio processing at all.  It
would be nice if we could at least prevent locking those into memory, if
it's possible

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Fons Adriaensen
On Mon, Oct 31, 2005 at 03:08:21PM +1100, Dave Robillard wrote:

> LASH and patch bays, for example, chew vast amounts of memory because of
> mlockall(), but they don't actually do any audio processing at all.  It
> would be nice if we could at least prevent locking those into memory, if
> it's possible

In the long term the connection control & query interfaces should be
completely separated from the RT audio parts IMHO. The ideal interface
would be OSC and an MVC model.

--
FA




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Jack O'Quin-2
In reply to this post by Dave Robillard
Dave Robillard <[hidden email]> writes:

> Looks like making mlockall() in Jack go away isn't about to happen, but
> is it necessary to call it for Jack clients that don't even have a
> process callback?

Have you tried `jackd -m'?  That would probably meet your needs.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Dave Robillard
On Mon, 2005-31-10 at 09:47 -0600, Jack O'Quin wrote:
> Dave Robillard <[hidden email]> writes:
>
> > Looks like making mlockall() in Jack go away isn't about to happen, but
> > is it necessary to call it for Jack clients that don't even have a
> > process callback?
>
> Have you tried `jackd -m'?  That would probably meet your needs.

I do want memory locked, but just the memory that /should/ be locked.
Not the entire process of an app that doesn't even handle audio.


-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Jack O'Quin-2
Dave Robillard <[hidden email]> writes:

> On Mon, 2005-31-10 at 09:47 -0600, Jack O'Quin wrote:
>> Dave Robillard <[hidden email]> writes:
>>
>> > Looks like making mlockall() in Jack go away isn't about to happen, but
>> > is it necessary to call it for Jack clients that don't even have a
>> > process callback?
>>
>> Have you tried `jackd -m'?  That would probably meet your needs.
>
> I do want memory locked, but just the memory that /should/ be locked.
> Not the entire process of an app that doesn't even handle audio.

Try it.  You may find that locking memory is not really necessary (it
frequently isn't).  And that will definitely solve your problem.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Dave Robillard
On Mon, 2005-31-10 at 12:59 -0600, Jack O'Quin wrote:

> Dave Robillard <[hidden email]> writes:
>
> > On Mon, 2005-31-10 at 09:47 -0600, Jack O'Quin wrote:
> >> Dave Robillard <[hidden email]> writes:
> >>
> >> > Looks like making mlockall() in Jack go away isn't about to happen, but
> >> > is it necessary to call it for Jack clients that don't even have a
> >> > process callback?
> >>
> >> Have you tried `jackd -m'?  That would probably meet your needs.
> >
> > I do want memory locked, but just the memory that /should/ be locked.
> > Not the entire process of an app that doesn't even handle audio.
>
> Try it.  You may find that locking memory is not really necessary (it
> frequently isn't).  And that will definitely solve your problem.

It's not necessary when.. you have enough RAM to fit absolutely
everything into memory anyway.  It is necessary when you don't, and
something needs to be swapped out - ie the exact scenario where Jack's
current behaviour is a problem.

If it's something that just can't be easily fixed, fine, I'm just saying
there /is/ a problem with Jack's behaviour here, and neither mlockall()
or not locking memory at all are decent solutions.

Maybe adding a new command line switch to explicitly mlock just the
necessary bits, with the implication that it's the apps' responsibility
to lock any memory that should be?

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Paul Davis
> Maybe adding a new command line switch to explicitly mlock just the
> necessary bits, with the implication that it's the apps' responsibility
> to lock any memory that should be?

you keep saying this as though its easy for the app to do.

we are not just talking about data, we are talking about code as well.

how do you suggest an app could ensure that its entire call path
from within the process() tree is mlocked?

--p




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Lee Revell
In reply to this post by Jack O'Quin-2
On Mon, 2005-10-31 at 12:59 -0600, Jack O'Quin wrote:

> Dave Robillard <[hidden email]> writes:
>
> > On Mon, 2005-31-10 at 09:47 -0600, Jack O'Quin wrote:
> >> Dave Robillard <[hidden email]> writes:
> >>
> >> > Looks like making mlockall() in Jack go away isn't about to happen, but
> >> > is it necessary to call it for Jack clients that don't even have a
> >> > process callback?
> >>
> >> Have you tried `jackd -m'?  That would probably meet your needs.
> >
> > I do want memory locked, but just the memory that /should/ be locked.
> > Not the entire process of an app that doesn't even handle audio.
>
> Try it.  You may find that locking memory is not really necessary (it
> frequently isn't).  And that will definitely solve your problem.

What problem?  Memory is cheap...

Lee



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Jack O'Quin-2
In reply to this post by Dave Robillard
Dave Robillard <[hidden email]> writes:

> On Mon, 2005-31-10 at 12:59 -0600, Jack O'Quin wrote:
>> Try it.  You may find that locking memory is not really necessary (it
>> frequently isn't).  And that will definitely solve your problem.
>
> It's not necessary when.. you have enough RAM to fit absolutely
> everything into memory anyway.  It is necessary when you don't, and
> something needs to be swapped out - ie the exact scenario where Jack's
> current behaviour is a problem.

The mlock() touches far more than the actual working set of the
process, greatly increasing its memory footprint.  Using the -m option
will save large amounts of storage.  

If there still is not enough memory for your system to run without
thrashing, then you do indeed have a problem.  In that case, the only
solution is to run fewer clients or reduce the total number of ports.

I doubt any other solution would make you happy, anyway.  A thrashing
PC is no fun.  Buy more memory.  It costs about $100 per gigabyte
these days.

> If it's something that just can't be easily fixed, fine, I'm just saying
> there /is/ a problem with Jack's behaviour here, and neither mlockall()
> or not locking memory at all are decent solutions.

You are making a purely theoretical point with no empirical data to
support it.  The true situation is much more complex.  Virtual memory
managers are highly unlikely to replace pages being referenced in a
regular process loop.

JACK works fine on Mac OSX despite the complete lack of mlockall()
support on that platform.  I have tested the -m option on Linux
machines having limited memory, also with good results.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Dave Cunningham
In reply to this post by Lee Revell
On Tue, Nov 01, 2005 at 02:55:22AM -0500, Lee Revell wrote:

>On Mon, 2005-10-31 at 12:59 -0600, Jack O'Quin wrote:
>> Dave Robillard <[hidden email]> writes:
>>
>> > On Mon, 2005-31-10 at 09:47 -0600, Jack O'Quin wrote:
>> >> Dave Robillard <[hidden email]> writes:
>> >>
>> >> > Looks like making mlockall() in Jack go away isn't about to happen, but
>> >> > is it necessary to call it for Jack clients that don't even have a
>> >> > process callback?
>> >>
>> >> Have you tried `jackd -m'?  That would probably meet your needs.
>> >
>> > I do want memory locked, but just the memory that /should/ be locked.
>> > Not the entire process of an app that doesn't even handle audio.
>>
>> Try it.  You may find that locking memory is not really necessary (it
>> frequently isn't).  And that will definitely solve your problem.
>
>What problem?  Memory is cheap...
>
>Lee

I always used to think that swap was a dirty dirty hack.  As soon
as i could afford it, i bought a load of RAM and stopped
using swap alltogether.  I can't even remember what it's like to
have swap now, but eliminating it entirely has not caused my any
problems.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Jack O'Quin-2

> On Tue, Nov 01, 2005 at 02:55:22AM -0500, Lee Revell wrote:
>>What problem?  Memory is cheap...

Dave Cunningham <[hidden email]> writes:
> I always used to think that swap was a dirty dirty hack.  As soon
> as i could afford it, i bought a load of RAM and stopped
> using swap alltogether.  I can't even remember what it's like to
> have swap now, but eliminating it entirely has not caused my any
> problems.

It made a lot more sense thirty years ago, when system design and
performance tradeoffs were quite different.  Back then, the paging
drums used as swapping devices were smaller than the main memory of a
modern PC.

Especially for audio workstations, running without swap makes good
sense nowdays.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Paul Davis
> It made a lot more sense thirty years ago, when system design and
> performance tradeoffs were quite different.  Back then, the paging
> drums used as swapping devices were smaller than the main memory of a
> modern PC.

not to seymour cray, who uttered the immortal line "Virtual memory is
for farmers" sometime in the late 1970's i believe.

--p




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Jack O'Quin-2
Paul Davis <[hidden email]> writes:

>> It made a lot more sense thirty years ago, when system design and
>> performance tradeoffs were quite different.  Back then, the paging
>> drums used as swapping devices were smaller than the main memory of a
>> modern PC.
>
> not to seymour cray, who uttered the immortal line "Virtual memory is
> for farmers" sometime in the late 1970's i believe.

I don't recall that one, but I do remember "Real programs need real
memory."  Seymour was quite a character.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Clemens Kirchgatterer
In reply to this post by Paul Davis
Paul Davis <[hidden email]> wrote:

> > It made a lot more sense thirty years ago, when system design and
> > performance tradeoffs were quite different.  Back then, the paging
> > drums used as swapping devices were smaller than the main memory of
> > a modern PC.
>
> not to seymour cray, who uttered the immortal line "Virtual memory is
> for farmers" sometime in the late 1970's i believe.

hmm, there was a long an very interesting thread on lkml some time ago
that explained, that activating swap will improve overall system
performance regardless of the amount of ram someone has. the point is,
that the VM swaps out only VERY infrequently or never used pages a gains
more system memory for the filesystem cache.

just a thought ...
clemens


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: mlockall redux

Lee Revell
On Tue, 2005-11-01 at 18:59 +0100, Clemens Kirchgatterer wrote:

> Paul Davis <[hidden email]> wrote:
>
> > > It made a lot more sense thirty years ago, when system design and
> > > performance tradeoffs were quite different.  Back then, the paging
> > > drums used as swapping devices were smaller than the main memory of
> > > a modern PC.
> >
> > not to seymour cray, who uttered the immortal line "Virtual memory is
> > for farmers" sometime in the late 1970's i believe.
>
> hmm, there was a long an very interesting thread on lkml some time ago
> that explained, that activating swap will improve overall system
> performance regardless of the amount of ram someone has. the point is,
> that the VM swaps out only VERY infrequently or never used pages a gains
> more system memory for the filesystem cache.

Yes, 2.6 really wants to have swap because it will aggressively swap out
the huge gobs of memory that bloated apps like Firefox and Evolution and
Gnome/KDE allocate then never touch.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12