Author |
Topic: LB 4.5.0 memory allocation failure (Read 1072 times) |
|
tsh73
Full Member
member is offline
Gender: 
Posts: 210
|
 |
Re: LB 4.5.0 memory allocation failure
« Reply #6 on: Aug 19th, 2015, 8:10pm » |
|
Quote:| with still only 33% of the memory used |
|
Just for the record, how much memory your computer has?
I just checked - minimal for Win 7 8 8.1 10 still 1Gb for 32 bit Windows.
|
| « Last Edit: Aug 19th, 2015, 8:16pm by tsh73 » |
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LB 4.5.0 memory allocation failure
« Reply #7 on: Aug 19th, 2015, 9:31pm » |
|
on Aug 19th, 2015, 8:10pm, tsh73 wrote:| Just for the record, how much memory your computer has? |
|
4 Gbytes I think.
To put the 33% memory usage into context, when I am running no foreground applications at all, apart from Task Manager itself, it reports 28% usage. When I am also running Internet Explorer Edge (which I was at the time, as you can see) it reports 30% usage. So the 20 instances of bbcwrun6.exe were using maybe 3% of the available memory. In fact you can see how much memory each instance was using from the screenshot - only about 2 Megabytes each!
All modern operating systems work the same way. When a program writes to (allocated, but as yet non-existent) memory it generates a 'page fault'. This causes the OS kernel to 'page in' some real memory at that address - a page usually being 4 Kbytes. After 4K of memory has been written another page fault will be generated, and another chunk of real memory paged in, and so on.
Using that strategy it really doesn't matter how much virtual memory your program initially allocates, because it doesn't use up any 'real' memory until it is actually written to. What does matter however is the amount of contiguous address space you try to reserve, because if the memory map has been fragmented (typically by DLLs) it will be impossible to allocate more than the largest fragment. This is completely independent of the amount of physical RAM fitted.
So I have set the amount of memory allocated by LBB to 500 Mbytes because that is around the largest amount of contiguous address space that you can be fairly confident will be available (under XP, anyway). But (initially) none of that 500 Mbytes is mapped by the operating system to physical memory. As I explain above, only when memory is actually written to does it get mapped to real RAM.
Windows, unlike Linux, makes a distinction between 'reserving' and 'committing' virtual memory. It so happens that LB 4.5.0 'reserves' 1 Gbyte of memory whereas LBB 'commits' 500 Mbytes. This will cause Process Explorer to report the memory usage differently, but in all normal circumstances you don't need to worry about the difference. And in Linux/Wine there is no difference anyway.
Richard.
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: LB 4.5.0 memory allocation failure
« Reply #8 on: Aug 20th, 2015, 01:19am » |
|
Thanks for clarifying that.
RE:
Quote:I fired up Win 7 in VMWare, 1GB ram (VMWare supposed default)
so it shows 2GB memory - 1 read and 1 virtual.
I run a program from LBB (...)
And I can run only one instance of LBB, no matter that.
It just don't start. |
|
After Win7 ends its update cycle, I was able to run 3 instances of LBB program.
Then 4th said "no room".
On next attempt, 4th instance run.
(probably Windows just made more virtual memory - it now shows "peak" commit more then 2 GB - at 2.7)
(and Task Manager shows "memory" - it says "physical memory" at 36%, Process Explorer Commit charge at 80%
Empty values are 32% Task Manager and 28% Process Explorer )
|
| « Last Edit: Aug 20th, 2015, 01:23am by tsh73 » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: LB 4.5.0 memory allocation failure
« Reply #9 on: Aug 20th, 2015, 09:30am » |
|
on Aug 20th, 2015, 01:19am, tsh73 wrote:After Win7 ends its update cycle, I was able to run 3 instances of LBB program.
Then 4th said "no room". |
|
That may be because you are running in a VM. This is what it says at MSDN:
"As an alternative to dynamic allocation, the process can simply commit the entire region instead of only reserving it. Both methods result in the same physical memory usage because committed pages do not consume any physical storage until they are first accessed. The advantage of dynamic allocation is that it minimizes the total number of committed pages on the system. For very large allocations, pre-committing an entire allocation can cause the system to run out of committable pages, resulting in virtual memory allocation failures."
It is this "running out of committable pages" that you are probably experiencing. In practice this is very unlikely to be a problem, but if you have specific issues (for example because you are running in a VM) what I can do is to make the amount of committed memory configurable by a setting in the INI file. Would that be helpful?
Richard.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: LB 4.5.0 memory allocation failure
« Reply #10 on: Aug 20th, 2015, 10:35am » |
|
Quote:what I can do is to make the amount of committed memory configurable by a setting in the INI file. Would that be helpful?
|
|
Yes it definitely will be.
I would be very grateful if it wil became configurable somehow.
|
|
Logged
|
|
|
|
|
