4 ms·
Can anyone comment on the duebugability of Loom (e.g. how do stack traces work)? Can Loom threads jump between native threads? Is it easy to understand what is
by anonymousDan 4y ago
Can anyone comment on the duebugability of Loom (e.g. how do stack traces work)? Can Loom threads jump between native threads? Is it easy to understand what is going on when I run all this under a debugger? Having worked with some user level threading systems in the past as part of some libos work the the fact the tooling wasn't really set up to handle such issues made it really difficult to understand what was going on when we ran into problems.
- kaba0 4y agoI can’t answer everything, but good debugging is a very important design goal of Loom, so the usual debug methods should work the exact same way they do with native threads.
- aardvark179 4y agoYou normally see the virtual thread’s stack. Virtual threads are normally run on a fork join pool or other executor service, and can run on any OS thread in that pool. They are not tied to any single OS thread. Yes, it is easy to understand in a debugger as support has been added to the debugger interface and to JVMTI, along with some Useful JFR events. We hope that in the future structured concurrency will make it even easier to understand huge numbers of virtual threads in production.
- anonymousDan 4y agoRight but the problem we had was that when you fired up the debugger (GDB) you could only see the stack traces of the currently active user level thread on each host thread. To understand what was going on in other user threads (e.g. who is holding what locks) you had to manually go into the scheduler data structures to find the descheduled threads etc, which was extremely tedious. If that all happens out of the box for Loom then that is great.