Jump to content
Excelsior Forums
Sign in to follow this  
jiverson

max application memory only 1.5 GB under Windows?

Recommended Posts

Hello,

Applications compiled with native XDS Modula-2 on Windows seem to limit the maximum memory available to an application to about 1.5 GB.  Other compilers allow up to 2 GB.  I've attached a small test program below.  When compiled with XDS (v 2.45) it exits at around 1.5 GB under Win 2K and Win XP Pro.  When compiled with the Stonybrook compiler, the program reachs 2 GB.  A similar C program compiled with MSC 6 also allocates up to 2 GB.

Any ideas as to the cause?  Is there a compiler or linker option that can be used to overcome this limitation?

Thanks for any help.

-Scott

MODULE test;

FROM SYSTEM IMPORT ADDRESS;

IMPORT STextIO, SWholeIO;

<*IF Stonybrook THEN*>

IMPORT WIN32;

<*ELSE*>

IMPORT Windows;

<*END*>

PROCEDURE Test;

VAR

  i : INTEGER;

  a : ADDRESS;

BEGIN

  i:=0;

  REPEAT

<*IF Stonybrook THEN*>

    a:=WIN32.GlobalAlloc(WIN32.GMEM_FIXED,100000000);

<*ELSE*>

    a:=Windows.GlobalAlloc(Windows.GMEM_FIXED,100000000);

<*END*>

    INC(i);

    SWholeIO.WriteInt(i,0);

  UNTIL a=NIL;

  STextIO.WriteLn;

END Test;

BEGIN

  Test;

  STextIO.WriteString("done"); STextIO.WriteLn;

END test.

Share this post


Link to post
Share on other sites

Thanks for the quick response.  I modified the test program to fill the allocated memory.  The respective max memory allocated is:

XDS - 1.4 G

Stonybrook - 2.0 G

MSC - 1.8 G

The Stonybrook test takes noticably longer to complete when filling memory, so I'm reasonably certain that the compiler is not optimizing away the initialization.

I can make an executable compiled with Stonybrook available if that would be helpful.

Thanks,

Scott

MODULE test;

FROM SYSTEM IMPORT ADDRESS, CAST;

IMPORT STextIO, SWholeIO;

<*IF Stonybrook THEN*>

IMPORT WIN32;

<*ELSE*>

IMPORT Windows;

<*END*>

CONST

  TestSize = 100000000;

PROCEDURE Test;

VAR

  i,j : INTEGER;

  a : POINTER TO ARRAY [0..TestSize] OF CHAR;

BEGIN

  i:=0;

  REPEAT

<*IF Stonybrook THEN*>

    a:=WIN32.GlobalAlloc(WIN32.GMEM_FIXED,TestSize);

<*ELSE*>

    a:=CAST(ADDRESS,Windows.GlobalAlloc(Windows.GMEM_FIXED,TestSize));

<*END*>

    INC(i);

    IF a<>NIL THEN

      FOR j:=0 TO TestSize-1 DO a^[j]:="A"; END;

      SWholeIO.WriteInt(i,0);

    END;

  UNTIL a=NIL;

  STextIO.WriteLn;

END Test;

BEGIN

  Test;

  STextIO.WriteString("done"); STextIO.WriteLn;

END test.

Share this post


Link to post
Share on other sites

As far as I can recall, Native XDS-x86 2.51 allocates for the heap the largest contiguous block of memory available from the operating system, provided of course you specify some huge value for HEAPLIMIT. It seems the size of such block on your system is 1.4GB.

Share this post


Link to post
Share on other sites

Changing the HEAPLIMIT doesn't appear to affect the result.  The test program allocates memory directly from Windows; it does not use the XDS memory manager.  I obtain the same results if I allocate a private Windows heap.

Does XDS reserve memory for the memory manager (even if it is not used) or do something else that might limit the available memory?  The only other cause that comes to mind is something related to how the executable is linked and/or loaded into memory.

The real application that exposed this strange limit is a 3D rendering app that really needs to have access to as much memory as possible.  Any help or hint you can provide would be much appreciated.

Thanks,

Scott

Share this post


Link to post
Share on other sites

Silly me! I overlooked the fact that you are using Win32 API directly.

What if you call Storage.ALLOCATE after GlobalAlloc returns NIL? Will it fail or succeed?

Share this post


Link to post
Share on other sites

Here's the code I added to the test:

i:=0;

REPEAT

  Storage.ALLOCATE(a,1000000);

  INC(i);

  IF a<>NIL THEN

    SWholeIO.WriteInt(i,0);

  END;

UNTIL a=NIL;

STextIO.WriteLn;

After GlobalAlloc returns NIL from the final attemp to allocate 100mb,  Storage.ALLOCATE successfully returns 1 1mb block before failing.

-Scott

Share this post


Link to post
Share on other sites

A followup:  on a machine with 4 Gb of RAM and Win XP 64 , the test program (with /largeaddressaware enabled) allocates 3.5 Gb before failing.  So it looks like a consistent 400-500 mb is inaccessible for some reason.

-Scott

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×