On Thu, 15 Aug 2024 06:07:49 GMT, Stefan Karlsson wrote:
> What is a Native Memory Tracker Type Flag?
It is a flag telling us the type of native memory being tracked.
> Whatever we choose we also need to consider the mt prefix of things like
> mtGC, mtClass, etc.
And what does that stand for:
On Wed, 14 Aug 2024 21:02:47 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use jdk.test.lib.Utils.getRandomInstance()
>
> src/hotspot/share/runtime/synchronizer.hpp line 126:
>
> 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 Thu, 15 Aug 2024 01:35:29 GMT, David Holmes wrote:
> I agree with @tstuefe here. MemFlag and MemType sound far too general when
> this is NMT specific.
Yes, it is not very specific, but it also not hard to learn and then know what
this type is all about.
> My preference to keep the "flags"
On Wed, 14 Aug 2024 20:58:24 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
>>
>>> 339:
>>> 340: ObjectMonitor*
>>> LightweightSynchronizer::get_or_insert_monitor_from_table(oop object,
>>> JavaThread* current, bool* inserted) {
>>> 341:
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski 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 bunch o
On Tue, 13 Aug 2024 17:24:19 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 Wed, 14 Aug 2024 09:24:34 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 22:28:10 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 Sat, 27 Jul 2024 02:12:33 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. The
On Tue, 13 Aug 2024 22:28:10 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 21:18:04 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> git rid of unnecessary @build
>
> Looks good.
@sspitsyn or @lmesnik I need a final review since I made a minor cod
On Tue, 13 Aug 2024 22:28:10 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.
I am out sick after JVMLS, typical post conference flu. There is no need to
rush this, right?
I really dislike MemType for its very genericness. MEMFLAGS is a handle
into the NMT subsystem. It has no meaning beyond NMT. Yet, it is spread all
over the code base. Therefore I really would like an NMT
On Wed, 14 Aug 2024 06:54:22 GMT, Stefan Karlsson 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
On Wed, 14 Aug 2024 09:35:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/vframe.cpp line 252:
>>
>>> 250: if (mark.has_monitor()) {
>>> 251: ObjectMonitor* mon =
>>> ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>>> 252:
On Fri, 9 Aug 2024 19:25:29 GMT, Erik Gahlin wrote:
>> Thanks, yes should have made this clearer and yes will follow up on the
>> additional commands, we should transition them to the same language.
>
> JFR.dump, JFR.start, and JFR.stop are written in Java and have separated from
> the Hotspot
On Tue, 13 Aug 2024 21:56:29 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/vframe.cpp line 252:
>
>> 250: if (mark.ha
> 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 16:03:16 GMT, Roman Kennke wrote:
>> I tried the following (see diff below) and it shows about a 5-10% regression
>> in most the `LockUnlock.testInflated*` micros. Also tried with just
>> `num_unrolled = 1` saw the same regression. Maybe there was some other
>> pattern you
On Wed, 14 Aug 2024 05:45:27 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 84:
>
>> 82:
>> 83: if (
> 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 21:45:57 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/synchronizer.cpp line 1271:
>
>> 1269: _no_pro
On Tue, 13 Aug 2024 21:05:29 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 18:13:30 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
25 matches
Mail list logo
