Hi David,

> On Aug 11, 2023, at 6:39 AM, David Stes ***@***.***> wrote:
>
>
> Hi,
>
> I have sent in the past email to Eliot Miranda about an issue which I discovered in August 2021 (two years ago), and I thought to raise an issue here.
>
> It is a Linux/UNIX patch issue with the behavior of the mmap() system call or library call as used by the OpenSmalltalk COG vm.
>
> When way back in 2021 some changes were made for Linux ARM8 to the file saUnixSpurMemory.c I reported that this was breaking the Solaris 11.3 build. Curiously the Solaris 11.4 build was still working fine.
>
> I think (I don't know) that perhaps the behavior of mmap() on Solaris 11.4 is slightly diferent than on 11.3, to match (perhaps) the Linux kernel behavior of mmap().
>
> An idea that I have is to ask some UNIX guru's whether there exist a autoconf-archive (configure script) test or script to test the behavior of mmap() for portability.
>
> However here I will just report what the issue is : since august 2021 I am building succesfully on Solaris with the following patch
>
>
> --- opensmalltalk-vm-sun-v5.0.34/platforms/unix/vm/sqUnixSpurMemory.c Fri Aug 13 19:54:42 2021
> +++ p0/opensmalltalk-vm-sun-v5.0.34/platforms/unix/vm/sqUnixSpurMemory.c Sun Aug 15 14:11:58 2021
> @@ -277,16 +277,21 @@
> {
> void *hint = sbrk(0); // a hint of the lowest possible address for mmap
> void *result;
> + char *address;
> + unsigned long alignment;
>
> pageSize = getpagesize();
> pageMask = ~(pageSize - 1);
>
> + alignment = max(pageSize,1024*1024);
> + address = (char *)(((usqInt)hint + alignment - 1) & ~(alignment - 1));
> +
> #if !defined(MAP_JIT)
> # define MAP_JIT 0
> #endif
>
> *desiredSize = roundUpToPage(*desiredSize);
> - result = mmap(hint, *desiredSize,
> + result = mmap(address, *desiredSize,
> #if DUAL_MAPPED_CODE_ZONE
> PROT_READ | PROT_EXEC,
> #else
> I really need Eliot's help on this.
>
> Eliot : what I did was try to understand your code and you seem to make some alignment calculations on the desired memory location that you request through mmap().
>
> I believe that the traditional UNIX mmap() or the Solaris 10 and Solaris 11.3 mmap() is reacting slightly differently to the requested memory "hint".
>
> By some experimentatoin and debugging I found the above patch, which I wrote based on looking at your code and try to mirror the calculations that you are doing, which are not fully symmetric.
>
> By copying some code, I discovered that with the above patch the build for both Solaris 11.3 and Solaris 11.4 are working fine again.
>
> I think this is a general UNIX issue that could be of interest to all UNIX software.
>
> If an autoconfigure autoconf-archive test would exist to test the behavior of mmap() then that could be dealt in all software that uses mmap() with anonymous memory mapping.
>
> As far as I know the history of the mmap() call is that it originated in the world of Sun and Solaris and is since a very long time present in Linux as well, and I think some improvements in Linux where then backported to Solaris 11.4.
>
> That would explain why the current OpenSmalltalk-VM code works fine on Solaris 11.4.
>
> For reasons of portability to all flavors of UNIX and Linux, I think a configure build test for the code could benefit portability of your Cog VM.
>

I wonder whether your version would work on all platforms. Can you email me your version of the file? That’s easier than working with the patch.

Also, can you hum a few bars on what’s different in n the Hinton your version?

Here’s the intent behind the code:

In Spur memory is laid out as follows:
As low as possible: JIT code zone (absent in StackInterpreter)
Above and potentially contiguous with code zone: new space

Above and potentially contiguous with new space: first old space segment, loaded from image file

All three can be allocated with one or two map calls, one if execute permission can be applied after the fact to the code zone.

Thereafter new old space segments must be allocated above new space. This is because the store check that maintains the remembered set (those old space objects that refer to new space objects) simply compares an oop (an object’s address) with the end of new space/first old space segment.

So at first the hint is used to ask the OS to allocate the memory low and thereafter is used to ask the OS to allocate the memory higher.

> Let us know please what you think. I could simply submit my patch as a patch to mainstream upstream OpenSmalltalk but I don't know your opinion about it.
>

If it works, it works. Looks OK to me but I’d much rather have one version than choosing via autoconf so email me your version, I’ll play with it, and if it works I’ll replace the old version with yours, otherwise I’ll probably add ifdefs to allow one to select your version via a C compiler flag. Autoconf is, IMNERHO, thd spawn of the devil ;-)
> And the way I have been using it as a platform specific patch (that I apply prior to the build on Solaris) is fine for me as well.
>

I admire your forbearance and am grateful for your patience. Sounds like a pain in the butt to me!
> Regards,
> David Stes
>
Cheers, Eliot
_,,,^..^,,,_ (phone)

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.