Hi Paolo, Thank you very much for the explanations.
> The amd64 code assumes in many places that executable code is > reachable > within +/- 2 GB, because that allows using a faster code sequence. > On Linux the code we produce is stored in pages allocated with the > MAP_32BIT mmap option and this usually makes the above assumption be > true (there are still issues possible even with this option). > So as a first thing, you should check if solaris/amd64 has a similar > mmap() option: you should reserve the memory from the lower 32 bit > virtual memory space. The code is in utils/mono-mmap.c and > mono-codeman.c (grep for 32BIT). Solaris' sys/mman.h does define _MAP_LOW32 for that purpose - but only conditionally if _KERNEL were defined. So not being able to use the define directly inside #ifndef MAP_32BIT, I defined it to _MAP_LOW32's value of 0x80 instead of the default of 0. This leads to a segmentation fault and core dump at runtime prior to any of my debug output (no "TYPE: 1" either). > If this solution is not available or it is not working, the real fix > will need to be implemented in utils/mono-codeman.c: at startup a > large > chunk of virtual memory needs to be reserved and instead of using > mono_valloc directly, chunks from this memory area are taken. This > ensures all the generated code is within the memory bounds reachable > from the call instruction. Additionally the memory would need to be > reserved close to the address space where the program and shared > libraries are loaded (or the jit code must be changed to always call > native code with an indirect instruction). > > This last solution is what I have in my todo list as a way to speedup > the generated code for architectures where a call instruction can't > reach all the address space (basically anything but x86). I have no > idea > when I'll actually get to that todo item... Before we dig around too deep inside Mono, is there some command for me to temporarily limit the available swap memory to check if it actually works with <= 2GB available? Andreas _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
