> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn has updated the pull re
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn has updated the pull re
On Thu, 22 Aug 2024 18:36:39 GMT, Simon Tooke wrote:
> This PR changes the status of realpath() from a Posix-specific API to a
> globally available API, i.e. adding it to the "Hotspot Porting API". Code
> would refer to os::realpath() instead of os::Posix::realpath().
>
> This requires a Wind
On Wed, 16 Oct 2024 13:42:42 GMT, Roman Kennke wrote:
>> We're seeing failures in our nightly testing for tests
>> runtime/cds/appcds/SharedBaseAddress.java and
>> runtime/cds/SharedBaseAddress.java which I'm tracking in this bug
>> [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>>
On Wed, 16 Oct 2024 13:17:48 GMT, Simon Tooke wrote:
>> This PR changes the status of realpath() from a Posix-specific API to a
>> globally available API, i.e. adding it to the "Hotspot Porting API". Code
>> would refer to os::realpath() instead of os::Posix::realpath().
>>
>> This requires a
On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls wrote:
> This test has been "skipping" since IIOP was removed (jdk 9). Should be
> removed, no impact.
This pull request has now been integrated.
Changeset: 8862ca07
Author:Kevin Walls
URL:
https://git.openjdk.org/jdk/commit/8862ca076f
On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls wrote:
> This test has been "skipping" since IIOP was removed (jdk 9). Should be
> removed, no impact.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/21534#issuecomment-2418837171
On Wed, 16 Oct 2024 10:30:48 GMT, Ramkumar Sunderbabu
wrote:
>> Passing "-Xmx1g -Xcomp" to the LingeredApp.
>> Testing: tier1
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one
> additional commit since the last revision:
>
> change othervm to driver, remove -Xmx1g
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Wed, 16 Oct 2024 20:51:49 GMT, Sean Mullan wrote:
>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java
>> line 31:
>>
>>> 29:
>>> 30: /**
>>> 31: * This class is for GSS security context permissions.
>>
>> Why is the content of _this_ class modifie
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Wed, 16 Oct 2024 17:01:38 GMT, Serguei Spitsyn wrote:
>> No issue from me on moving the notifications to the run method. My comment
>> was more for the JvmtiMountTransition's class description as it's not easy
>> to audit the use of this annotation.
>
> Got it, thanks.
The updated changes t
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Thu, 17 Oct 2024 23:17:48 GMT, Serguei Spitsyn wrote:
>> Agreed, thanks.
>> The interesting suspend point is in the `ThreadInVMfromJava()` destructor
>> that is a part of the `JRT_BLOCK` macro. I've pushed the fix now.
>
>> I'm not sure what motivated the change to add old_notify_method. May
On Thu, 17 Oct 2024 20:27:13 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review test tweaks: add @bug tag; a reliability update
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFrame
On Thu, 17 Oct 2024 02:33:01 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Fri, 11 Oct 2024 21:21:57 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 396:
>>
>>> 394: }
>>> 395:
>>> 396: inline bool ShenandoahHeap::is_old(oop obj) const {
>>
>> What is the difference between this method and the above is_in_old()? Why
>>
On Thu, 17 Oct 2024 21:18:23 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp
>> line 171:
>>
>>> 169: } else {
>>> 170: char* old_notify_method = (char*)last_notify_method;
>>> 171: last_notify_method
On Thu, 17 Oct 2024 21:50:39 GMT, Alex Menkov wrote:
>> Yes, this is all very synchronous. The control thread suspends the thread,
>> we call NotifyFramePop on the thread, the control thread resumes the thread
>> and then waits for confirmation of the FRAME_POP before repeating the
>> process.
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Thu, 17 Oct 2024 21:58:18 GMT, Chris Plummer wrote:
>> Control thread waits until pop_count is updated and FramePop callback
>> updates it at the beginning, so control thread can start next iteration
>> (i.e. call SuspentThread) before FramePop is completed.
>> But my understanding that Susp
On Thu, 17 Oct 2024 23:11:22 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Thu, 17 Oct 2024 23:11:34 GMT, Serguei Spitsyn wrote:
>> Actually I'm not so sure of your last statement. I think while in the
>> FramePop callback the thread can do things that allow it to be suspended. So
>> if the control thread has already detected that FramePop callback has been
>> cal
On Thu, 17 Oct 2024 23:14:50 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> no need in raw monitor - removed
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNot
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Thu, 17 Oct 2024 20:08:44 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review test tweaks: add @bug tag; a reliability update
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFrame
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Fri, 18 Oct 2024 00:40:38 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: move pop_count++ to the end of FramePop handler for more safety
>
> test/hotspot/jtreg/serviceability/jvmti
On Fri, 18 Oct 2024 01:11:32 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Fri, 18 Oct 2024 00:28:51 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn has updated the pull re
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request with a new target base due to
a merge or a rebase. The pull request n
On Wed, 16 Oct 2024 18:25:46 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: resolved comments from Alex and Chris
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStress
On Thu, 17 Oct 2024 00:57:12 GMT, Serguei Spitsyn wrote:
>>> Have you verified that the test still detects the bug? In other words, if
>>> you disabled the fix, does the test fail? I was just a bit worried that
>>> with all the changes to it, it might not be still be properly detecting the
>>>
On Thu, 17 Oct 2024 02:33:01 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
> Man page update for jcmd.
>
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and
> substitute PID
>
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.."
> as it is completel
On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu
wrote:
> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1
This pull request has now been integrated.
Changeset: d915ac2a
Author:Ramkumar Sunderbabu
Committer: Leonid Mesnik
URL:
https://git.openjdk.org/jdk/commit/d9
On Tue, 15 Oct 2024 21:26:26 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Thu, 17 Oct 2024 09:16:31 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - M
On Wed, 16 Oct 2024 22:15:05 GMT, Chris Plummer wrote:
>> Kevin Walls 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 three additional
>> commit
On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang wrote:
>> In general, I tried to remove any text from the Permission classes that
>> described behavior if the permissions were granted. So in the above I
>> removed the text because it had words like "protect" and "accessed" and
>> referred to `co
42 matches
Mail list logo
