RFR: 8229517: Support for optional asynchronous/buffered logging [v2]
Thomas Stuefe
stuefe at openjdk.java.net
Tue Mar 30 13:36:09 UTC 2021
On Tue, 30 Mar 2021 13:17:05 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> Hi Xin, regrading the VM thread blocking on logs.
>
> If you instead use two arrays, one active and one for flushing, you can swap them with atomic stores from the flushing thread.
> And use GlobalCounter::write_synchronize(); to make sure no writer is still using the swapped out array for logging.
>
> The logging thread would use GlobalCounter::critical_section_begin(), atomic inc position to get the spot in the array for the log, store the log and then GlobalCounter::critical_section_end().
>
> That way you will never block a logging thread with the flushing and run enqueues in parallel.
>
> If you want really want smooth logging you could also remove the strdup, since it may cause a syscall to "break in" more memory.
> To solve that you could use the arrays as memory instead, and do bump the pointer allocation with an atomic increment to size needed instead of position.
+1. This is what I meant with my strdup() critique. Does the Deque does not also allocate memory for its entries dynamically? If yes, we'd have at least two allocations per log, which I would avoid. I'd really prefer a simple stupid fixed-sized array here (or two, the double buffering Robbin proposed is a nice touch).
As I wrote before, this would make UL also more robust in case we ever want to log low level VM stuff without running into circularities. Ideally, UL should never have relied on VM infrastructure to begin with. That is a design flaw IMHO. UL calling - while logging - into os::malloc makes me deeply uneasy.
>
> I tested a bit locally generally I don't think there is an issue with blocking the VM thread on flushing.
> So I'm not really that concern about this, but it's always nice to have an algorithm which is constant time instead. (Neither CS begin()/end() or atomic inc can fail or loop on x86)
-------------
PR: https://git.openjdk.java.net/jdk/pull/3135
More information about the hotspot-dev
mailing list