On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes wrote:
> Pre-existing: The initialization logic in this code is quite odd for the case
> when no conversion is necessary (we call `utfInitialize` on every call to
> `convertUtf8ToPlatformString`!), but I assume we do not call
> `appendBootClassPath
On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden wrote:
> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a
> special case for use by the HeapDumper. I propose that we remove this code,
> since this special use case can be solved without the need for the concept of
> "foregro
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
The gist of the issue is that the test case now always creates the boot
classpath with non-ASCII chars appended, because the default encoding is fixed
to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by
nl_langinfo() (in unix/.../Encodin
On Fri, 27 Aug 2021 15:23:35 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
On Thu, 19 Aug 2021 21:18:53 GMT, Leonid Mesnik wrote:
> monitors_iterate make several checks which often are true before filter
> monitor by a thread. It might take a lot of time when there are a lot of
> threads. So it makes sense to first check thread and only then other
> conditions.
I ru
On Thu, 19 Aug 2021 21:18:53 GMT, Leonid Mesnik wrote:
> monitors_iterate make several checks which often are true before filter
> monitor by a thread. It might take a lot of time when there are a lot of
> threads. So it makes sense to first check thread and only then other
> conditions.
This
On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden wrote:
> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a
> special case for use by the HeapDumper. I propose that we remove this code,
> since this special use case can be solved without the need for the concept of
> "foregro
On Wed, 8 Sep 2021 11:40:25 GMT, Leo Korinth wrote:
>> I added a `set_type` method that ensures that the `_thread_last_allocated`
>> always transition over a `STACK_OR_EMBEDDED`. I did *not* create a PUSH/POP
>> macro pair because i believe it would give the false impression that we are
>> doi
On Wed, 8 Sep 2021 11:34:21 GMT, Leo Korinth wrote:
>> src/hotspot/share/memory/allocation.hpp line 439:
>>
>>> 437: void* operator new(size_t size, const std::nothrow_t&
>>> nothrow_constant) throw() {
>>> 438: address res = (address)resource_allocate_bytes(size,
>>> AllocFailStrategy
On Tue, 7 Sep 2021 23:29:10 GMT, Ioi Lam wrote:
>> Leo Korinth has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> First update
>>
>> * Change backing type of ResourceObj::allocation_type to be u8. Also
>> remove no longer needed mask
> The basic problem is that we are relying on undefined behaviour, as
> documented in the code:
>
> // This whole business of passing information from ResourceObj::operator new
> // to the ResourceObj constructor via fields in the "object" is technically
> UB.
> // But it seems to work within th
JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a
special case for use by the HeapDumper. I propose that we remove this code,
since this special use case can be solved without the need for the concept of
"foreground work" in WorkGang.
As far as I can tell, there's no rea
15 matches
Mail list logo
