Change the heap reservation for 64-bit platforms.

Hoard reserves a chunk of the address space to grow the heap into.
As there is a much larger address space available on 64-bit systems,
we may as well reserve a larger chunk of address space (64GB for now,
though could probably reserve a lot more than that and still leave
plenty of room for other areas).

64-bit printf warning fixes in libroot.

64-bit fixes to Hoard.

* Implemented a way to specify additional debug options via MALLOC_DEBUG when
using libroot_debug.so, instead of having to hardcode them in the application
via calling private heap functions.
* The following options are implemented: 'p' turns on paranoid validation,
'w' triggers periodic wall checking every 500ms ('W' does the same, but every
100ms), 'g' to use guard pages (beware, this will dramatically increase
memory usage), and 'r' which forbids reusing of memory, freed memory is never
actually freed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40514 a95241bf-73f2-0310-859d-f6bbb57e9c96

* init_after_fork(): In case the reservation for the heap area failed
sHeapBase will probably not point to memory in the heap area. Use
sFreeHeapBase instead.
* When reserving the heap area range fails, set sHeapBase to NULL, so we'll
later know about the fact.
* hoardSbrk(): When resizing the area fails, we'll now try to allocate a new
one, if the former failure was not due to an "out of memory" situation.
E.g. if the heap range reservation failed or, if we just have exhausted the
range, another area could be in the way. Also when mmap()ing over
malloc()ed, the heap area count be split in two with the first part
retaining the old area ID, thus preventing resizing as well. Fixed #5168.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34897 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Some minor cleanup and improved comments.
* Fixed check in hoardSbrk(): resize_area() was invoked, even if the area was
already large enough.
* Increased the initial heap size to 64 pages. Apparently the hoard
implementation is rather generous and the first malloc() (caused by
__init_heap()) already required enlarging the area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34336 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed _kern_reserve_heap_address_range() to _kern_reserve_address_range(),
and added a _kern_unreserve_address_range() as well.
* The runtime loader now reserves the space needed for all its areas first
to make sure there is enough space left for all areas of a single image.
* This also fixes the final part of bug #4008.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31115 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Patch from Olivier Coursiere: restore sFreeHeapSize in case of resize_area failure


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29013 a95241bf-73f2-0310-859d-f6bbb57e9c96

Increase the heap size in 64 KB steps. Was 4 KB before, which was a bit
slow for short-running, heap-intensive programs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27925 a95241bf-73f2-0310-859d-f6bbb57e9c96

implement sbrk() by calling hoard's version, through sbrk_hook (fct pointer was named this way in R5).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17540 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed the _kern_init_heap_address_range() syscall to _kern_reserve_heap_address_range()
and made it more powerful.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16825 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a real yield function to the kernel (using the next_priority approach).
The test application lets run a thread at the highest priority that calls
yield all the time - the system stays responsible when it runs, so it seems
to work fine :)
Changed the malloc implementation to use _kern_thread_yield() instead of
snoozing.
We should think about making this call public, too.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16166 a95241bf-73f2-0310-859d-f6bbb57e9c96

snooze(5) works more or less fine for standard threads, but is a very bad
idea for real-time threads. They could completely hog the CPU in this
case. Thanks to Marcus for investigating!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16161 a95241bf-73f2-0310-859d-f6bbb57e9c96

Found and fixed number one app_server crashing bug: our Hoard backend didn't
support unsbrk(), and that is actually called quite often in Hoard, resulting
in out of memory quite fast.
We don't shrink the heap (yet), but at least we can reuse the memory that
was freed by Hoard (it doesn't just remove bytes from the end, it will also
free up smaller parts in the middle).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15655 a95241bf-73f2-0310-859d-f6bbb57e9c96

The heap is now located at 384 MB, and creates a reserved range that spans over the
following 1152 MB - that area only guarantees that the heap can grow this much before
the application need the memory for something else. And even then, the heap range
is reused from top-to-bottom, allowing for maximum heap usage. Of course, if the
memory after the heap range is not claimed yet, it can still be claimed by the heap,
too. Added new syscall to create the reserved range.
Fixed a bug in vm_delete_areas(): when it removed reserved areas, the area list
could get messed up.
Fixed a bug in resize_area(): resized areas could never be deleted (missing vm_put_area())!
resize_area() now supports reserved regions (but not perfectly yet, see ToDo items).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12692 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed src/kernel to src/system.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12359 a95241bf-73f2-0310-859d-f6bbb57e9c96

