GC Internship: Read Barrier Verification

In the fall of 2018, I had the opportunity to intern with OpenJ9’s Garbage Collection (GC) team. OpenJ9 is a Java Virtual Machine (JVM). At the time, I was a fourth year computer engineering student at the University of Waterloo.

Before working with the GC team, I had also worked in OpenJ9’s Release Engineering team. My projects focused on developing tools for developers. I developed a Jenkins API to get real time machine statistics. In addition, I worked on porting OpenJ9’s debugging tool (DDR) to AIX, which is an operating system.

Based upon past experiences, working for the GC team was a different learning experience. It exposed me to the memory management component of OpenJ9. It improved my approach to workflow management. I realized the importance of a smooth and robust workflow. My scripting skills, which were acquired from working with the Release Engineering team, greatly helped me to streamline my workflow on the GC team. I wrote scripts to automate the repetitive tasks.

During my internship with the GC team, I wrote instrumentation to catch direct memory read call sites. This included all sites that didn’t go through the standard access read barrier. In order to catch such call sites, the memory slots are poisoned. For poisoning, the memory references are modified to point to a slot on the shadow heap after every garbage collection cycle. Anyone who attempts to read directly from the poisoned memory slots without going through the read barrier verifier gets an inaccessible memory error. Poisoning and healing of memory addresses is not just limited to heap addresses. It is also extended to monitor table slots, JNI global weak references, and class statics.

Overall, the past four months have been an amazing experience. I got an opportunity to improve my understanding of the garbage collection strategies used in OpenJ9, and contribute to it. A huge thanks to my supervisor, Aleksandar Micic, for being an excellent mentor.

Leave a Reply