In fact I’ll rather use the Java version as it seems a little faster than the WinGUI. Transactions SE37 and BAPI work terrific in SAP Gui for Java. I primarily do Web Dynpro Java development and hence does not need to use the SAP Gui for much other than fetching RFC and BAPI specs and of course the occasional test drive of the two. I my opinion, the Mac is a superior platform in every way, and since it can run a virtualised MS Windows installation simultaneously by the help from VMWare, I decided that lacking support from SAP was not going to prevent me from using the best platform ever. The work to purge the VM of the assumption that GCs have one discontiguous memory reservation is required to pave the way for the macOS port.To set the record straight, I have to say I had been warned a lot against choosing the Mac platform because of the lacking platform support from SAP. The tests that usually run for ZGC on Linux, will be run for macOS too. We abandoned this approach because, a) it did not support large pages, and b) the macOS implementation of ftruncate may only be called once to set the size of a file, which made uncommitting memory impossible. It used a file descriptor approach, for multi mapped memory. We attempted an alternative prototype using POSIX shared memory objects. As a result, GC APIs such as is_in_reserved(), reserved_region() and base() will be removed from CollectedHeap. The shared VM code must also stop assuming that a single contiguous memory reservation is used by a GC implementation. However, on macOS, the ASLR mechanism intrudes into our address space, so ZGC must allow the heap reservation to be discontiguous.
On a default Linux configuration, that is a safe assumption to make. For that to work, we assume that no shared libraries will be mapped into the desired address space. On Linux, we reserve 16TB of virtual address space during initialization. Support in ZGC for discontiguous memory reservations. This memory is remapped into the various ZGC views of memory, representing the different pointer colors of the algorithm. The physical memory of the heap is maintained in a separate address view, conceptually similar to a file descriptor, but residing in a (mostly) contiguous virtual address instead. We will use the mach microkernel mach_vm_remap API for this. The ZGC design makes intensive use of colored pointers, so we need a way on macOS to map multiple virtual addresses (comprising different colors in the algorithm) to the same physical memory.
Support for multi-mapping memory on macOS.
The macOS implementation of ZGC consists of two parts: There are also users who wish to run desktop applications such as IDEs with ZGC.
While we expect users that require the scalability of ZGC to use Linux-based environments, it is not uncommon that developers use Macs for local development and testing, before deploying applications.
0 kommentar(er)
