Hi Gary,
Thank you for cosmetic changes.
One thing to notice there is no guard against spurious wakeup for this:
108 Threadissuspended002a.waitnotifyObj.wait();
But I doubt it causes these timeouts as they are very well reproducible.
This time I looked more to the debugger side.
The code is
Hi Alex,
It looks good to me.
Just minor comments.
http://cr.openjdk.java.net/~amenkov/OptionTest_socket/webrev/test/jdk/com/sun/jdi/RunToExit.java.udiff.html
+ // port the debuggee is listening on
+ private static String address;
Local style is to use /**/ comments on class level that start
Hi Coleen,
It looks good to me.
Just a couple of minor comments.
http://cr.openjdk.java.net/~coleenp/2019/8181171.01/webrev/src/java.base/share/classes/jdk/internal/misc/Unsafe.java.udiff.html
+ * Throws NoSuchMethodError; for use by the VM for redefinition support.
+ * @since 1.12
+ */
Repl
Hi Gary,
Double resumed thread2 and suspended main thread is one of the tested
scenarios, and you just dropped it. This doesn't look good.
--alex
On 02/22/2019 11:52, Gary Adams wrote:
After 1000 successful testruns, it seems like a reasonable solution is
to resume the main thread to resolve
Thanks Alex!
I'm not too concerned about future extensions. Also it was even
suggested in a comment in the code to remove the need for at/in. I think
the main reason for supporting named parameters would be to allow them
to occur in any order, which isn't supported now.
Chris
On 2/22/19 4:3
+1 (although I prefer named parameters as unnamed restricts future
syntax extensions).
--alex
On 02/22/2019 15:13, serguei.spit...@oracle.com wrote:
Hi Chris,
It looks good.
Thank you for the update!
Thanks,
Serguei
On 2/22/19 12:24 PM, Chris Plummer wrote:
Please review the updated webre
Hi all,
Please review a fix for
https://bugs.openjdk.java.net/browse/JDK-8181383
webrev:
http://cr.openjdk.java.net/~amenkov/OptionTest_socket/webrev/
The change fixes OptionTest and RunToExit tests to avoid "address
already in use" failures by using dynamic port allocation (address=0).
OptionT
8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
Summary: Add a function to call NSME in ResolvedMethodTable to replace
deleted methods.
This Unsafe.throwX trick is also used for vtable initialization for
throwing IllegalAccessError. Tested with redefinition tests in the
reposit
Thanks!
On 2/22/19 3:13 PM,
serguei.spit...@oracle.com wrote:
Hi Chris,
It looks good.
Thank you for the update!
Thanks,
Serguei
On 2/22/19 12:24 PM, Chris Plummer
wrote:
Hi Chris,
It looks good.
Thank you for the update!
Thanks,
Serguei
On 2/22/19 12:24 PM, Chris Plummer wrote:
Please review the updated webrev:
http://cr.openjdk.java.net/~cjplummer/8219143/webrev.02/index.html
They syntax is now:
stop [go|thread] []
Basically I just removed the
Thanks, Igor!
StefanK
On 2019-02-22 22:02, Igor Ignatyev wrote:
Hi Stefan,
LGTM.
-- Igor
On Feb 22, 2019, at 1:00 PM, Stefan Karlsson wrote:
Hi all,
Please review this patch to ProblemList
serviceability/sa/TestJmapCoreMetaspace.java
https://cr.openjdk.java.net/~stefank/8219571/webrev.
Hi Stefan,
LGTM.
-- Igor
> On Feb 22, 2019, at 1:00 PM, Stefan Karlsson
> wrote:
>
> Hi all,
>
> Please review this patch to ProblemList
> serviceability/sa/TestJmapCoreMetaspace.java
>
> https://cr.openjdk.java.net/~stefank/8219571/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-821
Hi all,
Please review this patch to ProblemList
serviceability/sa/TestJmapCoreMetaspace.java
https://cr.openjdk.java.net/~stefank/8219571/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8219571
Original bug:
https://bugs.openjdk.java.net/browse/JDK-8219443
Thanks,
StefanK
Please review the updated webrev:
http://cr.openjdk.java.net/~cjplummer/8219143/webrev.02/index.html
They syntax is now:
stop [go|thread] []
Basically I just removed the need to specify "threadid" before
.
After 1000 successful testruns, it seems like a reasonable solution is
to resume the main thread to resolve any locks holding back the
thread2 reaching the desired breakpoint.
Updated webrev: http://cr.openjdk.java.net/~gadams/4903717/webrev.01/
Changes in this iteration:
- cosmetic changes
Hi Severin,
Did you manage to make the test pass locally?
This test has had a long history of failing, and I've come
to suspect that it might be flawed.
First - it has /timeout=5. I believe that's much too short.
It immediately failed the first time I ran it locally on my machine.
Then it uses
Apologies. I had two separate threads for this review, and replied on
the thread that no one else replied to, then later saw the thread with
all the activity.
Chris
On 2/22/19 8:48 AM, Chris Plummer wrote:
Looks good.
Chris
On 2/22/19 1:51 AM, Aleksey Shipilev wrote:
Bug:
https://bugs.o
Looks good.
Chris
On 2/22/19 1:51 AM, Aleksey Shipilev wrote:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8219574
Fix:
diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
+++ b/src/hotspot/os/linux/os_linux.cpp Fri
On 2/22/19 2:14 PM, David Holmes wrote:
> On 22/02/2019 11:02 pm, Aleksey Shipilev wrote:
>> On 2/22/19 1:55 PM, Jini George wrote:
>>> Looks good to me. Thanks for taking care of this, Aleksey!
>>
>> No problem. I'll run it through jdk-submit to catch weird failures, and then
>> push.
>
> After
Hi!
Bug: https://bugs.openjdk.java.net/browse/JDK-8219585
Could somebody please review this trivial testbug. For a config like
[1] the logic prior JDK-8145982 returned this list for
getAddressesForLocalHost():
[localhost/127.0.0.1, localhost/192.168.1.18, localhost/0:0:0:0:0:0:0:1]
Post JDK-814
On 22/02/2019 11:02 pm, Aleksey Shipilev wrote:
On 2/22/19 1:55 PM, Jini George wrote:
Looks good to me. Thanks for taking care of this, Aleksey!
No problem. I'll run it through jdk-submit to catch weird failures, and then
push.
After a second review of course.
Reviewed.
Thanks,
David
-
On 2/22/19 1:55 PM, Jini George wrote:
> Looks good to me. Thanks for taking care of this, Aleksey!
No problem. I'll run it through jdk-submit to catch weird failures, and then
push.
-Aleksey
signature.asc
Description: OpenPGP digital signature
Looks good to me. Thanks for taking care of this, Aleksey!
- Jini.
On 2/22/2019 5:56 PM, Aleksey Shipilev wrote:
On 2/22/19 12:19 PM, Jini George wrote:
JDK-8219414 decoupled CDS and DumpPrivateMappingsInCore. Removing the
#INCLUDE_CDS guard from the
definition of ClassLoader::close_jrt_image
On 2/22/19 12:19 PM, Jini George wrote:
> JDK-8219414 decoupled CDS and DumpPrivateMappingsInCore. Removing the
> #INCLUDE_CDS guard from the
> definition of ClassLoader::close_jrt_image() got missed out (My bad! Missed
> that during the review).
> So, since ClassLoader::close_jrt_image() is deco
Hi Aleksey,
JDK-8219414 decoupled CDS and DumpPrivateMappingsInCore. Removing the
#INCLUDE_CDS guard from the definition of ClassLoader::close_jrt_image()
got missed out (My bad! Missed that during the review). So, since
ClassLoader::close_jrt_image() is decoupled from CDS, it might be better
I'll make a pass over the code for cosmetic fixes after the test
is working correctly.
I think the purpose of the lockingObject is to ensure the debugger
has time to enable the breakpoint and perform the double resume
before debuggee thread2 is released to run to the expected breakpoint.
I'm ass
On 22/02/2019 9:12 pm, Aleksey Shipilev wrote:
On 2/22/19 11:48 AM, David Holmes wrote:
diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
+++ b/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 10:51:11 2019 +0100
@@ -1357,11
On 2/22/19 11:48 AM, David Holmes wrote:
>> diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
>> --- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
>> +++ b/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 10:51:11 2019 +0100
>> @@ -1357,11 +1357,11 @@
>> // called from signa
Hi Aleksey,
On 22/02/2019 7:51 pm, Aleksey Shipilev wrote:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8219574
Fix:
diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
+++ b/src/hotspot/os/linux/os_linux.cpp Fri Feb
Bug:
https://bugs.openjdk.java.net/browse/JDK-8219574
Fix:
diff -r e94ed0236046 src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 09:23:37 2019 +0100
+++ b/src/hotspot/os/linux/os_linux.cpp Fri Feb 22 10:51:11 2019 +0100
@@ -1357,11 +1357,11 @@
// called from
30 matches
Mail list logo
