On Fri, 23 Sep 2022 17:08:46 GMT, Johan Sjölen <[email protected]> wrote:
> Here's a suggested solution for the ticket mentioned and a use case for
> outputStream. I'm not attached to the name.
>
> This saves space for all allocated outputStreams, which is nice. It also
> makes the purpose of ResourceObj more clear ("please handle the life cycle
> for me"), reducing the need for it.
>
> Thank you for considering it.
src/hotspot/share/memory/allocation.hpp line 219:
> 217: };
> 218:
> 219: class DynCHeapObj {
I tried this and it seems to work: If you make CHeapObj new operators take
MEMFLAGS f = F, where F is the default value, you could not have this class
and make outputStream inherit from CHeapObj<mtInternal> and the new calls will
override mtInternal. I guess the risk is that you get mtInternal if you forget
the parameter to new.
src/hotspot/share/opto/compile.cpp line 4413:
> 4411: // print_inlining_init is actually called several times.
> 4412: print_inlining_stream_free();
> 4413: _print_inlining_stream = new (mtCompiler) stringStream();
These now need a delete (which is good because it doesn't need an explicit
destructor call).
-------------
PR: https://git.openjdk.org/jdk/pull/10412
