On Tue, 16 Jul 2024 12:36:08 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Remove try_read
>> - Add explicit to single parameter constructors
>> - Remove superfluous access specifier
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Fri, 12 Jul 2024 15:32:45 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 58:
>
>> 56:
>> 57: //
>>
On Tue, 23 Jul 2024 20:21:05 GMT, Coleen Phillimore wrote:
>> Only legacy locking uses the displaced header, I believe, which isn't clear
>> in this code at all. This seems like a fix. We should probably assert that
>> only legacy locking uses this field as a displaced header.
>
> Update: yes
On Tue, 23 Jul 2024 13:19:02 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62:
>>
>>> 60: class ObjectMonitorWorld : public CHeapObj {
>>> 61: struct Config {
>>> 62: using Value = ObjectMonitor*;
>>
>> Does this alias really help? We don't st
On Tue, 23 Jul 2024 16:36:18 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102:
>>
>>> 100: assert(*value != nullptr, "must be");
>>> 101: return (*value)->object_is_cleared();
>>> 102: }
>>
>> The `is_dead` functions seem oddly plac
On Tue, 23 Jul 2024 14:27:34 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105:
>>
>>> 103: };
>>> 104:
>>> 105: class LookupMonitor : public StackObj {
>>
>> I'm not understanding why we need this little wrapper class.
>
> It's a two way looku
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Mon, 12 Aug 2024 18:55:41 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing DEBUG_ONLY
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
>
>> 339: };
>> 34
On Mon, 12 Aug 2024 14:37:50 GMT, Axel Boldt-Christmas
wrote:
>> This is a really good suggestion and might help a lot with the performance
>> problems that we see with the table with heavily contended locking. I think
>> we should change this in a follow-on patch (which I'll work on).
>
> I
On Tue, 13 Aug 2024 14:52:03 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 12:57:23 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674:
>>
>>> 672:
>>> 673: // Search for obj in cache.
>>> 674: bind(loop);
>>
>> Same loop transformation would be possible here.
>
> I tried the following (see diff
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Tue, 13 Aug 2024 01:16:45 GMT, David Holmes wrote:
>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>>
>> `MEMFLAGS` implies that we can use more than one at the same time, but those
>> are exclusive values, so `MemType` is much more suitable name.
>>
>> There is a bu
Hi all,
This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681)
enabling support for timestamp expansion in filenames specified in
`-XX:HeapDumpPath` using `%t`.
As mentioned in this comments for this issue, this is somewhat related to
[8334492](https://bugs.openjdk.org/brow
On Tue, 13 Aug 2024 15:07:17 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681)
> enabling support for timestamp expansion in filenames specified in
> `-XX:HeapDumpPath` using `%t`.
>
> As mentioned in this comments for t
On Mon, 12 Aug 2024 21:35:49 GMT, Chris Plummer wrote:
>> JVMTI has a somewhat unique event called DataDumpRequest. One way it is
>> triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the
>> DataDumpRequest event to all agents that have registered for the event
>> callback.
On Mon, 12 Aug 2024 21:35:49 GMT, Chris Plummer wrote:
>> JVMTI has a somewhat unique event called DataDumpRequest. One way it is
>> triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the
>> DataDumpRequest event to all agents that have registered for the event
>> callback.
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 12 Aug 2024 15:58:14 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 16:49:42 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
On Mon, 15 Jul 2024 00:45:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401:
>>
>>> 399:
>>> 400: if (inserted) {
>>> 401: // Hopefully the performance counters are allocated on distinct
>>
>> It doesn't look like the counters are on d
On Tue, 13 Aug 2024 14:52:03 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 14:56:32 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> src/h
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
> JVMTI has a somewhat unique event called DataDumpRequest. One way it is
> triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the
> DataDumpRequest event to all agents that have registered for the event
> callback. The agent is free to do pretty much what it wants during the
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Mon, 12 Aug 2024 22:40:06 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing DEBUG_ONLY
>
> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 632:
>
>> 630:
On Tue, 13 Aug 2024 16:34:17 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
On Tue, 13 Aug 2024 17:05:38 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> sr
On Tue, 13 Aug 2024 16:30:01 GMT, Gerard Ziemski wrote:
> Is everyone OK with MemTypeFlag?
It's quite unfortunate to have a three-word type for something this prolific in
our code base. Why not go with `MemType` and change variable names from `flag`
to `mt`?
static char* map_memory_to_file
34 matches
Mail list logo
