RFR: 8256256: UL should not use heap allocation for output string

[Thomas Stuefe]

On Tue, 17 Nov 2020 07:43:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Yumin,
>> 
>> Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this).
>> 
>> I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation.
>> 
>> David
>
> Hi Yumin, thanks for doing this! 
> 
> @dholmes-ora : I think doing this makes a lot of sense. UL is way too vulnerable against circularities.
> 
> Notes:
> 
> - I agree that truncation or large stack buffers are not ideal. Alternatives could be:
>   - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities.
>   - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread.
> 
> Long or even mid term I believe we will separate loggers from writing to the file and make logging sites as quick and "shallow" as possible. This idea has been floating around a lot. That would relegate anything expensive and potentially dangerous to an own writer thread. I have a rough sketch of such a solution - in such a solution we would write to some global memory area which the writer thread would drain, so there is no reason to allocate at a logging site.
> 
> Cheers, Thomas

> 
> > - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities.
> 
> That seems like a better solution at the expense that UL will not be
> tracked by NMT.
> 
> > - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread.
> 
> Not quite sure what you mean by this.

Oh, just allocate a static buffer - large enough for longish lines - beforehand. Can be done with C-Heap allocation since here we don't live on the stack. That buffer must be kept thread local since multiple threads can log at the same time.

(While writing this, I believe using ::malloc/::free would probably be simplest.)

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/1246