[M3devel] FW: out of memory philosophy

[Jay]

(truncated..)

From: jay.krell at cornell.eduTo: dabenavidesd at yahoo.es; m3devel at elegosoft.comSubject: RE: out of memory philosophyDate: Thu, 5 Feb 2009 18:29:59 +0000

Here are some ideas that contribute to handling out of memory being useful/good:  "stress"Stress a system.Things start going slow and failing, ok. You can't succeed againstall odds, you can only try.Remove the stress.System should go back to normal, as if the stress was never applied.System should not require reboot, should not have leaked, etc. (I see a lot of "leaks in error paths" in traditional codethat tries lamely to be right: p = malloc();  q = malloc();  if (q == NULL)   return error; /* p leaked */ )  "running at the edge of resource exhaustion"A system is "dedicated" to a certain task.It should make the most use of the resources it has.That is, it should use all the memory and/or cpu available.Diskspace is a different matter -- so much of it generally, hard to exhaust,and hard to consume more than one resource.Using it all means it will occasionally go too far,which should gracefully fail and use a little less.If you don't aim to use it all, you won't, and you will under-utilize.  You could perhaps modify this and say "aim for 90% utilization". Certain "applications" might not strive to be this way,but if "the system" is not, then no application can be.The whole can only be as good as all the parts, etc.One bad apple spoils the bunch, etc.(Possible cultural-ism there.)  Another approach though is to kill processes that are low on resources.Assuming that important state is managed well, like in a transactional database.And that most state is expendable.As well, resource hungry processes might be "run away" and/or "malicious".  Trick of course is to discern the "important non-malicious" from the "run away"/"malicious", as well as insulating "important" server processes (daemons)from run away/malicious clients. Guard against "denial of service attacks".Some people like to put hard limits on things.  "I will reject any strings longer than 2gig".However that has the affect of imposing arbitrary capacity limits where  larger capacity might just work and there might be legitimate clients for it.Lately I'm using Windows findstr against text files with very long lines.  It fails, it says "line too long". Darn.  - Jay

Date: Thu, 5 Feb 2009 09:56:06 -0800From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: Re: [M3devel] elminating pthread_attr_t from cloned headers



Hi all;I guess there was a 1995 try to change that Runtime error into an exception (not sure if they succeed). Take a look at:ftp://ftp.u-aizu.ac.jp/pub/lang/Modula/m3/pkg/contrib/whenNEWfails/src/Please be patient if the files don't appear when loading the web page (I tried 2 times to open that url with the source files). Hope this helps.Thanks--- El mié, 4/2/09, Mika Nystrom <mika at async.caltech.edu> escribió:
De: Mika Nystrom <mika at async.caltech.edu>Asunto: Re: [M3devel] elminating pthread_attr_t from cloned headersPara: "Jay" <jay.krell at cornell.edu>CC: m3devel at elegosoft.comFecha: miércoles, 4 febrero, 2009 11:33Jay writes:...>I'll maybe review more code along these lines.>I gather the general gist of things in Modula-3 though>is that out of memory is fatal anyway. Raising an exception>vs. failing an assertion probably not significantly different>if the exception is not meant to be caught and isn't ever caught.>(Strange though then the gymnastics I pointed out elsewhere>converting one form of out
 of memory to another form..)...Back in SRC days I remember there was a discussion at some lengthabout what to do in case of running out of memory.  I think theproject was abandoned as people realized it was quite a trickyproblem...I don't believe PM3 has out of memory exceptions, nor did SRCM3...?  It's a wild guess but maybe this has something to do withthe Critical Mass modifications for their JVM?     Mika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090205/8f18cb1f/attachment-0002.html>