CoCreate Modeling FAQ: Memory management

How can I load models which exceed 2 GB in data size?

By default, both HP-UX and Windows limit the application's data space to 2 GB. The other 2 GB of the 32-bit address space are used for the system.

Various server versions of Windows, and recently also Windows XP Professional, provide a boot-time option which switches the operating system kernel into the so-called "4GT mode" where the kernel leaves 3 GB of address space to the application. This gives us an additional gigabyte of maenouvring space for model data.

Background explanations and instructions on the 4GT mode can be found in the Microsoft Knowledge Base at http://support.microsoft.com/kb/q171793 and http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx.

With CoCreate Modeling 2005, another option is to run CoCreate Modeling under Windows XP x64 Edition. On such a system, the available virtual address space for the application is close to 4 GB.

With CoCreate Modeling 2006, a full 64-bit version will become available which can use the vast amount of memory provided by 64-bit systems.

Wie kann ich Modelle laden, die mehr als 2 GB Speicher belegen?

Normalerweise begrenzen sowohl HP-UX als auch Windows den Adressraum, der von einer Anwendung für Daten benutzt werden kann, auf 2 GB. Die anderen 2 GB im 32-Bit-Adressraum werden für das Betriebssystem gebraucht.

Verschiedene Server-Versionen von Windows und neuerdings auch Windows XP Professional kann man in einem speziellen Modus starten, der den Betriebssystemkern in den sogenannten "4GT-Modus" schaltet. Dabei begnügt sich das Betriebssystem mit 1 GB Adressraum und überläßt die restlichen 3 GB der jeweiligen Anwendung. Damit erhält man ein zusätzliches Gigabyte für Modelldaten.

Hintergrundinformationen und Anweisungen zum 4GT-Modus findet man bei Microsoft in der "Knowledge Base" unter http://support.microsoft.com/kb/q171793 und http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx.

CoCreate Modeling 2005 läuft auch unter Windows XP x64 Edition. Auf solch einem System bekommen Anwendung Zugriff auf fast 4 GB Adreßraum, also noch einmal 1 GB mehr als selbst im "4GT-Modus".

Ab CoCreate Modeling 2006 wird es eine volle 64-Bit-Version von CoCreate Modeling geben, die dann auch den riesigen Adreßraum von 64-Bit-Systemen voll ausnutzen kann.

-- ClausBrod, last updated 3 December 2005

---

I have enabled the /3GB mode, but still cannot load models which require more than 2.6 or 2.7 GB. How come?

The 3 GB of address space which are left to the application are not used solely for data, but also for program components, such as the application code, any loaded DLLs, buffers which those DLLs allocate etc. For example, there are graphics drivers which allocate up to 256 MB in the application's part of the address space. Therefore, the maximum amount of data which can be loaded also depends on the number of activated system components (such as drivers).

Ich habe den /3GB-Modus eingeschaltet, kann aber immer noch keine Modelle laden, die mehr als 2.6 oder 2.7 GB brauchen.

Die 3 GB Adressraum, die der Anwendung zugeordnet sind, werden nicht nur für Daten, sondern auch für Programmkomponenten verwendet, beispielsweise also für den Programmcode selbst, mitgeladene Systembibliotheken (DLLs), von diesen DLLs angelegte Puffer und anderes. Beispiel: Manche Grafiktreiber legen einen Puffer von bis zu 256 MB im Adressraum der Anwendung an. Daher hängt die maximale Datengröße, die man noch unterbringen kann, auch von der Anzahl und Art der aktivierten Systemkomponenten (wie etwa Treiber) ab.

-- ClausBrod

---

Why does the Windows taskmanager only display a little more than 3.5 GB of physical RAM even though I have 4 GB of RAM in the system?

Some BIOS versions reserve certain address areas below the 4 GB line for themselves which they then use for memory-mapped I/O. Memory-mapped I/O is a method to integrate hardware components into the system. The system talks to those hardware components by reading from and writing to hardware registers which appear in the address space just as if they were part of regular memory.

