There are only two implementations of these classes (one for windows, and one
for posix):
- PlatformEvent
- PlatformParker
- PlatformMutex
- PlatformMonitor
- ThreadCrashProtection
Before this PR, these classes are declared in os_xxx.hpp. This causes excessive
inclusion of the large header file
On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review
Looks good.
Just a couple of minor "
On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam wrote:
> This is a follow up to
> [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623).
> `java_lang_VirtualThread` is part of loom and should be move to
> continuationJavaClasses.hpp, which contains the accessors for the other java
> classes us
On Mon, 27 Jun 2022 14:27:37 GMT, Stefan Karlsson wrote:
>>> The _reference_type used to be initialized correctly in most cases, but
>> needed fixing up for a few cases during bootstrapping. With this change it is
>> never initialized correctly for Reference subtypes and always needs an
>> initia
> Simple rename and some comments update.
>
> Test: build
Albert Mingkun Yang has updated the pull request incrementally with one
additional commit since the last revision:
review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/8332/files
- new: https://git.openjdk.org/jd
On Mon, 27 Jun 2022 17:02:04 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 event, that results,
On Mon, 27 Jun 2022 17:49:25 GMT, Zhengyu Gu wrote:
>>> This patch is intended to not post ObjectFree events on VMThread, so I am
>>> going to move this PR back to draft state and take another look.
>>
>> I'm not so sure it matters to the debug agent. I thought the main change
>> here was to n
On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam wrote:
> This is a follow up to
> [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623).
> `java_lang_VirtualThread` is part of loom and should be move to
> continuationJavaClasses.hpp, which contains the accessors for the other java
> classes us
This is a follow up to
[JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623).
`java_lang_VirtualThread` is part of loom and should be move to
continuationJavaClasses.hpp, which contains the accessors for the other java
classes used by loom.
-
Commit messages:
- 8289231: Move
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 additional
>> commits si
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
> fai
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 additional
>> commits si
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 t
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 additional
>> commits si
On Mon, 27 Jun 2022 18:24:18 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java
> when run with vthread wrapper.
This pull request has now been integrated.
Changeset: 28913f47
Author:Daniel D. Dau
On Mon, 27 Jun 2022 11:49:07 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 19 -> JDK 20
This pull request has now been integrated.
Changeset: d4b040f4
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.org/jdk/commit/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182
Stats: 366 lines
> Forwardport JDK 19 -> JDK 20
Jesper Wilhelmsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 146 commits:
- Merge
- 8289126: Cleanup unnecessary null comparison before instanceof check in
jdk.hotspot.agent
Reviewed-by:
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 bac
On Sat, 25 Jun 2022 13:08:30 GMT, Ryan Ernst wrote:
>> Applied required casts in jdk.hotspot.agent for the upcoming warning.
>> Verified by cherry-picking @asotona's patch.
>
> Ryan Ernst has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev exc
> 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 results, sometimes, it
> only captures partial or even empty unload
On Sun, 26 Jun 2022 11:52:28 GMT, Zhengyu Gu wrote:
> This patch is intended to not post ObjectFree events on VMThread, so I am
> going to move this PR back to draft state and take another look.
I'm not so sure it matters to the debug agent. I thought the main change here
was to not force post
On Fri, 24 Jun 2022 12:24:27 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 contains 18 additional
>> commit
On Mon, 27 Jun 2022 14:14:23 GMT, Stefan Karlsson wrote:
>>> The current approach limits the knowledge of non-strong ref types to
>>> `instanceRefKlass` file.
>>
>> The mechanism used to compute the correct reftype is purely derived from the
>> parser, and to me looks like "parsing". So I think
On Fri, 24 Jun 2022 00:15:10 GMT, Kim Barrett wrote:
>> `_reference_type` always gets the correct value after the constructor is
>> run. The member initializer list just follows the convention of having all
>> fields set. One could move this field inside the constructor body to ensure
>> this
On Thu, 9 Jun 2022 19:19:44 GMT, Jayashree Huttanagoudar
wrote:
> This PR is to address :
> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
> Verified the build before and after the patch. Also below tests are run:
> Before Patch:
>
> $ make test TEST="jtreg:test/hot
Forwardport JDK 19 -> JDK 20
-
Commit messages:
- Merge
- 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed
with "RuntimeException: Test failed"
- 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
- 8288983: broken link in com.sun.net.
On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie wrote:
>> When we started introducing some possibly more intrusive compiler flags and
>> functionality for reproducible builds, we also introduced a flag to turn
>> this off out of an abundance of caution. But we have been been using this
>
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nm
On Tue, 21 Jun 2022 13:44:23 GMT, Thomas Stuefe wrote:
>>> > > I would have thought that since we don't have the pool anymore, we can
>>> > > just remove this test line. The lines above already
>>> > > test against MaxMetaspaceSize.
>>> >
>>> >
>>> > Okay.
>>> > > I think you may be right, we
On Fri, 24 Jun 2022 09:19:33 GMT, Andrey Turbanov wrote:
> Update code checks both non-null and instance of a class in jdk.hotspot.agent
> module classes.
> The checks and explicit casts could also be replaced with pattern matching
> for the instanceof operator.
>
> For example, the following
33 matches
Mail list logo
