RFR: 8229517: Support for optional asynchronous/buffered logging [v10]
Thomas Stuefe
stuefe at openjdk.java.net
Wed May 5 06:46:54 UTC 2021
On Wed, 5 May 2021 06:20:56 GMT, Xin Liu <xliu at openjdk.org> wrote:
> > I do not understand why you make the _tagset member in LogDecorations optional. Could you explain this?
>
> The reason I change _tagset from reference to pointer because I would like tosupport tagset is NULL.
> This is a corner case. When I inject meta-information, I don't have a appropriate tagset for the log message.
> [(null) ] is the result from LogDecorations with a NULL tagset.
>
> ```
> [24.933s][warning][(null) ] 1983 messages dropped...
> [24.943s][warning][(null) ] 1424 messages dropped...
> [24.953s][warning][(null) ] 2067 messages dropped...
> [24.964s][warning][(null) ] 2466 messages dropped...
> [24.972s][warning][(null) ] 1635 messages dropped...
> ```
>
> here is the relevant code snippet.
>
> ```
> bool AsyncLogMapIterator::do_entry(LogFileOutput* output, uintx* counter) {
> LogDecorators decorators = output->decorators();
> decorators.without(LogDecorators::tags_decorator);
> LogDecorations decorations(LogLevel::Warning, decorators);
> const int sz = 128;
> char out_of_band[sz];
>
> if (*counter > 0) {
> jio_snprintf(out_of_band, sz, UINTX_FORMAT_W(6) " messages dropped...", *counter);
> output->write_blocking(decorations, out_of_band);
> *counter = 0;
> }
>
> return true;
> }
> ```
Ah, I get it. I thought LogTagSet is a bitmask... why would it not be a bitmask? Again we pay for a full array here. Plus an arbitrary limitation to 5 tags.
Well, I may not know the full story.
I see what you mean and this makes sense, but I would prefer to modify tagset to allow it to be empty and have zero tags. Modifying LogDecorations to deal with something which should be done in LogTagSet just perpetuates the complexity.
Alternatively, you could just add a placeholder tag for "this set has no tags" and we leave the LogTagSet improvement for later.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3135
More information about the hotspot-dev
mailing list