Because those hardware registers are mapped into the address space below the 4 GB address line, no real RAM can be mapped into the same address space. To avoid conflicts between those hardware registers and RAM, the BIOS will hide the RAM in those address areas - which is why the Windows task manager cannot find it.

Advanced 32-bit systems could actually try to map the hardware registers into address space above the 4 GB line. However, this is often not done because this requires full PCI compliance from all PCI hardware devices in the system, and vendors do not want their systems to crash just because a user plugs in a PCI card which does not implement the full PCI specification. Hiding some RAM in the BIOS is probably the lesser evil in this case.

-- ClausBrod

Warum zeigt der Windows-Taskmanager nur etwas über 3.5 GB Arbeitsspeicher an, obwohl ich 4 GB RAM installiert habe?

Einige BIOS-Versionen reservieren bestimmte Adreßbereiche unterhalb der 4-GB-Marke für sich und benutzen sie für memory-mapped I/O. Das ist eine Methode, um Hardwarekomponenten im System zu integrieren. Das System kommuniziert mit den Komponenten, indem es aus Hardwareregistern liest und in diese hineinschreibt. Diese Hardwareregister werden in den normalen Arbeitsspeicher eingeblendet; für den Prozessor sehen sie wie ganz normale RAM-Speicherstellen aus.

Weil diese Hardwareregister in den Speicherbereich unterhalb von 4 GB abgebildet werden, kann in diesem Bereich nicht gleichzeitig echter Speicher benutzt werden. Um Konflikte zwischen den Hardwareregistern und dem echten Speicher zu vermeiden, wird der echte Speicher vom BIOS "versteckt" und daher auch nicht vom Windows-Taskmanager gefunden.

Etwas schlauere Systeme könnten übrigens die Hardwareregister einfach in den Speicherbereich oberhalb der 4-GB-Marke einblenden, so daß sich erst gar kein Konflikt ergibt. Allerdings wird das nicht besonders häufig getan, weil das nur funktioniert, wenn alle im System eingesetzten PCI-Karten sich an die vollständige PCI-Spezifikation halten. Die meisten PC-Systemhersteller wollen aber nicht, daß ihre Systeme abstürzen, nur weil ein Anwender eine veraltete PCI-Karte einsteckt, die sich nicht ganz an die Konventionen hät - der BIOS-Ausblendetrick ist hier das kleinere Übel.

-- MichaelMueller (translation) - 18 Jan 2005

---

How do I delete the UNDO buffer?

How do I define the maximum number of UNDO steps kept in memory?

While working with CoCreate Modeling, the software keeps track of previous states of the model during the session in the so-called UNDO buffer. This, obviously, consumes some memory.

CoCreate Modeling will delete the UNDO buffer automatically every now and then, i.e. it only keeps a user-definable number of UNDO steps in memory. You can also explicitly clear the UNDO buffer:

• Open the Undo dialog using Edit/Undo/.
• Check the Expand option for advanced parameters
• Set the Max Back value to 1

Alternatively, you can achieve the same with a Lisp one-liner:

  (undo :max_back 1)

In the same dialog, you can also set the maximum number of UNDO steps which are kept in memory (Limit/Steps).

Wie löscht man den UNDO-Puffer?

Wie stellt man die maximale Anzahl der UNDO-Schritte im Speicher ein?

Während man mit CoCreate Modeling arbeitet, merkt sich die Software Zwischenstände des Modells innerhalb der aktuellen Sitzung im sogenannten UNDO-Puffer. Das kostet natürlich Speicher.

CoCreate Modeling löscht den UNDO-Puffer hin und wieder automatisch; nur eine - vom Anwender definierbare - Anzahl von Zwischenschritten wird im Speicher gehalten. Man kann auch den UNDO-Puffer explizit löschen:

