On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen 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
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen 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
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen 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
> 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
> 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
On Thu, 29 Sep 2022 08:50:11 GMT, Johan Sjölen wrote:
>> src/hotspot/share/opto/compile.hpp line 1064:
>>
>>> 1062: delete _print_inlining_stream;
>>> 1063: };
>>> 1064:
>>
>> compile.cpp has print_inlining_stream_free() calls which will leak the
>> stringStream now if called. I think
On Mon, 3 Oct 2022 13:37:25 GMT, Johan Sjölen 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
On Mon, 3 Oct 2022 13:02:51 GMT, Johan Sjölen 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
> 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
> 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
On Wed, 28 Sep 2022 13:41:06 GMT, Johan Sjölen wrote:
>> Or you could have the class that requires dynamic mtFlag be declared with
>> mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually
>> that assert might already be there. Can't really puzzle out what Kim's
>> change
On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sjölen 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 mor
On Wed, 28 Sep 2022 18:21:09 GMT, Coleen Phillimore wrote:
>> Johan Sjölen has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Introduce new, invalid, memory flag
>> - delete _print_inlining_stream
>> - Merge r
On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sjölen 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 mor
On Mon, 26 Sep 2022 15:34:29 GMT, Coleen Phillimore wrote:
>> We can eliminate this problem:
>> "I guess the risk is that you get mtInternal if you forget the parameter to
>> new."
>>
>> We can instead have CHeapObj that *only* allocates with mtFoo, and
>> CHeapObj<> that *requires* specifying
> 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
On Mon, 26 Sep 2022 10:13:18 GMT, Kim Barrett wrote:
>> Good idea! I implemented this instead.
>
> We can eliminate this problem:
> "I guess the risk is that you get mtInternal if you forget the parameter to
> new."
>
> We can instead have CHeapObj that *only* allocates with mtFoo, and
> CHeapO
On Sat, 24 Sep 2022 09:47:38 GMT, Johan Sjölen wrote:
>> 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, y
On Fri, 23 Sep 2022 19:53:56 GMT, Coleen Phillimore wrote:
>> Johan Sjölen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Try out Coleen's suggestion
>
> src/hotspot/share/memory/allocation.hpp line 219:
>
>> 217: };
>> 218:
>> 219: c
> 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
On Fri, 23 Sep 2022 17:08:46 GMT, Johan Sjölen 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 cle
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
22 matches
Mail list logo
