define larger array and SIGSEGV exception raised?

[tigerA15]

Why is everyone using the the array of array now days? Isn't the two dimensional array easier to read and understand? eg

Code: Pascal  [Select][+][-]

1. type
2.   TMyArray = array[1..15000, 1..15000] of integer;
3.   PMyarray = ^TMayArray;
4. var
5.   MyArray : PMyArray;
6. begin
7.   MyArray := GetMem(Sizeof(TMyArray));
8.   try
9.     MyArray^[1,1] := 1;
10.     MyArray^[1,2] := 10;
11.   finally
12.     FreeMem(MyArray);
13.   end;
14. end;
15.  
16.  

As martin said be aware of the size of your variables and where they leave. The above code will be able to allocate an array as big as 3GB in windows if there is enough memory that is.

OK , I see. Thank you  very much , thanks everyone.

[Thaddy]

Thaddy, you go too far.

Could you answer simple question(s):

Is it possible, in principle, the situation on some platform where you can get a total of 1.5 GB of memory by small pieces, but can not get 1 GB of memory in one piece?

If yes, then you need to consider whether such possibility?


P.S. My message is late, Martin_fr already explained everything.

For 32 bit yes. But you still do not understand how the memory manager allocates. The sub-allocater is for small blocks and can become very fragmented indeed, but large blocks (larger than the sub-allocator can handle) are allocated by the system because in that case the memory manager defers the call to system calls directly. That memory is contiguous and can be very, very large, like 3 G in 32 bit systems and a multitude of that in 64 bit systems. THAT is the point and part of the answer. I don't think I went too far. Nonsense is nonsense. First look inside the code of FPC's memory manager and you will see why.

[Martin_fr]

For 32 bit yes. But you still do not understand how the memory manager allocates. The sub-allocater is for small blocks and can become very fragmented indeed, but large blocks (larger than the sub-allocator can handle) are allocated by the system because in that case the memory manager defers the call to system calls directly. That memory is contiguous and can be very, very large, like 3 G in 32 bit systems and a multitude of that in 64 bit systems. THAT is the point and part of the answer. I don't think I went too far. Nonsense is nonsense. First look inside the code of FPC's memory manager and you will see why.

That has nothing to do with the problem. The system/OS is just another mem manager. It can not give you what is not there.

That is "not there" has nothing (or little) to do with physical installed memory. It is about address space (32 bit to form an address).

Independent of real memory the 32 bit address space is 4 GB. On windows approx 1 GB goes away for the OS.
The rest can be allocated.

But once you have allocated some memory in the middle of the address space, it is no longer continuous. Never mind if you allocate directly from the OS or via sub allocation.

The only question is how hard or easy it is, to get enough small allocations spread across the entire addr space

[Thaddy]

http://www.thefreedictionary.com/contiguous and learn something about it.
sequentially accessible. Addressable in a continuous way. Often (but not always) opaque( e.g. a high level object like TStringList can cover multiple pages from the OS and is STILL accessible in a continuous way.

[Martin_fr]

http://www.thefreedictionary.com/contiguous and learn something about it.
sequentially accessible. Addressable in a continuous way. Often (but not always) opaque( e.g. a high level object like TStringList can cover multiple pages from the OS and is STILL accessible in a continuous way.

I am aware of paging. And also that the address seen by the application has nothing todo with the physical address.

I am aware that
- an app can have memory at address 3GB, even if there is only 1GB of real mem
- if an app accesses memory at address X this can be anywhere within the real memory

That changes nothing of what I said.

Any memory accessed by the app must bi in its address space. (But can be mapped to anywhere within real memory)

If an app has a variable Foo at (virtual) address 0x40000000 then as long as foo is allocated, the same app can not have any other variable at that address. Otherwise the OS could not know what page to map to that address if it was accessed.

If the app has variables (of just a few bytes size) at (virtual addresses) 0x20000000 (0.5 GB), 0x40000000 , 0x60000000  and so on, then in is impossible to allocate a continuous (not native English, but pretty sure that is the word) block of memory that is bigger than 0.5GB, because any such block would have to contain one of those (virtual) addresses.
Swapping the current content of the memory at that virtual address to disk would not help, because the next time the app accesses it, it would be impossible to know which of the 2 variable (that both would (have to) contain the same (virtual) address) was accessed by the app.

Code: Pascal  [Select][+][-]

1. var
2.   a: array [0..999] of pbyte;
3.   b : pbyte;
4. begin
5.   // allocate a lot of memory in a very tricky pattern, then
6.   a[0] := getmem(16);  // assume OS return address 0x20000000
7.   a[1] := getmem(16);  // assume OS return address 0x40000000
8.   // .... up to address 0xE0000000 (or whatever your OS can handle as maximum
9.   b := getmem(0x40000000 ); // 1 GB
10.  

what address should B be at? So that "for i = 0 to 0x40000000 -1 do b := 0;" does at no time access any of the data pointed to by a

• ?