RFR: 8141211: Convert TraceExceptions to Unified Logging
John Rose
john.r.rose at oracle.com
Fri Dec 18 08:43:14 UTC 2015
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
More information about the hotspot-runtime-dev
mailing list