> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. That overloading causes massive problems with Lilliput, bec
On Fri, 14 Oct 2022 18:31:24 GMT, Chris Plummer wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading exception.
On Fri, 14 Oct 2022 18:37:03 GMT, Chris Plummer wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading exception.
> There are a few changes we can make to better understand the LingeredApp test
> when it goes wrong:
>
> startAppExactJvmOpts() should not try and call finishApp unless the process
> isAlive, that just creates a misleading exception.
>
> waitAppReady() is really waitAppReadyOrCrashed(), and sh
> There are a few changes we can make to better understand the LingeredApp test
> when it goes wrong:
>
> startAppExactJvmOpts() should not try and call finishApp unless the process
> isAlive, that just creates a misleading exception.
>
> waitAppReady() is really waitAppReadyOrCrashed(), and sh
On Mon, 17 Oct 2022 11:13:55 GMT, Kevin Walls wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading exception.
>
On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test only change which proposes to fix the
> recent intermittent failures in `RmiBootstrapTest` reported in
> https://bugs.openjdk.org/browse/JDK-8030616?
>
> The test has been intermittently failing with
On Mon, 17 Oct 2022 11:29:15 GMT, Kevin Walls wrote:
> ./core.22317 4371398656 bytes
It would be a lot easier to read if this was converted to mb.
-
PR: https://git.openjdk.org/jdk/pull/10613
Failures of the test are usually caused by unexpected frame in the stack.
Also the failures are intermittent, so it makes sense to report more details on
error to simplify analysis.
The fix adds stack trace printing if the test fails
-
Commit messages:
- print stack trace on error
On Mon, 17 Oct 2022 19:04:09 GMT, Chris Plummer wrote:
> > ./core.22317 4371398656 bytes
>
> It would be a lot easier to read if this was converted to mb.
OK yes, I'd like both... 8-)
LingeredApp startup took 3119ms
Check for hs_err_pid/core/mdmp files:
./hs_err_pid14641.log 0mb (181706 bytes)
> There are a few changes we can make to better understand the LingeredApp test
> when it goes wrong:
>
> startAppExactJvmOpts() should not try and call finishApp unless the process
> isAlive, that just creates a misleading exception.
>
> waitAppReady() is really waitAppReadyOrCrashed(), and sh
On Mon, 17 Oct 2022 19:22:26 GMT, Alex Menkov wrote:
> Failures of the test are usually caused by unexpected frame in the stack.
> Also the failures are intermittent, so it makes sense to report more details
> on error to simplify analysis.
> The fix adds stack trace printing if the test fails
On Wed, 5 Oct 2022 22:49:20 GMT, Serguei Spitsyn wrote:
> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
> the target thread to be suspended. If not suspended then the
> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the implementation.
>
> The CSR is: h
On Mon, 17 Oct 2022 19:22:26 GMT, Alex Menkov wrote:
> Failures of the test are usually caused by unexpected frame in the stack.
> Also the failures are intermittent, so it makes sense to report more details
> on error to simplify analysis.
> The fix adds stack trace printing if the test fails
On Tue, 18 Oct 2022 00:06:57 GMT, Serguei Spitsyn wrote:
>> Failures of the test are usually caused by unexpected frame in the stack.
>> Also the failures are intermittent, so it makes sense to report more details
>> on error to simplify analysis.
>> The fix adds stack trace printing if the test
The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the JVM
TI ObjectFree events.
The JVM TI ObjectFree events are flushed when the JVM TI
SetEvenNotificationMode is used to disable the ObjectFree events. It is not
very helpful for JDWP agent as the ObjectFree events are alway
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Tue, 18 Oct 2022 02:23:12 GMT, David Holmes wrote:
> The agent will be racing against VM termination and will need to be
> resilient to potentially getting "wrong phase" errors, or similar.
I'm not sure what you mean.
There is always this kind of race but this fix does not make it worse.
The
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Tue, 18 Oct 2022 02:39:11 GMT, Serguei Spitsyn wrote:
> There is always this kind of race but this fix does not make it any worse.
Before this fix events were not getting flushed so at VM exit the agent was
idle with respect to those events and the test failed because events were
missing. N
On Tue, 18 Oct 2022 04:18:33 GMT, David Holmes wrote:
> Do you mean that before the flush operation returns all events are guaranteed
> to have been processed?
Exactly. And it happens before the VMDeath event is posted.
-
PR: https://git.openjdk.org/jdk/pull/10736
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Mon, 17 Oct 2022 20:16:49 GMT, Kevin Walls wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading exception.
>
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
26 matches
Mail list logo
