-
-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SignalTuple memory allocations #182
Comments
Creating the signal tuples all the time is really a bad idea. The purpose for all of this is to support generic signal handlers. Caching may be an option, also I don't really like that. I'm currently thinking of a solution which does not require the |
So I took some time and changed the signal handling a bit. |
Smashing! The The GC sawtooth pattern still shows a lot of churn: The Closing this ticket as fixed. Thank you! |
The following screenshot shows the memory allocations against the Gen 1 GC:
The method
getAllPossibleTuples
is creating 19 instances ofSignalTuple
for every message. Our application receives 64 messages per second, resulting in 1,216 objects per second. This stresses the GC.dbus-java/dbus-java-core/src/main/java/org/freedesktop/dbus/SignalTuple.java
Line 63 in 89ea49d
When the GC runs, it needs to free 600 to 700 kB of
SignalTuple
instances from memory.Here's a screenshot of the GC sawtooth:
Is it possible to cache these so that they are only created once?
The text was updated successfully, but these errors were encountered: