Internal Memory Management in Visual FoxPro

Last reviewed: April 30, 1996
Article ID: Q130522
The information in this article applies to:
  • Microsoft Visual FoxPro for Windows, version 3.0

SUMMARY

Visual FoxPro handles memory management differently from previous versions of FoxPro. With FoxPro version 2.x, FoxPro had to pre-allocate one or more blocks of memory at startup. This is demonstrated by using MVCOUNT and MEMLIMIT. Visual FoxPro uses a more dynamic approach to memory management.

MORE INFORMATION

In Visual FoxPro, a small footprint is allocated and the reserved memory pool is dynamically increased as needed. When free contiguous space in the currently allocated blocks used by Visual FoxPro becomes low, Visual FoxPro will try to compress the memory block. If Visual FoxPro still needs more memory after compression, it requests another memory block from the operating system.

The requested block size is large, so Visual FoxPro doesn't have to send requests to the operating system often.

Along the same lines, Visual FoxPro doesn't release memory from the pool until the operating system requests it back. This is done because memory requested by Visual FoxPro is assumed to be needed again. It requires a lot of time to request memory from the operating system, so Visual FoxPro holds on to whatever it requests.

Memory Pools

When Visual FoxPro starts, it creates two memory pools (FOX USER and FOX BUFFERS). The FOX USER area stores memory variables, and FOX BUFFERS stores strings that are embedded in the product as well as any structures that are related to files that are open. Visual FoxPro pulls memory from three existing Windows resources - OLE, USER, and GDI resources.

Example Showing How Memory Pools Are Used

When a user opens a form owning a private DataSession and that form is instantiated, Visual FoxPro uses memory from the FOX USER pool to store information about the session and properties of the form. The FOX BUFFERS pool is used to cache parts of the tables that are open in the DataSession.

There is no Visual FoxPro command that forces the FoxPro memory manager to release the reserved memory blocks. The commands CLEAR ALL, RELEASE ALL, CLOSE ALL have no effect.


Additional reference words: 3.00 VFoxWin
KBCategory: kbenv
KBSubcategory: FxenvMemory


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 30, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.