Maximum Object Size in .Net

General discussions related to APLNext's VisualAPL.

Moderators: Tech Support, phpbb_admin

Maximum Object Size in .Net

Postby joe_blaze » June 17th, 2009, 11:29 pm

Using 64-bit harware and a 64-bit version of the Windows operating system, the memory available to a specific application window is increased to an amount which greatly exceeds the analogous limit for 32-bit hardware and a 32-bit operating system.

Generally in the 32-bit environment, an application window has available up to 2Gb (in a few cases 3Gb). In all cases the actual amount of memory available to an application window is limited to the excess of the available physical memory over the memory required by the operating system and running services.

Evidently, any specific .Net object, including an array, is limited to 2Gb in both 32-bit and 64-bit .Net programs. .Net provides inherent memory manangement which incorporates this limit.

So in the 64-bit environment, assuming that the appropriate physical memory has been installed, many 2Gb objects can be created and manipulated, but in the 32-bit environment it is unlikely that even one 2Gb object can be created and manipulated effectively.

Using custom memory manangement, one can exceed this Microsoft-imposed design limitation:
    Arrays can be implemented as blocks, each of which does not exceed this limit, and an appropriate function to calculate the appropriate block number to set or get array values can be developed. This approach would still result in fully-managed code.

    Arrays could be implemented using un-mananged code involving custom memory management and memory pointers.


For additional comments on this issue see:
http://msdn.microsoft.com/en-us/library/ms241064(VS.80).aspx

http://msdn.microsoft.com/en-us/library/ms241064.aspx

http://stackoverflow.com/questions/5736 ... 2147483647

http://www.informit.com/guides/content. ... seqNum=592
Last edited by joe_blaze on July 3rd, 2009, 4:02 pm, edited 1 time in total.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Note on .Net Memory Management and VisualAPL

Postby joe_blaze » June 30th, 2009, 12:51 am

.Net maintains a secure, managed environment by not providing physical memory pointers to objects in memory. This avoids a significant malware threat. The Microsoft memory manager automatically allocates virtual memory to a running application and automatically recovers (‘garbage collects’) memory no longer needed by an application.

This is different than APL+Win which uses a proprietary memory management and garbage collection system based upon the legacy Win32 API (application programming interface) which permits direct access to physical memory by an application.

[list]• This means that in VisualAPL, in-line assignment by value of several variables (a â†
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Determine memory available in .Net

Postby joe_blaze » November 16th, 2010, 9:54 am

View the attached pdf-format document to see how to obtain the memory available to a .Net application and the memory available to a .Net process. Using VisualAPL, a .Net language, multiple processes each with their own memory heap can be started, controlled and ended. Such processes can interact with each other using the multi-threading tools of .Net.
Attachments
Memory Available .Net.pdf
(268.12 KiB) Downloaded 635 times
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361


Return to VisualAPL

Who is online

Users browsing this forum: No registered users and 3 guests

cron