• Den UNDO-Dialog über Bearbeiten/Rückgangig/ öffnen.
• Die Option MenüLang aktivieren
• Den Wert Max rückw auf 1 setzen

Man kann dasselbe auch mit einem Einzeiler in Lisp erreichen:

  (undo :max_back 1)

Im gleichen Dialog kann man auch die maximale Anzahl der gepufferten Zwischenschritte einstellen (über Grenzwert/Schritte).

-- ClausBrod

---

Limiting the UNDO buffer to 10 steps does not seem to work - sometimes the UNDO dialog reports more than 10 steps in the buffer!

This is quite normal - the limit which you specify is actually the minimum number of steps which will be kept. Every once in a while, CoCreate Modeling will check the number of modelling steps in the UNDO buffer, and removes all but the most recent 10 steps from the UNDO buffer (if 10 is the limit you specified, that is).

Die Anzahl der Schritte im UNDO-Puffer auf 10 zu begrenzen, scheint nicht zu funktionieren - manchmal zeigt der UNDO-Dialog mehr als 10 Schritte im Puffer an!

Das ist ganz normal - das Limit gibt die minimale Anzahl der Modellierschritte an, die aufgehoben werden. Ab und an prüft CoCreate Modeling, ob die Anzahl der Modellierschritte im Puffer das angegebene Limit überschreitet - wenn ja, werden alle überzähligen Schritte entfernt; die jeweils letzten 10 bleiben übrig (wenn man 10 als Limit angegeben hat).

-- ClausBrod

---

I deleted all UNDO buffers, but the Windows task manager tells me that the application still uses the same amount of memory. How can this be true?

The memory which was previously used for UNDO buffers is now free, but CoCreate Modeling does not return it to the operating system; rather, it assumes that it will be needed anyway by any CoCreate Modeling commands that follow, and so it keeps the memory around instead of returning it to the OS, figuring out after a few seconds that it actually still needs the memory, and requesting it from the OS again. So in this case, the values displayed in the Windows task manager are not a good indication of what is really going on.

Ich habe den gesamten UNDO-Puffer gelöscht, aber der Windows-Taskmanager sagt mir, daß die Applikation immer noch genausoviel Speicher belegt. Wie kann das sein?

Der Speicher, der zuvor für den UNDO-Puffer benutzt wurde, ist nun tatsächlich frei, aber CoCreate Modeling gibt ihn nicht an das Betriebssystem zurück. Stattdessen nimmt CoCreate Modeling an, daß der Speicher ohnehin bald wieder für irgendwelche Folgekommandos gebraucht wird, und daher wird der freie Speicher intern bereitgehalten, anstatt ihn erst an das Betriebssystem zurückzugeben, nur um nach ein paar Sekunden festzustellen, daß man den Speicher doch wieder braucht, und ihn dann umständlich und zeitaufwändig beim Betriebssystem wieder anzufordern. In diesem Fall sind also die Werte im Windows-Taskmanager kein guter Anhaltspunkt dafür, was wirklich vorgeht.

-- ClausBrod

Why deleting a model does not really delete the model

New CoCreate Modeling users are sometimes confused by the following observation: They load a large model; some memory is consumed, according to the Windows task manager. Then they delete the model - and even more memory is consumed!

Session 1: After loading a large model

Session 1: After deleting the model

This seems counterintuitive - after all, the model was just deleted, so shouldn't there be more free space now rather than less?

One part of the explanation is outlined in the previous entry - CoCreate Modeling maintains its "free memory lists" internally, rather than returning once allocated virtual memory to the operating system. But this does not explain yet why the Windows task manager claims that CoCreate Modeling consumes even more memory after deleting the model.

If you think about it for a moment, however, it's all very simple: The model was only marked as deleted, but it is actually still in memory - in an UNDO buffer! This way, you can undo the deletion when you find that you actually still need the model. Marking the model as deleted, however, adds more administrative data to the model, which is why it is possible that more memory is required for a model in an UNDO buffer than for the same, freshly loaded model.

