mainsize.tst reports failure on successful 2GiB allocation using 32-bit Hercules.

[srorso]

When mainsize.tst is run on a non-Windows 32-bit version of Hercules (ptrsize=4), it reports test failure when a 2GiB memory allocation succeeds. The test expects a 2GiB allocation attempt to fail on 32-bit Hercules, and when the allocation succeeds, the Hercules message does not match the expected failure message.

A 2GiB allocation by a 32-bit app will "always" fail on Windows because Windows normally uses a 2GiB split between user space and kernel space. This can be changed using the /3GB boot switch or the /4GT parameter, but these are not recommended for other than specific-purpose Windows systems such as an Exchange server, and the change is only visible if Hercules were to be linked with /LARGEADDRESSAWARE. So on Windows, a 2GiB allocation attempt will fail.

It appears that most modern Linux systems use a 3GiB/1GiB split between user space and kernel space, as FreeBSD since 11.2. OpenBSD and NetBSD are also reported to use a 3/1 split.

Solaris 11.3, a 64-bit system, has a tool chain that normally produces 32-bit images, and when Hercules is built on 11.3 without the -m64 option, a 32-bit image is the result. Solaris 11.3 runs a 32-bit process in a 4GB (obviously) space that is mostly allocated to user space; it is possible to request 3.5GiB of mainsize when running 32-bit Hercules in Solaris. (A Solaris 32-bit process space as an unmapped reservation of about 112MiB starting at 0x00000000 and a mapped kernel space of about 31MiB ending at 0xffffffff, likely a trampoline area.

Solaris 11.4 appears to build 64-bit images. At least, ptrsize is set to 8.

I propose that the messages generated for a 2GiB allocations not be analyzed by mainsize.tst on 32-bit systems because they reveal little about Hercules and much about the specifics of the system running Hercules.

[jphartmann]

Right. The storage size tests for 32 bit mode has also given me infinite amounts of grief. Excise whatever you find troublesome. I suppose it is something each user will have to test herself.

[srorso]

A bit more research shows that Linux kernels as far back as at least 2.6.12, released June 2005, and perhaps older than that, used a 3/1 user/kernel address space split on 32-bit systems. Kernel 2.6.12 was the first to appear on Github. See https://github.com/torvalds/linux/blob/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2/include/asm-i386/page.h. lines 85, 124, and 131.

FreeBSD changed from a 2/2 split to a 3/1 split effective with release 11.2 as part of the project's Meltdown mitigation. See https://reviews.freebsd.org/rS332489).

Solaris is difficult to parse because it is closed source. Documentation dated July of 2009 shows a 3/1 split for 32-bit Solaris on x86 and a 4MiB exclusion from user space for a 32-bit process on SPARC. see https://www.oracle.com/technetwork/server-storage/solaris/solaris-memory-135224.html.

So I think I shall re-work the mainsize.tst testing to expect a 2GiB allocation to succeed on Linux and Solaris and to fail on Windows. Hercules responses to a 2GiB allocation on FreeBSD will not be analyzed as they are release dependent and host system release is not presently visible to the Hercules testing system.