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

[David Holmes]

On Tue, 17 Nov 2020 16:41:30 GMT, Yumin Qi <minqi 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, @dholmes-ora and @tstuefe
>   Thanks for your review. I came up with this simplest fix with the stack overflow case in concern, but think at that case, the thread will overflow even without using UL log, that is an extreme case, but I do agree 4K is way bigger for it.
>   So next version will keep 512 as the buffer size, and use ::malloc/::free to replace NEW_C_HEAP_ARRAY/FREE_C_HEAP_ARRAY to avoid circularity here. We need manually check OOM here.
>   For the thread local allocation at thread initialization --- we need to check if UL is used, should avoid allocating unused buffer,  but that is in future work. 
>   @dholmes-ora please let me know if you agree continue working on the current issue.
> 
> Thanks
> Yumin

Going with the manual malloc/free approach seems reasonable to me. I don't know if the NMT folk will object to UL not being tracked.
Thanks,
David

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

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