Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.
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.
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.
Regards,
David Stes
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.