On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang wrote:
>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to
>> capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due
> to a merge or a rebase. The
On Fri, 14 Jun 2024 10:19:47 GMT, Albert Mingkun Yang wrote:
>> Obsolete OldSize and related code. An internal variable `OldSize` is kept to
>> capture the capacity of old-gen size.
>
> Albert Mingkun Yang has updated the pull request with a new target base due
> to a merge or a rebase. The
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
On Mon, 23 Oct 2023 05:25:50 GMT, Thomas Stuefe wrote:
> > The hs_err file includes a dump of the maps file. It seems these
> > annotations would be useful there also.
>
> I thought about this too. The problem is the printing may take long since it
> is O^2 (iterate through VMAs, for each one
On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote:
> The problem is that the following assert in the JvmtiExport::post_object_free
> is wrong:
> ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");`
>
> Even though the condition was checked before, it can be changed later as
On Wed, 15 Jun 2022 12:53:40 GMT, Zhengyu Gu wrote:
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish even
On Thu, 21 Jul 2022 15:31:48 GMT, Chris Plummer wrote:
>>> > The following RN is related to this question:
>>> > https://bugs.openjdk.org/browse/JDK-8256558
>>> > It explicitly says: `SetNotificationMode can be used to explicitly flush
>>> > ObjectFree events, if needed.`
>>>
>>> That wasn't
On Thu, 21 Jul 2022 13:33:01 GMT, Zhengyu Gu wrote:
>> Hi, it was added because some tests were failing. With the concurrent
>> posting, we were missing events and flushing them made the tests pass.
>
>> Hi, it was added because some tests were failing. With the concurrent
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 21 Jul 2022 13:18:25 GMT, Coleen Phillimore wrote:
> Hi, it was added because some tests were failing. With the concurrent
> posting, we were missing events and flushing them made the tests pass.
Thanks, @coleenp
Can you recall what were those tests?
I removed the block and passed
On Wed, 20 Jul 2022 16:53:39 GMT, Serguei Spitsyn wrote:
> get_objects_with_tags
@sspitsyn Good catch!
I believe it should be synchronized if `JvmtiEnv::GetObjectsWithTags()` call
can overlap disable/enable `ObjectFree` event.
But it raises a question: why it needs
On Mon, 18 Jul 2022 23:12:00 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with
On Mon, 18 Jul 2022 20:04:14 GMT, Coleen Phillimore wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix a bug
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1223:
>
>> 122
On Thu, 30 Jun 2022 19:30:54 GMT, Coleen Phillimore wrote:
>> Zhengyu Gu has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
On Mon, 18 Jul 2022 12:41:09 GMT, Zhengyu Gu wrote:
>> In general, the JVMTI fixes look okay to me at the first glance. Will make
>> another pass tomorrow.
>
> @sspitsyn and @coleenp
>
> Could you please review? Thanks!
> @zhengyu123 Yes, I'm lookin
On Fri, 24 Jun 2022 09:08:27 GMT, Serguei Spitsyn wrote:
>> Zhengyu Gu has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 18 addi
On Wed, 13 Jul 2022 01:14:48 GMT, Chris Plummer wrote:
> Ok. Everything is passing after your latest fix.
>
> I think the test still has a synchronization bug, but probably not something
> important enough to worry about, and I'm guessing a lot of tests have this
> issue. The test disables
On Tue, 12 Jul 2022 19:27:16 GMT, Chris Plummer wrote:
> I haven't had a chance to review your change or to understand the sync
> issues, but I did test them out and it seems to have gotten rid of the issue.
> However, there is new assert that turned up once in 75 runs:
>
> ```
> # Internal
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 12 Jul 2022 14:28:18 GMT, Zhengyu Gu wrote:
> > It seems during test shutdown, ObjectFree events are being delivered after
> > JVMTI events have been disabled:
> > ```
> > nsk_jvmti_enableEvents(JVMTI_DISABLE, eventsCount, events, NULL);
> >
> >
On Tue, 12 Jul 2022 06:31:39 GMT, Chris Plummer wrote:
> It seems during test shutdown, ObjectFree events are being delivered after
> JVMTI events have been disabled:
>
> ```
> nsk_jvmti_enableEvents(JVMTI_DISABLE, eventsCount, events, NULL);
>
>
On Tue, 12 Jul 2022 06:31:39 GMT, Chris Plummer wrote:
> post_object_free
-
PR: https://git.openjdk.org/jdk/pull/9168
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request with a new target base due to a merge
or a rebase. The pull request n
On Fri, 1 Jul 2022 18:36:26 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Incorporated plummercj's test changes
>
> test/jdk/com/sun/jdi/TestClassUnloa
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
F
On Thu, 30 Jun 2022 14:54:47 GMT, Zhengyu Gu wrote:
>> I just noticed the test is being added to a newly created
>> hotspot/jtreg/serviciability/jdi directory. It should be placed in one of
>> the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think
&
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last
On Wed, 29 Jun 2022 22:46:30 GMT, Chris Plummer wrote:
> I just noticed the test is being added to a newly created
> hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the
> existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the
> latter would be
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request with a new target base due to a merge
or a rebase. The incremental
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision
On Wed, 29 Jun 2022 22:33:32 GMT, Chris Plummer wrote:
> > > I didn't see any response to my suggested improvements to the test. Can
> > > you please comment on them and update the test if you agree? Thanks.
> >
> >
> > I am still learning JDI and not quite sure how it works. But I think it
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 28 Jun 2022 23:51:20 GMT, Chris Plummer wrote:
> It looks like TestClassUnloadEvents is failing on Windows-x64:
> https://github.com/openjdk/jdk/pull/9168/checks?check_run_id=7102500258
Thanks for pointing out. I could not reproduce locally so far, but continue
debugging it.
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 28 Jun 2022 23:54:20 GMT, Chris Plummer wrote:
> I didn't see any response to my suggested improvements to the test. Can you
> please comment on them and update the test if you agree? Thanks.
I am still learning JDI and not quite sure how it works. But I think it is
unrelated to this
On Mon, 27 Jun 2022 21:28:25 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Renamed eventHandler_synthesizeUnloadEvent
>
> src/jdk.jdwp.agent/share/native/li
On Mon, 27 Jun 2022 20:56:26 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> v5
>
> src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 48:
>
>>
ted after heap walks, but I don't think it
> makes any material material difference.
> Even the events are posted earlier in old code, but they are only processed
> after next GC cycle.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revi
On Fri, 24 Jun 2022 04:11:24 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 18 addi
On Fri, 24 Jun 2022 21:49:00 GMT, Chris Plummer wrote:
> You should also remove the following from the hotspot ProblemList.txt:
>
> `vmTestbase/nsk/jdi/HiddenClass/events/events001.java 8257705 generic-all`
>
> Try to reproduce without your fix, and then verify your fix is addressing the
>
On Mon, 27 Jun 2022 15:50:47 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1200:
>>
>>> 1198: };
>>> 1199:
>>> 1200: // PostObjectFree can't be called by JavaThread, so call it from the
>>> VM thread.
>>
>> I wish I'd written why here. I think it's because we
On Fri, 24 Jun 2022 03:32:13 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 18 addi
On Sat, 25 Jun 2022 05:42:08 GMT, Chris Plummer wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1722:
>>
>>> 1720: if (javaThread->is_in_VTMS_transition()) {
>>> 1721: return; // no events should be posted if thread is in a VTMS
>>> transition
>>> 1722: }
>>
>> Chris suggested
On Fri, 24 Jun 2022 03:42:28 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 18 addi
On Mon, 27 Jun 2022 17:01:02 GMT, Chris Plummer wrote:
>> @sspitsyn Thanks.
>>
>> Yes, `JvmtiTagMap::check_hashmaps_for_heapwalk()` is where I saw the call
>> from `VMThread`.
>>
>> This patch is intended to **not** post `ObjectFree` events on `VMThread`, so
>> I am going to move this PR
and post object free events in one batch
>
> This way, JDI event handler can process object free events upon arrivals
> without delay.
Zhengyu Gu has updated the pull request incrementally with one additional
commit since the last revision:
v5
-
Changes:
- all: htt
On Sat, 25 Jun 2022 01:35:38 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1702:
>>
>>> 1700: } else {
>>> 1701: post_object_free_on_java_thread(env, objects);
>>> 1702: }
>>
>> Can you explain why sometimes it is a VMThread and why sometimes it is a
>>
suggested by @kbarrett, the last pending unloaded class list can be flushed
> by other events, such as `VM_DEATH`.
>
> It also performs `commonRef_compact()` only when there are classes unloaded.
>
> New test failed about 20% without patch, none with patch.
Zhengyu Gu has upd
suggested by @kbarrett, the last pending unloaded class list can be flushed
> by other events, such as `VM_DEATH`.
>
> It also performs `commonRef_compact()` only when there are classes unloaded.
>
> New test failed about 20% without patch, none with patch.
Zhengyu Gu has upd
On Wed, 15 Jun 2022 17:42:42 GMT, Chris Plummer wrote:
> One issue I have with this fix is that is doesn't fix the "delay" issue. It
> helps it, and ensures the CLASS_UNLOAD events are sent before the debuggee
> exits, but it doesn't guarantee that they are sent in a time manner.
>
Yes, it
On Wed, 15 Jun 2022 17:21:25 GMT, Chris Plummer wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that
56 matches
Mail list logo
