On Wed, 20 Sep 2023 05:32:07 GMT, David Holmes wrote:
>> Test start failing because of unexpected VM logging.
>> The fix is to search expected string ignoring any unknown output from forked
>> process.
>> Tested with tier1 and by running test with various options used in CI.
>
> test/hotspot/jtr
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Okay - seems reasonabl
On Wed, 20 Sep 2023 05:23:12 GMT, Leonid Mesnik wrote:
> OutputAnalyzer 'firstmatch' method analyze result. It analyze string from
> 'String OutputBuffer getStdout()' and can't be used to communicate with
> process.
Ah I see.
> Something like this was my first fix. Use largeHeapScanner.nextLi
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
OutputAnalyzer 'firstm
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Something like this wa
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Or even use the regula
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Can't you just change
Test start failing because of unexpected VM logging.
The fix is to search expected string ignoring any unknown output from forked
process.
Tested with tier1 and by running test with various options used in CI.
-
Commit messages:
- 8316562: serviceability/sa/jmap-hprof/JMapHProfLarge
On Tue, 19 Sep 2023 23:36:42 GMT, Chris Plummer wrote:
> The only time listenAddr is not set is when using AF_UNSPEC ("system").
@plummercj no it can also be unset if there are no listed addresses for the
preferred family e.g. you prefer v6 but they are all v4, or vice-versa. The new
code mak
On Tue, 19 Sep 2023 22:48:16 GMT, Jonathan Joo wrote:
>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix build issues
Changes requested by dholmes (Revie
On Thu, 3 Aug 2023 08:43:12 GMT, Jean-Philippe Bempel
wrote:
>> Fix a small leak in constant pool merging during retransformation of a
>> class. If this class has a catch block with `Throwable`, the class
>> `Throwable` is pre-resolved in the constant pool, while all the other
>> classes are
On Tue, 19 Sep 2023 23:54:31 GMT, Liam Miller-Cushon wrote:
> > I think Alex has commented that this can be made more obvious with a check
> > for AF_UNSPEC.
>
> Thanks, yes, I have applied that suggestion.
>
> > > For 748, it's handling a situation where IPv4 isn't specifically
> > > preferr
On Tue, 19 Sep 2023 23:36:42 GMT, Chris Plummer wrote:
> I think Alex has commented that this can be made more obvious with a check
> for AF_UNSPEC.
Thanks, yes, I have applied that suggestion.
> > For 748, it's handling a situation where IPv4 isn't specifically preferred.
> > The implementat
On Tue, 19 Sep 2023 05:30:39 GMT, David Holmes wrote:
> Okay I see now that `ai` is not important. We won't have set `listenAddr` so
> we will take the first `addrInfo`. But this seems somewhat random behaviour
> as the first `addrInfo` could be either V4 or V6 (what controls the order?).
> Bu
> Please consider this fix for
> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
> only handled `-Djava.net.preferIPv6Addresses=true` and
> `-Djava.net.preferIPv6Addresses=false`.
Liam Miller-Cu
On Mon, 18 Sep 2023 23:57:33 GMT, Liam Miller-Cushon wrote:
> For 748, it's handling a situation where IPv4 isn't specifically preferred.
> The implementation comment notes 'if preferredAddressFamily is AF_INET6 or
> not set'.
What does "specifically preferred" mean? By default it will be set
On Tue, 19 Sep 2023 23:22:50 GMT, Alex Menkov wrote:
>> Liam Miller-Cushon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix pre-existing typo
>
> 1st pass in attach (line 970) is also not needed, can be something like
>
> -/*
On Tue, 19 Sep 2023 15:41:23 GMT, Liam Miller-Cushon wrote:
>> Please consider this fix for
>> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
>> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
>> only handled `-Djava.net.preferIPv6Addresses=tr
On Tue, 19 Sep 2023 15:41:23 GMT, Liam Miller-Cushon wrote:
>> Please consider this fix for
>> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
>> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
>> only handled `-Djava.net.preferIPv6Addresses=tr
> 8315149: Add hsperf counters for CPU time of internal GC threads
Jonathan Joo has updated the pull request incrementally with one additional
commit since the last revision:
Fix build issues
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15082/files
- new: https://git.op
> 8315149: Add hsperf counters for CPU time of internal GC threads
Jonathan Joo has updated the pull request incrementally with one additional
commit since the last revision:
Fix logic for publishing total cpu time and convert atomic jlong to long
-
Changes:
- all: https://git.
On Tue, 19 Sep 2023 07:28:52 GMT, Axel Boldt-Christmas
wrote:
> All the failing CDS tests pass now. Will rerun a full test suite to be sure.
> (There were two CDS test files that needed to be updated)
[JDK-8293507](https://bugs.openjdk.org/browse/JDK-8293507) is suppose to
address the CDS iss
On Tue, 19 Sep 2023 21:40:18 GMT, Chris Plummer wrote:
> > Similar to @plummercj comment what about this code at L730:
> > ```
> > // Try to find bind address of preferred address family first.
> > for (ai = addrInfo; ai != NULL; ai = ai->ai_next) {
> > if (ai->ai_family == preferredA
On Mon, 18 Sep 2023 23:44:22 GMT, Chris Plummer wrote:
>> Liam Miller-Cushon has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one n
On Tue, 12 Sep 2023 08:21:35 GMT, Matthias Baesken wrote:
> > > So what about FontConfiguration? Is that something using the class
> > > directly too?
> >
> >
> > I think this is not needed either. As far as I can see, the instance of
> > `FontConfiguration` is created from `doPrivileged`, th
Test
com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
check how beans work with VM flags and ignore external flags.
It doesn't make sense to run it with external options so just mark it as
flagless.
Tested with running tier1 and test with/without additional options.
-
Comm
On Mon, 18 Sep 2023 21:36:55 GMT, David Holmes wrote:
>> Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY.
>>
>> This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process.
>
> Looks good. Thanks.
@dholmes-ora, @rkennke, and @stefank - Thanks for the reviews!
On Thu, 7 Sep 2023 01:25:19 GMT, Alex Menkov wrote:
>> To test ForceEarlyReturn command for NO_MORE_FRAMES case the test creates
>> ThreadStartEventRequest with SUSPEND_ALL policy and requests debuggee to
>> start new thread.
>> If debuggee JVM starts some internal threads before the request is
On Fri, 15 Sep 2023 23:18:06 GMT, Leonid Mesnik wrote:
> The test is updated to start the target VM with tested flags in addition to
> heap size.
> Tested with tier1, and iter5/6 rt/svc with CI flags.
This pull request has now been integrated.
Changeset: e0f8d168
Author:Leonid Mesnik
URL:
On Tue, 19 Sep 2023 11:03:36 GMT, Alan Bateman wrote:
>> Liam Miller-Cushon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review feedback
>
> test/jdk/com/sun/jdi/JdwpNetProps.java line 75:
>
>> 73: .run(TestResult
> Please consider this fix for
> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
> only handled `-Djava.net.preferIPv6Addresses=true` and
> `-Djava.net.preferIPv6Addresses=false`.
Liam Miller-Cu
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the f
On Thu, 13 Jul 2023 14:34:38 GMT, Coleen Phillimore wrote:
>> Fix a small leak in constant pool merging during retransformation of a
>> class. If this class has a catch block with `Throwable`, the class
>> `Throwable` is pre-resolved in the constant pool, while all the other
>> classes are in
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the f
Relativize initial_sp in interpreter frames.
By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on PowerPC)
member in interpreter frames from being an absolute address into an offset that
is relative to the frame pointer, we don't need to change the value as we
freeze and thaw
On Tue, 19 Sep 2023 00:03:27 GMT, Liam Miller-Cushon wrote:
>> Please consider this fix for
>> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
>> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
>> only handled `-Djava.net.preferIPv6Addresses=tr
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman wrote:
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
> GetThr
On Mon, 18 Sep 2023 18:54:53 GMT, Chris Plummer wrote:
> In the CR David requested that I still do a CSR to cover the minor jdwp.spec
> changes. I wasn't intending to have the CSR cover the APi note.
Changes to the JDWP spec or JDI API are tracked by CSR. The changes here just
expand rational
On Tue, 19 Sep 2023 10:35:33 GMT, Alan Bateman wrote:
>> Thread::getState is an API for monitoring and management purposes to report
>> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
>> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
>> Ge
> Thread::getState is an API for monitoring and management purposes to report
> the thread state. If a virtual thread is parked with LockSupport.parkNanos,
> its state is reported as WAITING when it should be TIMED_WAITING. JVM TI
> GetThreadState has the same issue in that it returns
> JVMTI_
> ObjectMonitorIterator fails to return the most resent monitor added. It start
> with returning the `nextOM()` ObjectMonitor from the `_head` ObjectMonitor
> but fails to ever return the `_head` ObjectMonitor.
> The current implementation can also not handle that the `_head` is nullptr
> (no mo
On Mon, 18 Sep 2023 12:11:24 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonitor.
>> The current imp
> ObjectMonitorIterator fails to return the most resent monitor added. It start
> with returning the `nextOM()` ObjectMonitor from the `_head` ObjectMonitor
> but fails to ever return the `_head` ObjectMonitor.
> The current implementation can also not handle that the `_head` is nullptr
> (no mo
On Mon, 18 Sep 2023 18:49:43 GMT, Chris Plummer wrote:
> > CDS tests are not happy with changing the class hierarchy of the
> > LingeredApp. Unless it is easily solved for the CDS test I will revert
> > those changes and have the 'TestObjectMonitorIterate' just do a less
> > precise check of a
44 matches
Mail list logo
