especially many gigabytes in 64-bit Linux?
For example, system has 6 GB free memory. Is possible to alloc it in ONE block or 60 100-mega blocks ?
Many block very complicate algorithms, for example : one heap structure: parent index = 1/2 child index, child index = 2*parent index.
I want have one large heap, but if will many blocks, algorithm will difficult and inefficient.

what language? have you tried it at all? How?

Language c++

have you tried it at all? How?

I would frankly suggest that you probably should not pursue this approach. Here are a handful of possible reasons why:

It's actually virtual storage. Your application's entire memory-space is carved up into "pages" which are demand-loaded from external storage. When you use up the total number of physically resident pages that you can presently have, pages begin to get "stolen." Each page-operation requires milliseconds to complete ... apiece.

Locality of reference: This is the pivotal assumption upon which the entire concept of virtual memory is built, and it's the key to building production systems that consistently perform well. The virtual memory manager assumes that "the next memory reference" made by your application "probably will be nearby to" some other memory reference that the same app made "recently."

If you need "arrays" in your source-code, C++ allows you to use that syntax ... even if the underlying implementation is different.

It is generally unwise to "roll your own." C++ has a truly vast standard library of classes, with plenty more available from well-known Internet sources.

I concur with these thoughts. If you are using a general purpose OS environment, then don't try to use the maximum available and stress the limits. If you are working on a custom system, an embedded one, where memory management is performed, you can pre-define a memory segment to be reserved when you construct the system. That is how things such as this are performed. A custom system is constructed where this large memory segment is reserved solely for the use of your custom program.

A general purpose OS just isn't going to provide you with maximum services to protect things and also allow the location of the memory to be consistent. I know you weren't asking for that, but in my opinion, this would be the next step when you tried to debug the fruits of your first level effort.

C++'s standard (and contributed) libraries are fairly stuffed with good "container classes" that will enable applications to have the functional illusion of "an unlimited, n-dimensional storage space within which to work," which some applications do need. But, they do it efficiently, being extremely mindful of the vagaries of virtual storage ... particularly the fundamental(!) concern of locality of reference.

"Don't fret over nanoseconds" here. There is no price-to-be-paid by slightly longer code paths taking a few billionths of a second more. No, the real price is measured in "multiple milliseconds," and they occur with every page fault.

Uncontrolled, or simply unplanned-for, page fault activity is rudely called, "thrashing." Or, as I used to say back in the days when a 20-megabyte disk drive was about the size of an apartment's washing-machine, "Maytag® Mode." We literally had one of those devices slowly juggle itself to the very edge of the raised floor, over in the corner where a few tiles were removed, and ... (The spinning disk broke loose from the capstan and very nearly went sailing out across the machine room.)

The performance-degradation curve caused by thrashing is variously called "elbow-shaped" or simply, "hitting the wall." It basically goes straight to Hell straight up, exponentially. Poorly designed applications which need lots of RAM are especially vulnerable to it, the moment they come out of the memory-rich "developer's environment" and an attempt is made to deploy them to production.

You can reserve memory on the kernel command line using memmap=, then create a virtual address in your userspace program that points to it. You will need to rebuild the kernel to allow access via /dev/mem.

http://lwn.net/Articles/267427/