If, after loading a model, you really want to remove the model from memory, simply UNDO the load operation, then proceed modelling. LOAD-UNDO-LOAD can be a lot more efficient (in terms of memory and performance) than LOAD-DELETE-LOAD.

Session 2: After loading a large model

Session 2: After UNDO

Warum beim Löschen des Modells nicht wirklich gelöscht wird

Wer neu ist in CoCreate Modeling, den verwirrt gelegentlich die folgende Beobachtung: Man lädt ein großes Modell; laut Taskmanager in Windows wird auch so einiger Speicher dafür verbraucht. Dann löscht man das Modell - und es wird sogar noch ein wenig mehr Speicher verbraucht!

Das scheint widersinnig - denn schließlich hat man das Modell gerade gelöscht; sollte es dann nicht mehr freien Speicher und nicht weniger?

Ein Teil der Erklärung ist umrissen in der Antwort auf die vorige Frage - CoCreate Modeling verwaltet seine Freispeicherlisten intern, anstatt einmal angeforderten und nach dem Löschen von Daten wieder freigewordenen Speicher wieder ans Betriebssystem zurückzugeben. Aber das erklärt noch nicht, warum des Taskmanager behauptet, daß CoCreate Modeling nach dem Löschen des Modells sogar mehr Speicher verbraucht.

Wenn man einen Moment darüber nachdenkt, ist es alles ganz einfach: Das Modell wird nur als gelöscht markiert, aber tatsächlich bleibt es immer noch im Speicher - einem UNDO-Puffer nämlich! Auf diese Weise kann man das Löschen rückgängig machen, wenn man das Modell doch noch einmal braucht. Das Modell als gelöscht zu markieren, fügt dem Modell noch etwas Verwaltungsinformation hinzu - und so ist es möglich, daß für ein Modell im UNDO-Puffer sogar etwas mehr Speicher verbraucht wird als für das gleiche, frisch geladene Modell.

Will man nach dem Laden ein Modell wirklich aus dem Speicher entfernen, löscht man das Modell nicht, sondern macht einfach die Ladeoperation rückgängig und arbeitet dann weiter. LOAD-UNDO-LOAD kann um einiges effizienter sein (was Speicherverbrauch und Geschwindigkeit angeht) als LOAD-DELETE-LOAD.

-- ClausBrod - 09 Dec 2004

---

How do I use the memory-limit command?

Short answer: Don't use it at all. This will make your life a lot easier.

Long answer: The memory-limit command can be used to artificially limit the maximum amount of memory which CoCreate Modeling will request from the operating system during a session. By default, i.e. without using the memory-limit command, CoCreate Modeling will simply behave like any other application: It will request memory from the operating system on demand, i.e. when the model grows, CoCreate Modeling will ask for more memory.

Why would anyone prefer any different behavior? There are, in fact, some corner cases where memory-limit still serves or served some purpose:

