RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v8]
Thomas Stuefe
stuefe at openjdk.org
Mon Sep 12 05:58:03 UTC 2022
On Mon, 12 Sep 2022 05:40:03 GMT, Xin Liu <xliu at openjdk.org> wrote:
>> Current implementation of AsyncLogWriter uses dynamic memory. There are 2 sources.
>>
>> 1. Overhead of pointer-based linked-list.
>> 2. strdup of message contents
>>
>> This implementation has impact on glibc/malloc. If allocation of logsites interleave with other allocation, it's hard to clean up all glibc arenas. This worsens fragmentation issue.
>>
>> In this PR, we replace linked-list with `2 pre-allocated raw buffers`. AsyncLogWriter appends payload AsyncLogMessage to the serving buffer and avoids all dynamic allocation. Please note this effort won't eliminate mutex lock. We use ping-pong buffers to guarantee AsyncLogWriter is still non-blocking. A buffer serves as a FIFO queue like before.
>>
>> In addition, AsyncLogWriter doesn't enqueue meta messages anymore when it needs to report the number of discarded messages. This is archived using a temporary hashtable called `snapshot`. It copies the working hashtable with the protection of lock and reset it. After writing all regular messages, AsyncLogWriter writes meta messages from snapshot.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>
> get rid of TOKEN_SIZE. use Message::calc_size(0) instead.
>
> it's still a compiler-time constant like TOKEN_SIZE. put the
> headroom logic in Buffer::push_back().
src/hotspot/share/logging/logAsyncWriter.cpp line 52:
> 50: // Reserve space for a flush token, so 'push_flush_token' always succeeds.
> 51: AsyncLogWriter::Buffer::Buffer(size_t capacity) : _pos(0), _capacity(capacity) {
> 52: _buf = NEW_C_HEAP_ARRAY(char, capacity, mtLogging);
I would give it a low minimal size. It needs to be at least token size, but small enough to serve as a good test for simulating buffer overflows. Maybe 2-3 x header size + ~64 bytes or so. E.g. 96 bytes?
-------------
PR: https://git.openjdk.org/jdk/pull/10092
More information about the hotspot-runtime-dev
mailing list