Clojurians Log v2
humbleui
I have been using HumbleUI intensively for the last couple of weeks and it is a wonderful improvement from how we needed to use Skija previously! I am using the UI framework a little and it works well. Primarily, though, I'm running a graph layout algo on ui/canvas via Skija. This updates and requests frames frequently, usually well over the 60fps. That seems to typically work well, rendering at a smooth 60fps. However I'm also getting intermittent UI lockups. Sometimes they happen after a minute or two, and sometimes it will be fine for an hour. There is nothing printed and no stack trace. The algo that I'm running from the repl will eventually complete, and when I Ctrl+C the process, it will briefly unfreeze and show the final frame for a fraction of a second before the window goes away. That tells me that the problem is somewhere in in HumbleUI or JWM. I'm sorry that right now I don't have any additional details. It's not too concrete which is why I didn't file a ticket yet, but I can if you'd like me to.
No it can’t include C++ resources. What if you do Runtime.getRuntime().gc() periodically? Will it prolong the time before freeze happens? If yes then it’s C++ resources
I've re-run with the GC being triggered roughly once every 150ms. The freeze still happens in roughly the same range of time. The range of time that it runs for is always quite variable. Sometimes it will only run for 30s before freezing, other times you get relatively long runs like the one above which was about 4 minutes.
Just to wrap up this thread, the issue has been fully resolved now.
Any chance you can share app code?
Even if not, you could record with JFR and then others could analyze the data without sharing code
I'm planning to open source, yes. Can I share the repo privately until I'm ready to actually release it?
@ben.sless thanks for mentioning JFR, I don't think I've used that before. I'll try it out.
I have some recordings that range in size from 8MB to 40MB. Should I just put them here? If not, I'll find some other way to share.
Those are pretty small files, you can share them here imo
Might be a GC issue. Try running it with some GC visualizer? There’s also a potential risk with not closing C++ objects. In that case they will be freed when collected by JVM GC, but JVM GC doesn’t know which objects are large and which are small (since they are allocated in C++ heap)
I just ran it in a loop until it it crashed. I think this screenshot provides a decent summary. Flat memory usage. The total memory used by "Java" according to activity monitor was stable at about 930MB for the last several minutes. Maybe that includes the memory allocated by C++? The window is correctly marked as "Not Responding" because it is not responding to events anymore, but I can still run commands on the repl and my process was continuing to run normally.
The slight drop in CPU load at 6:50 p.m. indicates the moment that the UI froze.
I'm also using some other visualizations that have 60fps D3 transition-style animations or are just periodically updated and so far I don't think I've ever had a crash with those.
You might want to hook clj-async-profiler or visualvm into your program to see if you can detect anything in the call stack correlated with the latency you observe.
http://clojure-goes-fast.com/blog/ has good guides on both, should you need them.
Yes thanks, both of those tools are great. I haven't yet tried digging into why this happens. I just thought I'd post the observation since I see someone mentioning something potentially similar above.