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

[Thomas Stuefe]

On Tue, 17 Nov 2020 03:48:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi, Please review
>>   Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated.
>> 
>> Tests: tier1,tier4
>
> 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

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

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