• You run CoCreate Modeling along with some other application on the same machine, and you want to make sure that CoCreate Modeling does not allocate all the RAM, forcing the other application to page data out.
• You want to avoid paging at all, even while working in CoCreate Modeling only. (In that case, you'l want to specify the size of your machine's RAM as the memory-limit.)
• On HP-UX, the operating system is actually free to terminate processes without warning when it runs out of swap space. (At least this used to be true in older versions of HP-UX. I haven't checked the current status in a while.) In that case, you would lose all your data. However, this problem should be avoidable by proper swap space configuration - which is preferable to trying to work around the issue via memory-limit. Also, the problem seems to be rare in practice.
• In very old versions of CoCreate Modeling (in the golden days of HP-UX), the code established a rather low default memory limit because we wanted to be conservative and "nice" both to the operating system and to other running applications. In those versions, you actually had to use memory-limit if you wanted to load any sizable model at all.

The good ol' days are long gone, and CoCreate Modeling by default now grabs as much memory as it needs, relying on the operating system's memory management services to deal with the above issues. And that is actually the best solution; after all, it is the operating system which knows best about all running applications and can therefore make the best decisions about which pages should be swapped out and which application needs the highest priority.

"Well, maybe using memory-limit doesn't buy me much, but then, it doesn't hurt either, right?" Wrong. memory-limit commands tend to be added to some magic customization file and then be forgotten. As a result, when the machine is upgraded with more RAM, CoCreate Modeling will not be able to use it, and the user and/or sysadmin will have to figure out why, unnecessarily spending time and effort.

"So if memory-limit is so pointless, why didn't CoCreate simply remove it from the product?" Good question, this one. As a CoCreate developer, I can say: It is actually very tempting to remove the command. However, there are those corner cases (see above), and enough people out there still have memory-limit commands buried deep down in their configuration files, and if we no longer provided this function with a new release, they would run into Lisp errors when they start up the new code for the first time.

But from quite a number of years of experience in supporting CoCreate Modeling customers, I can say: Using memory-limit usually causes at least as many problems as it solves.

Summary: memory-limit? Just say no!

Wie verwende ich das Kommando memory-limit?

Kurze Antwort: Am besten gar nicht. Damit wird das Leben viel leichter.

Lange Antwort: Das Kommando memory-limit kann man benutzen, um die maximale Menge von Speicher zu konfigurieren, die CoCreate Modeling innerhalb einer Sitzung vom Betriebssystem anfordern darf. Normalerweise - also ohne das Kommando memory-limit - verhält sich CoCreate Modeling wie jede andere Anwendung: Speicher wird einfach nach Bedarf vom Betriebssystem angefordert, sprich: Wenn das Modell wächst, holt CoCreate Modeling mehr Speicher.

Wieso sollte sich überhaupt jemand ein anderes Verhalten wünschen? Tatsächlich gibt es ein paar Randfälle, in denen memory-limit einen Zweck erfüllt oder zumindest früher erfüllte:

• Man möchte CoCreate Modeling gleichzeitig mit einer anderen Anwendung laufen lassen, aber sicherstellen, daß CoCreate Modeling nicht den gesamten Hauptspeicher für sich belegt und damit die andere Anwendung zwingt, ihren Speicher temporär auf Platte auszulagern.
• Man möchte überhaupt jede Auslagerung auf Platte vermeiden, auch innerhalb von CoCreate Modeling selbst. (In diesem Fall gibt man die Größe des Hauptspeichers bei memory-limit an.)
• Wenn der konfigurierte Swapspace zum Auslagern auf Platte unter HP-UX knapp wird, kann das Betriebssystem sogar Prozesse ohne jede Warnung und vorherige Datensicherung beenden. (Zumindest traf das auf ältere Versionen von HP-UX zu; ich habe den aktuellen Status seit einer Weile nicht mehr verfolgt.) In so einem Fall verliert man alle Daten. Allerdings ist dieses Problem vermeidbar, indem man den Swapspace ausreichend konfiguriert - was in jedem Fall einem Notbehelf wie memory-limit vorzuziehen ist. Das Problem scheint in der Praxis auch eher selten.
• In sehr alten Versionen von CoCreate Modeling (in den guten alten HP-UX-Zeiten) stellte der Code automatisch einen sehr niedrigen Ausgangswert für memory-limit ein, weil wir sehr konservativ und besonders zurückhaltend gegenüber dem Betriebssystem und anderen Anwendungen agieren wollten. In diesen alten Versionen mußte man in der Tat memory-limit verwenden, wenn man größere Modelle laden wollte.

Die guten alten Zeiten sind indes lang vorüber, und CoCreate Modeling greift sich nun einfach soviel Speicher, wie es eben braucht. Dabei verläßt es sich auf die Dienste des Betriebssystems für die Speicherverwaltung, um mit Situationen wie den obigen zurechtzukommen. Und das ist auch tatsächlich die beste Lösung, denn schließlich weiß das Betriebssystem am besten Bescheid über alle gerade laufenden Anwendungen und ihren Speicherbedarf, und kann daher am besten sinnvolle Entscheidungen darüber treffen, welche Speicherbereiche auf Platte ausgelagert werden sollten und welche Anwendung gerade die höchste Priorität genießen sollte.

"Nun, vielleicht bringt mir memory-limit nicht viel, aber schaden tut es doch auch nicht, oder?" Falsch. memory-limit-Kommandos verbreiten sich gerne in alle möglichen Konfigurationsdateien und werden dann leicht vergessen. Das Ergebnis ist, daß CoCreate Modeling nach einer Hauptspeicheraufrüstung des PCs den zusätzlichen Speicher nicht benutzen kann, und prompt verlieren Anwender und/oder Systemverwalter eine Menge Zeit mit dem Versuch, die Ursache des Problems zu finden. Ich spreche aus Erfahrung.

"Wenn memory-limit so sinnlos ist, wieso hat CoCreate es nicht einfach aus dem Produkt entfernt?" Eine gute Frage. Als CoCreate-Entwickler kann ich sagen: Es ist in der Tat eine große Versuchung, das Kommando ersatzlos zu entfernen. Allerdings: Es gibt noch diese Randfälle (siehe oben), auch wenn sie immer unwichtiger geworden sind, und zudem verwenden genügend Anwender das Kommando in Konfigurationsdateien. Würden wir das Kommando einfach in einer neuen Version entfernen, liefen viele dieser Anwender beim ersten Start der neuen Version in einen Lisp-Fehler.

Aus der Support-Erfahrung einiger Jahre kann ich aber sagen: Das Kommando memory-limit verursacht im allgemeinen mehr Probleme, als es in der Praxis wirklich löst.

Zusammenfassung: memory-limit? Just say no!

-- ClausBrod

---

How much memory do I need in my system? How large should my paging file be?

These two questions are connected, because the paging file basically acts as substitute RAM in modern operating systems.

The questions which you really need to answer are:

• How much memory in total do I need in a session?
• How much of this memory should be RAM?

As a rough rule of thumb, the more RAM you have, the faster your system will be. However, depending on the kind of models you work with, you may not even come close to exhausting your memory, so adding RAM may also simply be a waste of money.

The right memory size always depends on the applications running on your system and the amount of data you handle in them. Therefore, a good way to determine paging file size is to measure actual memory consumption and then adjust the paging file or add RAM according to those data. Reasonable indicators are the "Commit Charge Peak" and "Commit Charge Limit" values in Windows Task Manager. "Commit Charge Limit" is the maximum amount of active memory which you can have in the system; its size is roughly determined by the amount of RAM plus the size of the paging file. The "Commit Charge Peak" tells you the maximum amount of memory which has actually been in use since you started the system. If the "Peak" value approaches the "Limit" value, it is definitely time to either think about ways to reducing memory consumptions in the applications you are running, or to add memory to the system, either as RAM or by increasing the paging file size.

Comparing the commit charge peak against the commit charge limit helps you answer the first question above, i.e. how much memory you need in total, RAM and paging file combined. In the example to the right, the commit charge peak is roughly at 1 GB, and the limit is at 1.5 GB. So if the test session was typical for the system, you can continue to work with that system without expanding the paging file or adding RAM.

However, the amount of physical memory in the system is 512 MB (see the "Physical Memory/Total" field in the dialog), while the test session actually consumed 1 GB. This is an indication that you might be able to gain significant performance during the test session by adding more RAM to the system.

-- ClausBrod - 26 Dec 2005

---

When asked for a TWiki account, use your own or the default TWikiGuest account.