Hi Shiva, I’m preparing my application for the Apache AsterixDB GSoC 2026 project on Dynamic Memory Management, and I wanted to share one concrete contribution I completed while studying the codebase.
I’m currently a Master’s student in Computer Science at Beihang University. I previously interned at Shopee and ByteDance, where I worked on backend systems and infrastructure-related development. I’m particularly interested in systems, runtime behavior, and resource management, which is why this AsterixDB project strongly appeals to me. While studying the AsterixDB/Hyracks runtime, I identified a real issue in the NC-side memory path and opened the following PR: https://github.com/apache/asterixdb/pull/42 This patch fixes a runtime-side bug in Hyracks NC memory accounting, specifically in org.apache.hyracks.control.nc.Joblet. Joblet tracks outstanding frame memory in memoryAllocation, and close() uses that value to detect and reclaim leaked memory. In the previous code, however, deallocateFrames(int) increased memoryAllocation instead of decreasing it. As a result, even a balanced allocate/deallocate sequence could still leave a positive outstanding-memory count, and close() could incorrectly treat that memory as leaked and deallocate it again. I also fixed a related issue in the same path: if MemoryManager.allocate(bytes) succeeded but FrameManager.allocateFrame(bytes) later failed, the reservation was not rolled back. That could leave a phantom allocation behind and again interfere with leak cleanup. I added focused unit tests for both cases: - a balanced alloc/free sequence should not trigger an extra deallocation on close() - a failed frame allocation should immediately release its reservation I verified the patch with module test compilation and by directly running the new JobletTest, and the tests passed. I chose this issue because it is part of the execution/runtime memory path rather than a setup issue, and working through it helped me better understand the NC-side memory lifecycle in Hyracks. That code-reading process has also been directly useful for forming my understanding of how dynamic operator memory management could be introduced more systematically. I am continuing to study the current budgeting and memory-intensive operator path in AsterixDB/Hyracks, especially around runtime memory ownership, operator-level memory behavior, and where a future broker/resizing loop could be integrated safely. If helpful, I would also be glad to summarize my current understanding of the next implementation steps for the project. Best regards, Weijian Deng
