Stack Commit Size, Stack Reserve Size

[Josef Templ]

Did you relink a new blackbox.exe file for the test?
Module Kernel is part of the linked executable.

- Josef

[Mobatec]

Anyone any suggestions for the original question? I'm rather stuck and would really like a solution

- Mathieu.

[Mobatec]

Oh, sorry, I didn't notice that after 10 comments I had to click to the next page

Yes, Josef, I relink new blackbox.exe for testing.

[Josef Templ]

Oh, sorry, I didn't notice that after 10 comments I had to click to the next page

Yes, Josef, I relink new blackbox.exe for testing.

When you open the file dialog, is the stack almost empty or is it almost full?

It would be good to have a small test program that we can use for
reproducing the behavior.

The only other idea that I currently have is to avoid the large stack by allocating large data structures on the heap.
This would give you much more memory but it is of course a change in your model loader.

A very large stack has at least one additional disadvantage: it slows down garbage collection a lot
because it introduces a huge number of roots. Note that in BB the stack is collected using a conservative
(not a precise) approach. Anything on the stack that looks like a pointer is treated like a pointer
and may keep otherwise unreachable objects alive.

- Josef

[Mobatec]

How do I check if the stack is empty or full? I don't have much experience with this.
In the end, all I need is that the .exe behaves as it should AND that I can load my large models. So, I like your idea about allocating large data structures on the heap, but also here I don't know how that works. I currently make use of the Externalize and Internalize routines of Stores..
- Mathieu.

[Mobatec]

The only other idea that I currently have is to avoid the large stack by allocating large data structures on the heap.
This would give you much more memory but it is of course a change in your model loader.

Hi Josef,

Any hints on how to do this?

- Mathieu.

[Ivan Denisov]

The only other idea that I currently have is to avoid the large stack by allocating large data structures on the heap.
This would give you much more memory but it is of course a change in your model loader.

Hi Josef,

Any hints on how to do this?

You can use ARRAY buffers and riders above them. Ilya Ermakov said, that he had used something like that to increase the efficiency.
For example, if you have some list structure of with 10000 REALs you can create the ARRAY and then access to this list items by id etc. Try to experiment with your data model to reduce calling NEW and amount of POINTERs. I think, that Josef meant this.
Anyway, can you make some example module for demonstration?

[Mobatec]

Hi Ivan,

A bit hard to give an example module. To have an idea about what our models look like have a quick look at this video: https://www.mobatec.nl/web/videos/Mobatec_Modeller.webm

What we store is a mixture of a lot of information in a "Mobatec Modeller Model": Graphical, mathematical, numeric, preferences, etc. When a model becomes big, there is just a lot of information to be stored. I'm not talking about accessing the information of a loaded model, btw, I have implemented HASH tables for quick access of information. The question was on loading a big model into memory, which at one point resulted in a Stack Overflow message. I then increased the Stack Commit and Reserve size of the executable, which had as a positive result that I could load my big models, but the negative effect is that the Windows Explorer apparently has to little memory to work correctly. I was looking for a solution for the latter

The package that we've build over the years consists of over 100 Component Pascal modules. Making an "example module for demonstration" would be missing the point of the question (I think). I hoped there would be some "settings" in which I can load big models and also the Windows Tools would work properly. The DevLinker part unfortunately goes beyond my knowledge, hence the quest for some help

- Mathieu.

[Josef Templ]

if the stack grows very big than you have either a very deep recursion, ie a lot of active procedure frames on the stack,
or you have large local arrays of some data (, or both). Most probably you have very large arrays as local
variables on the stack and a moderate level of nesting or recursion.
Try to allocate those local variables not on the stack but on the heap.

An example: instead of using the following pattern:

Code: Select all

PROCEDURE LoadSomething(...);
  VAR arr: ARRAY 100000 OF REAL;
BEGIN ...

use this instead:

Code: Select all

PROCEDURE LoadSomething(...);
  VAR arr: POINTER TO ARRAY OF REAL;
BEGIN arraysize := ...; NEW(arr, arraysize);

where arraysize is either 100000 (as above) or the precise number
of elements if you know them in advance, which is usually the case.

- Josef

[Mobatec]

Thanks for the suggestion, but the large arrays that I use are already in a dynamic form and take the actual size. I always try to minimize the allocation of new objects. There is quite a deep recursion, though.
There are typically a lot of smaller arrays in my models, not several large ones.
For example a "system" has a pointer to a parent, child, left and right system. Each system holds a lot of information, both local information and pointers to global information. When a model becomes big, there are many thousands of these systems. So, even if I find a way to slightly improve the loading of a model, I will still run into a stack overflow problem if the model becomes big. Is there not a way to just overall assign more memory to BlackBox?