RFR: 8141211: Convert TraceExceptions to Unified Logging

[John Rose]

On Dec 18, 2015, at 12:35 AM, Thomas Stüfe <thomas.stuefe at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20151218/86350660/attachment-0001.html>