Re: Ranting about JVM's default memory limits...

On Sat, 02 Aug 2008 18:02:17 -0700, Zig <none@xxxxxxxxxxx> wrote:

On Sat, 02 Aug 2008 18:57:40 -0400, Arne Vajhøj <arne@xxxxxxxxxx> wrote:

See above for 2G not being accepted on my machine.

Many 32 bit OS including Windows split the total of 4 GB in system
space and process space.

Java can only use process space.

2 GB - "some stuff" is what is available.

I find this interesting: could you provide some further information on this?

He simply means that out of the 2GB virtual address space allocated to each process, there is already going to be "some stuff" that every process has and which consumes part of the virtual address space right off the bat. You'll never ever, no matter what, be able to allocate an actual 2GB block of memory.

I had previously been under the impression that the 2 GB limit comes into effect for applications that are likely to do signed comparisons on pointers - such as needing to call a legacy routine which returns sub-zero values when it needs to indicate an error and an error-code in one result.

Not exactly. It's a hard limit on the total range of addresses allowed for a given process. On 32-bit architecture, a native pointer can theoretically address up to 4GB of addresses. But, the OS needs part of the processes virtual address space for itself, and so the OS reserves a portion of the address space.

Originally, 32-bit Windows split it half and half, with the user code getting 2GB and the OS getting 2GB. But, the OS didn't really need 2GB of address space, and so enabling "LARGEADDRESSAWARE" tells the OS that the application doesn't make any assumptions about the range of pointers and that it can pass user data addresses to the process in the first 1GB of the second 2GB of the full 4GB address space. No application should be making assumptions about the addresses in the first place, but you know how it is: when there's something true about the platform, someone will figure out a way to write code that depends on that.

Windows doesn't have any functions that return "negative pointers" for errors. It will either return a pointer, which is null on error, or it will return some kind of result code. Either an actual 32-bit error code or simply a boolean success/failure code (when an actual error code isn't returned, usually a process can call GetLastError() or an equivalent to get the actual error code). So there's not any "legacy routine which returns sub-zero values" for errors, at least not in the OS.

Of course, there's nothing to stop 3rd-party vendors from writing code like that, even though they shouldn't. So that's why "LARGEADDRESSAWARE" exists. Every application that would otherwise work but was compiled pre-LARGEADDRESSAWARE suffers as a result of Windows trying to make sure bad applications don't break.

Now, on top of all that, the virtual address space can easily become fragmented. Memory blocks aren't moveable, so allocations can sit in between two free blocks, limiting the size of the largest block that can actually be allocated. Depending on the allocation pattern, it's not hard at all to have over 1GB of virtual address space left, but not be able to allocate any single block nearly that large.

Personally, I think that any application that finds itself bumping up against the 2GB limit is likely to only get a short reprieve by enabling the "LARGEADDRESSAWARE" flag. In reality, that application probably ought to just be a 64-bit application. I don't know if there's a Windows Java run-time that's 64-bits, but there ought to be. :)

[...]
Without that flag being set in the executable files, I believe the OS limits the memory the process may request. In theory, you can use "editbin" to manually set it - but flipping bits in compiled exe files seems to be asking for trouble.

It sure does. :) That said, if it's something you _really_ need to do, I suppose it'd be worth a try. As long as the problem accepts the full 32 bits for a pointer, and doesn't do anything funny with that 32nd bit, in terms of looking at it directly or comparing the whole thing as greater/less than zero, it should work fine.

And yes, the OS (indirectly) limits the memory the process may request based on that flag. In particular, it's not so much that the OS sets a particular limit, but rather it's constrained by the range of memory addresses the OS believes the application can understand. By default, Windows will assume a 32-bit application can only deal with addresses in the lower 2GB range of the 32-bit pointer and so can only return memory allocations that fit within that range.

I am surprised that those flags aren't set when Sun does a java build - it would be nice if they were.

It does seem odd. Though, perhaps it's that way because Sun's implementation actually does do something funny with the addresses and can't support pointers outside that 2GB range. That would definitely be a bad thing, but no doubt worse decisions have been made (whether in implementing Java or other platforms).

Pete
.

Relevant Pages

  • Re: Help wanted - problems with heap
    ... Memory pressure, because of limited heap size. ... identified that by failures to allocate memory. ... Any pointers as to work out what is happening would be welcome. ...
    (rec.games.roguelike.development)
  • Re: non-paged memory inside a kernel driver
    ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ... With their stuff running I cannot allocate 10 MB 's on a XP system. ... so I need 100MB of non-paged memory inside my driver. ...
    (microsoft.public.development.device.drivers)
  • Re: How to allocate memory for a linked list of pointers in a kernel process
    ... are you sure you access memory at proper ... lists using pointers of course. ... When the kernel routines need to allocate a ... Are you aware that the kernel contains routines to do doubly linked lists ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Compiler options and memory overheads
    ... >If you allocate tens of megabytes, you better use an allocator based on ... Another reason is that users with a "little knowledge" about memory ... this again reduces support calls and complaints. ... customers about Windows internals. ...
    (microsoft.public.vc.language)
  • Re: non-paged memory inside a kernel driver
    ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ... With their stuff running I cannot allocate 10 MB 's on a XP system. ... so I need 100MB of non-paged memory inside my driver. ...
    (microsoft.public.development.device.drivers)