Pointers in 64-bit architectures are unlikely to exhaust their vast address range, and are as such needlessly big. Reducing the amount of memory a pointer occupies leads to reduced memory demands, better usage of memory, and better locality. Pointer compression is a term that encompasses techniques that aim to make pointers occupy less memory, often to 32-bit for the sake of word alignment. Pointers that are 32-bit embody the opposite problem of having too restricted of an address range, being able to address only 4 GB. Z is a garbage collector in the HotSpot JVM which does not support pointer compression. Partly because the aforementioned address range restriction, and partly because the implementation of compressed pointers which exist in HotSpot would clash with the goals of the garbage collector. This project explores ways of implementing pointer compression for Z that isn't detrimental to the goals of the garbage collector, and aims to find where problems may occur. The outset was to explore compressing speculatively during runtime. The result is a design that relies on a custom bit layout for compressed pointers, inspecting bit layouts of the pointers on each read and write to detect the compression status. This seems to be the most promising in terms of code maintainability and ease of implementation.

Java is one of the more recent programming languages that in runtime free applications from manual memory management by using automatic Garbage collector (GC) threads. Although, at the cost of stop-the-world pauses that pauses the whole application. Since the initial GC algorithms new collectors has been developed to improve the performance of Java applications. Still, memory related errors occurs and developers struggle to pick the correct GC for each specific case. Since the concept of microservices were established the benefits of using it over a monolith system has been brought to attention but there are still problems to solve, some associated to garbage collectors. In this study the performance of garbage collectors are evaluated and compared in a microservice environment. The measurements were conducted in a Java SpringBoot application using Docker and a docker compose file to simulate a microservice environment. The application outputted log files that were parsed into reports which were used as a basis for the analysis. The tests were conducted both with and without a database connection. Final evaluations show that one GC does not fit all application environments. ZGC and Shenandoah GC was proven to perform very good regarding lowering latency, although not being able to handle the a microservice environment as good as CMS. ZGC were not able to handle the database connection tests at all while CMS performed unexpectedly well. Finally, the study enlightens the importance of balancing between memory and hardware usage when choosing what GC to use for each specific case.