On Dec 18, 2015, at 12:35 AM, Thomas Stüfe <thomas.stu...@gmail.com> wrote: > > Neither advantage nor disadvantage: you keep the TLS-anchored buffer around. > This is nice because next time you log you save an allocation call, but needs > to be managed to not be a memory drain. For instance, in > commit_multiline_message() the buffer should be cut back to certain maximum > size. > > I am unsure which approach I find better - the one where the caller creates > an explicit buffer or the one where the logging system manages the buffer. > Any would be fine for us.
The approaches can be combined: Require the user to link the transaction together explicitly (in my example) but allow the transaction object (LogBuffer) to reuse a stashed thread-local buffer. Actually, for HotSpot, it's likely that a thread-local ResourceArea would often be the best fit, since blocks in those are cheap to allocate and free. I view the implicit addressing of the transaction buffer (in your code) as a special disadvantage, because it forces all log calls to check foir a thread-local condition (running transaction). That's probably what you meant by forcing everybody to pay the cost for the feature. The UL code is a veritable hive of templatery. A few more templates will give us a static distinction between log channels that are stateless and those which buffer, with little or no apparent difference to the user. — John
