[Vm-dev] fix for allocateJITMemory in VMMaker.oscog-eem.3047

stes@PANDORA.BE stes at telenet.be
Sun Aug 29 12:57:49 UTC 2021


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Please recall that I reported about a month ago, a new problem,
with allocateJITMemory().  That function is new since about late July 2021.

sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto mmap: Not enough space
sqAllocateMemory: initial alloc failed!

This error happens on Solaris 11.3 and OpenIndiana, but not on Solaris 11.4.

It still happens with VMMaker.oscog-eem.3047 but I believe I have a patch now.

bash-4.4$ products/sqcogspursunosht/usr/bin/squeak $HOME/squeak/v5/Squeak6.0alpha-19843-32bit.image 
sqAllocateMemory: initial alloc failed!

bash-4.4$ products/sqcogspursunosht/usr/bin/squeak -version $HOME/squeak/v5/Squeak6.0alpha-19843-32bit.image 
5.0-202108291033-OpenSmalltalk-Cog  Sun Aug 29 13:27:29 CEST 2021 cc [Production Spur VM]
CoInterpreter VMMaker.oscog-eem.3047 uuid: 548d0a5b-eb23-4df6-bbb1-0b431cc840b3 Aug 29 2021
StackToRegisterMappingCogit VMMaker.oscog-eem.3047 uuid: 548d0a5b-eb23-4df6-bbb1-0b431cc840b3 Aug 29 2021

I have been succesfully using a patch since about 3 weeks that seems to fix the issue.

All patches can be found at:

https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/runtime/smalltalk

In this case - it only affects the COG VM - the patch is:

09-sqUnixSpurMemory.patch 

https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/runtime/smalltalk/cog-spur/patches

Basically I copied old code which is doing alignment and pasted it into
allocateJITMemory() :

+++ 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 have been using this succesfully as follows.

bash-4.4$ patch -p1 < 09-sqUnixSpurMemory.patch 
patching file platforms/unix/vm/sqUnixSpurMemory.c

Basically when running this in "dbx" 

(2) stop change `squeak`sqUnixSpurMemory.c`pageSize

=>[1] allocateJITMemory(desiredSize = 0x826710) (optimized), at 0x5627d5 (line ~
282) in "sqUnixSpurMemory.c"
  [2] readImageFromFileHeapSizeStartingAt(f = 3, desiredHeapSize = <value unavai
lable>, imageOffset = <value unavailable>) (optimized), at 0x4e1968 (line ~21170
) in "cointerp.c"
  [3] imgInit() (optimized), at 0x4c8e84 (line ~1992) in "sqUnixMain.c"
  [4] main(argc = 2, argv = 0xffff80ffbfffed78, envp = <value unavailable>) (opt
imized), at 0x4c8ffd (line ~2110) in "sqUnixMain.c"


I had the impression that allocateJITMemory() which is a new function,
is not doing the same alignment computation as the old code which was working.

I compared with the alignment code in
sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto()

sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto() is using a different,
alignment computation ...

So out of considerations of symmetry or compatibility, I guessed that perhaps
it could be related to alignment and the details of how mmap() works on
Solaris 11.3 versus Solaris 11.4.

Indeed when copying/pasting the old alignment computation it works again,
on OpenIndiana and Solaris 11.3.

With that SpurMemory.c patch, 32bit and 64bit work again,
CoInterpreter VMMaker.oscog-eem.3047 uuid

Solaris 11.4 is not affected by the new issue, but I tested that the
alignment fix also works on Solaris 11.4.

What do you think, is it a good fix, can this be added please to allocateJITMemory ?

Thanks,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJhK4OLAAoJENdFDkXGicizsBoH/1GhBNRD+eL7EFrY2FaIbbZm
UGuhoSslHKOAEh4DrUvf1e9pYoiabmLUWdCpb6vQVGsrY8jDHFpKN9QCcsLILsOw
NdR8X2HW+KZl0oGniW4/UOL7m2tkRLYPbMwS8ACEnBXf69ffI02CwyvBWlCipTa2
yh+JQcDBgB/qd3qlTyHuGGvJZbtMIck1e6u2YMPLqTHyTaX0dskWRvm8ULKNbOLP
ofQYWr0DnwI132OOaPifA185dI5Bes5L7HEdpBcwR5GDg3fey9w5yZRVFkSmXnsQ
xJa0baeDGRYEh+CvWOj+H/nuvViqkSwpLJb9DvKR2l8l//lfmuiDJAKu594yh2Q=
=jMOC
-----END PGP SIGNATURE-----


More information about the Vm-dev mailing list