To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=72412
User mmeeks changed the following:
What |Old value |New value
================================================================================
CC|'ace_dent,mhu' |'ace_dent,mhu,mt'
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Mon Dec 11 03:32:23 -0800
2006 -------
sorry ace - nope, didn't mail is down. Yes this does overlap with codecleanup01
- on the other hand that CWS seems destined for non-integration [ at least,
there is no date for integration, and despite having a number of nice cleanups
it's not clear what's going on there ;-] mt ? any status ?
Anyhow - on the issue itself, I consulted the various authorities here:
[snip]
> Greetings Michael, Matthias. Brief weekend holiday in Paris finds me
> well; I hope you are both in high spirits, too.
Yes, thanks for asking.
>
> This does NOT sound useful!
Yes, I completely agree to Robert's reasoning below. Add a
multi-threaded application, and it will become even worse (one thread
returning that reserve memory, for another thread to eat away even more
memory).
And yes, there have been times when OS'es existed, where this was
useful. Think of 16bit-Windows (3.1) and MacOS 8 which had very simple
global memory management and only cooperative multitasking. On these
systems, this "memory reserve" trick actually used to work.
But these times are long gone and dead. So, don't hesitate to get rid of
this.
Enjoy your weekend,
Matthias
>
> First, yes, it can obviously provoke the very situation it wishes to
> solve--another 512KB closer to OOM.
>
> Second, however, the intent is not insane. You can in theory catch the
> errors and jump to pre-allocated space to do some unwinding. But in
> practice it will almost never work--by the time malloc fails, you are
> knee-deep in swap and, as you note, are quite unlikely to have enough
> room to do the intended work.
>
> To be at all useful--and if you do not/cannot do this, scrap the 512kb
> immediately--you need to memory lock ("wire") the pages AND prefault
> them into core by touching each page. Otherwise, the preallocated 512kb
> is worthless; you might as well allocate the 512kb AFTER the failure.
> The memory will be undoubtedly swapped out.
>
> On Linux, you can only mlock 32KB as non-root (intended to be just
> enough for things like gpg; in general locking pages is bad practice).
>
> Even if you could mlock all 512kb, you would have to ensure you could do
> the emergency cleanup / unwind / document saving 100% in those locked
> pages. Doubtful, given, at the least, the pages needed for library
> calls.
>
> It seems so useless I wonder if we (I) don't understand the feature, or
> if some other systems have VASTLY different memory allocation subsystems
> (Solaris, as far as I know, is close enough to Linux to make this
> feature questionable).
>
> In short, I guess if you can mlock & prefault all of the pages, it is
> worth looking at--but probably useless. Without the lock: save the
> memory and push OOM another 128 pages out.
[snip]
So - I attach the minimal patch extracted from cws-codecleanups01 that is in our
patch set now.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
