MozillaZine

Full Article Attached New Memory Management Plan for Feedback

Saturday May 8th, 1999

Rick Gessner, Director of Engineering of NGLayout at Netscape, is calling for standardization in Mozilla's memory management techniques. If you are a mozilla developer, please read this, and post any comments to Rick's duplicate post in the layout newsgroup. Click Full Article below to read Rick's report.


#1 Exceptions

by Ben White

Sunday May 9th, 1999 11:09 AM

Reply to this message

Clearly Rick is correct about the need for this problem to be solved.

But why not use exceptions? This is EXACTLY what they're in the language for. A good overall exception handling system can make a software system easier to write and more reliable.

Seems like an obvious question.

#2 Re:New Memory Management Plan for Feedback

by Brendan Eich <brendan@mozilla.org>

Sunday May 9th, 1999 2:12 PM

Reply to this message

C++ exceptions are not up to snuff on all platforms; see <http://www.mozilla.org/do…atBuild/portable-cpp.html> for details, and tell Ramiro (mailto:<ramiro@netscape.com>) if you have new data.

Here are some links and prior art that should be incorporated into rickg's fine proposal:

Step 4: we already have an nsIAllocator, it has existed for a while: <http://lxr.mozilla.org/mo…com/public/nsIAllocator.h>

Use it either by getting its service (for example, <http://lxr.mozilla.org/mo…base/src/nsBuffer.cpp#324>), or by statically linking with the xpcom library and calling the nsAllocator class's static methods (<http://lxr.mozilla.org/mo…/public/nsIAllocator.h#88>).

Arena links: <http://lxr.mozilla.org/mo…ource/base/src/nsIArena.h> <http://lxr.mozilla.org/mo…/nsprpub/lib/ds/plarena.h>

Smart pointers links: <http://lxr.mozilla.org/mo…e/xpcom/public/nsCOMPtr.h> <http://lxr.mozilla.org/mo…om/public/nsXPIDLString.h>

/be

#3 Recyclers, Exceptions

by Marko Macek <Marko.Macek@gmx.net>

Monday May 10th, 1999 1:03 AM

Reply to this message

Since mozilla usually is not the only thing running in the system it is important to use recyclers only when they really have huge benefits .

In other cases it would be best to return as much memory as possible back to the system.

Re: exceptions:

I'd prefer mozilla not to use exceptions. Code generated by gcc seems much better/smaller when they are not used. Has anyone tried to compile mozilla with -fno-exceptions (and possibly with -fno-rtti)?

#4 Re:New Memory Management Plan for Feedback

by Gregory

Monday May 10th, 1999 10:19 AM

Reply to this message

The only safe approach is to provide your own allocator that throws bad_alloc for platforms that don't yet support it. It's too easy to make mistakes, otherwise. Furthermore, have you considered that require in "if (blah==NULL) { do_whatever(); }" *also* results in additional code? I'd be somewhat surprised if gcc's implementation of exceptions is any worse than that. In any event, standard c++ will become more common over time, and all that NULL testing will no longer work on newer platforms.

#5 Re:New Memory Management Plan for Feedback

by mark rawling <mwr@npec.netscape.com>

Monday May 10th, 1999 1:05 PM

Reply to this message

If you can't use exceptions then you'd almost be better off banning pointers altogether. Use smart pointers, auto pointers and references everywhere. Or maybe even change new() to never return NULL unless there really is no more memory, in which case you can panic there. Otherwise all the checking and specical casing will make the code bloated, buggy and impossible to comprehend.

As for exceptions, you can establish rules for object ownership and transfer thereof so that a generic goto error label will know how to clean up before returning an error code. Error checking then becomes a simple, unobtrusive macro. Or how about adding an exception arg to (most) every funtion? The jmc approach. It's ugly but it works.

#6 Exceptions and recycling

by Mike Shaver <shaver@mozilla.org>

Monday May 10th, 1999 2:15 PM

Reply to this message

Simply calling free() or delete is not enough to give the memory back to the system in most cases. An object allocated from the middle of a page can't be returned until everything else on that page is released, and even then you can't sbrk() back down if there are other things allocated ``after'' it.

As far as exceptions go, we do currently use -fno-exceptions and -fno-rtti with gcc/egcs, and the space savings are considerable. Also, use of exceptions across XPCOM boundaries is pretty much begging for pain. I don't think that even MS COM permits exceptions across COM interface boundaries, and they're a lot more prescriptive about compiler behaviour than we are.