JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) #3855
In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index.
Better would be to use a numerical index array of offset values, which could be safely copied.
And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517.
The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected.
The text was updated successfully, but these errors were encountered:
I compare yours and mine using
baseline is synchronized log outputs. custom copy ctor is what I am using in PR#3135.
I acknowledge that copying _decorations_buffer as need is not necessary.
I read this patch and PR #3874. IMHO, I don't think PR #3874 is over this patch in terms of "makes the code easier to understand and read." The change is obviously bigger(+238 −117) than this one. Is it worth it?
To me, the only critical drawback of storing resolved c-string is i18n. As a matter of fact, unified logging doesn't put i18n into consideration, so it is not an issue.
A universal buffer seems cleaner than scatter fields, doesn't it? Reducing size(from 368 -> 56 bytes on Linux x64) is appealing, but it actually has very limited impact on real performance.
I am not a reviewer. Those are all my personal opinions. Take it as a grain of salt. I can go either way.
Be fair, a lot of those lines is added tests, which had not been there before, and added comments, which this code sorely needed. The code size of logDecorations.cpp/hpp is smaller now.
I reduced the patch size somewhat further.
In my opinion no.
Really? It decreases your planned message buffer size, no?
I close this PR now in favor of the other one.
Yes, I am happy to see it reduces the size of each payload. but sometimes smaller memory footprint doesn't change to runtime performance directly. From my measurement, LogDecoration doesn't impact that much.
Check out this performance comparison. I found that copying 20 bytes is almost identical to copying 256 bytes.
Oh sure. But I never claimed this to be performance relevant. Its all about memory.