Skip to content

Bispoke Deferred Destruction & Leak Detection + MappedBuffer Copy fix#982

Open
RuffledPlume wants to merge 7 commits into117HD:masterfrom
RuffledPlume:GLBufferFinalizerAndCopyFix
Open

Bispoke Deferred Destruction & Leak Detection + MappedBuffer Copy fix#982
RuffledPlume wants to merge 7 commits into117HD:masterfrom
RuffledPlume:GLBufferFinalizerAndCopyFix

Conversation

@RuffledPlume
Copy link
Contributor

@RuffledPlume RuffledPlume commented Mar 3, 2026

No description provided.

@RuffledPlume
Copy link
Contributor Author

RuffledPlume commented Mar 3, 2026

We could drop the last commit if need be, I'm 50'50 on it.
I've played for an hour with it & after the first load, we basically don't allocate a new GLBuffer until plugin reload/boats coming into view.

@RuffledPlume
Implemented DestructibleHandler
3bce3f1 
 * Handles deferred destruction of objects
 * Handles leaked objects printing debug info when encountering it
 * Flush during shutdown to catch any further leaks
 * Pool Zone VBOs instead of always recreating them
 * Better Pool Handling & removed Zone GLBuffer Pooling
@RuffledPlume RuffledPlume force-pushed the GLBufferFinalizerAndCopyFix branch from ebbd814 to 3bce3f1 Compare March 3, 2026 17:07
@RuffledPlume
Copy link
Contributor Author

RuffledPlume commented Mar 3, 2026

Ended up dropping the GLBuffer pooling, but kept the Destructible Handler as it's handles both deferred destruction & leak handelling

@RuffledPlume
Switch to Explicitly controlling life cycle of StagingBuffer
143dafa 
BufferUtils destructs the allocated memory when the garbage collector finalises the object, however if the ReservedView has its reference held the object will remain alive.

Therefore MemoryUtil should be used to directly control its life cycle so it is free'd once the memory has been uploaded to the GPU
@RuffledPlume RuffledPlume mentioned this pull request Mar 4, 2026
Closed
@RuffledPlume
Copy link
Contributor Author

RuffledPlume commented Mar 4, 2026

143dafa fixes a leak where DynamicModelVAO pools View holds a reference to ReservedView that could contain a IntBuffer allocated using BufferUtils which will only destruct the memory once the Java Garbage Collector finalizes the Java IntBuffer Object.

To avoid this entirely, I've switched from BufferUtils to MemoryUtils so that way the lifecycle of the IntBuffer is directly controlled by GLMappedBufferIntWriter once flush has been called it isn't valid to access any ReservedView, which DynamicModelVAO doesn't do but it just doesn't clear its reference until the next frame which is fine.

aHooder
aHooder requested changes Mar 4, 2026
View reviewed changes
Copy link
Member

@aHooder aHooder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the malloc change, I'm happy with this 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@aHooder aHooder aHooder requested changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@RuffledPlume @aHooder