Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 335495 - HeapStd should support unlimited "heap size"
Summary: HeapStd should support unlimited "heap size"
Status: CLOSED FIXED
Alias: None
Product: RTSC
Classification: Technology
Component: Runtime (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Vikram Adiga CLA
QA Contact:
URL:
Whiteboard: targets: 3.25.00
Keywords:
Depends on: 292207
Blocks:
  Show dependency tree
 
Reported: 2011-01-26 13:56 EST by Sasha Slijepcevic CLA
Modified: 2013-04-04 17:08 EDT (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sasha Slijepcevic CLA 2011-01-26 13:56:33 EST 
+++ This bug was initially created as a clone of Bug #292207 +++
292207 was fixed in 3.20 series by adding a comment. In 3.21, we may want to remove programatically any limits for targets with unlimited heap.

------------------------------------------------------------------------------- 
On High-Level OS's (HLOS) like Linux and WinCE, malloc() has [essentially] no limit.  (I know, I know... there's always a limit, but it's "really big").

XDC users that integrate HeapStd-based heap managers into their HLOS system can easily trip up and "run out of memory" by allocating more than the configured heap size (typically the value of Memory.defaultHeapSize - which is defaulted to a meager 4kB!).

This 'heap size' is an artificial limit imposed by HeapStd on systems with virtual memory.  It forces system integrators to define some arbitrarily "big enough" amount of memory.  System integrators can never get this right - all they can do is configure it 'too small' - which, when hit, throws an Error and halts the system.

Not sure how to solve this... perhaps we should make HeapStd respect a '-1' heap size that means 'disable your size checking'?  This might render getStats() invalid - but maybe that's okay if eases this use case.

Comment 1 dave russo 2009-10-21 17:05:33 EDT 
The original motivation for requiring a size was to enable reasonably close
approximation of application behavior which is being run in a "host emulation"
environment.  Karl strongly advocated this use case and we should continue to
support it.

On the other hand, I completely agree that HeapStd should support an "unlimited
mode" to make it possible to leverage all underlying system resources.

Comment 2 dave russo 2011-01-10 20:14:04 EST 
Fix docs to mention how the heap size can be set to a arbitrarily large value -
0xFFFFFFFF - to address this particular usecase. In a later release (XDCtools
3.21?) address this problem by either
(a) Making a new heap module with a large default heap size 
(b) Changing the default heap size of HeapStd
Comment 1 Vikram Adiga CLA 2012-01-31 20:37:38 EST 
A special parameter HEAP_MAX has been added into the HeapStd module. Using this parameter when creating HeapStd instance will disable the size checking and allow unlimited memory mode (works as long as malloc() keeps allocating memory)

Also, if the Memory.defaultHeapInstance is not initialized, a HeapStd instance of size HEAP_MAX will be assigned to it by default.

Fix will be in released in the next xdc tree release (xdc-z05).
Comment 2 Sasha Slijepcevic CLA 2013-02-22 14:27:26 EST 
Verified against 3.25.00.40 using the native Linux targets and C64P ELF. I did not create a default heap in the config script, and I verified that in that case a HeapStd heap is created with the size of ~0U. Then, using Memory_getStats function, I verified that the size of the heap is ~0U at runtime.