Change the heap reservation for 64-bit platforms.

Hoard reserves a chunk of the address space to grow the heap into.
As there is a much larger address space available on 64-bit systems,
we may as well reserve a larger chunk of address space (64GB for now,
though could probably reserve a lot more than that and still leave
plenty of room for other areas).

64-bit printf warning fixes in libroot.

64-bit fixes to Hoard.

* Implemented a way to specify additional debug options via MALLOC_DEBUG when
using libroot_debug.so, instead of having to hardcode them in the application
via calling private heap functions.
* The following options are implemented: 'p' turns on paranoid validation,
'w' triggers periodic wall checking every 500ms ('W' does the same, but every
100ms), 'g' to use guard pages (beware, this will dramatically increase
memory usage), and 'r' which forbids reusing of memory, freed memory is never
actually freed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40514 a95241bf-73f2-0310-859d-f6bbb57e9c96

* init_after_fork(): In case the reservation for the heap area failed
sHeapBase will probably not point to memory in the heap area. Use
sFreeHeapBase instead.
* When reserving the heap area range fails, set sHeapBase to NULL, so we'll
later know about the fact.
* hoardSbrk(): When resizing the area fails, we'll now try to allocate a new
one, if the former failure was not due to an "out of memory" situation.
E.g. if the heap range reservation failed or, if we just have exhausted the
range, another area could be in the way. Also when mmap()ing over
malloc()ed, the heap area count be split in two with the first part
retaining the old area ID, thus preventing resizing as well. Fixed #5168.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34897 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Some minor cleanup and improved comments.
* Fixed check in hoardSbrk(): resize_area() was invoked, even if the area was
already large enough.
* Increased the initial heap size to 64 pages. Apparently the hoard
implementation is rather generous and the first malloc() (caused by
__init_heap()) already required enlarging the area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34336 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed _kern_reserve_heap_address_range() to _kern_reserve_address_range(),
and added a _kern_unreserve_address_range() as well.
* The runtime loader now reserves the space needed for all its areas first
to make sure there is enough space left for all areas of a single image.
* This also fixes the final part of bug #4008.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31115 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Patch from Olivier Coursiere: restore sFreeHeapSize in case of resize_area failure


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29013 a95241bf-73f2-0310-859d-f6bbb57e9c96

Increase the heap size in 64 KB steps. Was 4 KB before, which was a bit
slow for short-running, heap-intensive programs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27925 a95241bf-73f2-0310-859d-f6bbb57e9c96

implement sbrk() by calling hoard's version, through sbrk_hook (fct pointer was named this way in R5).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17540 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed the _kern_init_heap_address_range() syscall to _kern_reserve_heap_address_range()
and made it more powerful.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16825 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a real yield function to the kernel (using the next_priority approach).
The test application lets run a thread at the highest priority that calls
yield all the time - the system stays responsible when it runs, so it seems
to work fine :)
Changed the malloc implementation to use _kern_thread_yield() instead of
snoozing.
We should think about making this call public, too.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16166 a95241bf-73f2-0310-859d-f6bbb57e9c96

snooze(5) works more or less fine for standard threads, but is a very bad
idea for real-time threads. They could completely hog the CPU in this
case. Thanks to Marcus for investigating!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16161 a95241bf-73f2-0310-859d-f6bbb57e9c96

Found and fixed number one app_server crashing bug: our Hoard backend didn't
support unsbrk(), and that is actually called quite often in Hoard, resulting
in out of memory quite fast.
We don't shrink the heap (yet), but at least we can reuse the memory that
was freed by Hoard (it doesn't just remove bytes from the end, it will also
free up smaller parts in the middle).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15655 a95241bf-73f2-0310-859d-f6bbb57e9c96

The heap is now located at 384 MB, and creates a reserved range that spans over the
following 1152 MB - that area only guarantees that the heap can grow this much before
the application need the memory for something else. And even then, the heap range
is reused from top-to-bottom, allowing for maximum heap usage. Of course, if the
memory after the heap range is not claimed yet, it can still be claimed by the heap,
too. Added new syscall to create the reserved range.
Fixed a bug in vm_delete_areas(): when it removed reserved areas, the area list
could get messed up.
Fixed a bug in resize_area(): resized areas could never be deleted (missing vm_put_area())!
resize_area() now supports reserved regions (but not perfectly yet, see ToDo items).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12692 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed src/kernel to src/system.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12359 a95241bf-73f2-0310-859d-f6bbb57e9c96