Hi Dmitry,
Thank you very much for the review/ I've changed the CR title.
Waiting for a (R)eviwer to approve this trivial one-line quarantine.
Best regards,
Alexander
- Original Message -
From: dmitry.dmitr...@oracle.com
To: alexander.kulyakh...@oracle.com
Cc:
Hi,
Could you, please, review this trivial change (quarantining a test).
CR: https://bugs.openjdk.java.net/browse/JDK-8168479 "Backout the changes for
JDK-8168478"
Webrev: http://cr.openjdk.java.net/~akulyakh/8168479/
The test is being quarantining due to
, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review these test-only changes
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8166289 "RuntimeException:
> canRead() reports false for reading from the same module: expected true, was
> false"
> Webrev: ht
Hi,
Could you, please, review these test-only changes
CR: https://bugs.openjdk.java.net/browse/JDK-8166289 "RuntimeException:
canRead() reports false for reading from the same module: expected true, was
false"
Webrev: http://cr.openjdk.java.net/~akulyakh/8166289/
The fix restores the changes
, 2016 3:40:37 PM GMT +03:00 Iraq
Subject: Re: RFR: 8158797: Test
java/lang/management/MemoryMXBean/LowMemoryTest.java fails when GC is specified
explicitly
Alexander,
It looks good to me.
Thanks,
Serguei
On 10/13/16 05:37, Alexander Kulyakhtin wrote:
> Dmitry,
>
> Thank you
eed a new webrev for that.
Thanks,
Dmitry
On 10.10.2016 13:51, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this simple, test-only change:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8158797 "Test
> java/lang/management/MemoryMXBean/LowMem
Hi,
Could you, please, review this simple, test-only change:
CR: https://bugs.openjdk.java.net/browse/JDK-8158797 "Test
java/lang/management/MemoryMXBean/LowMemoryTest.java fails when GC is specified
explicitly"
Webrev:
Hi Leonid,
(not a reviewer) Maybe a comment explaining why the metaspace should be eaten
first could be useful?
Otherwise it might be not clear that the order of the methods is important and
the methods can be unintentionally swapped again?
Best regards,
Alexander
- Original Message
dules list.
Thanks,
Serguei
On 9/14/16 03:02, Alexander Kulyakhtin wrote:
Hi,
Could I, please, have some feedback regarding the RFR below?
Best regards,
Alexander
- Original Message -
From: alexander.kulyakh...@oracle.com To: serguei.spit...@oracle.com ,
serviceability-dev@openjdk.j
Hi,
Could I, please, have some feedback regarding the RFR below?
Best regards,
Alexander
- Original Message -
From: alexander.kulyakh...@oracle.com
To: serguei.spit...@oracle.com, serviceability-dev@openjdk.java.net
Sent: Monday, September 12, 2016 3:06:13 PM GMT +03:00 Iraq
Subject:
Hi,
Could you, please, review this test-only change
CR: https://bugs.openjdk.java.net/browse/JDK-8165017 "Additional test coverage
of the JDWP CLASSLOADER and MODULE commands"
Webrev: http://cr.openjdk.java.net/~akulyakh/8165017_03/
The verification of the new JDWP 'MODULE' command has been
and -Dcom.sun.management need to add to the
initial set of modules to resolve
On 09/09/2016 13:07, Alexander Kulyakhtin wrote:
> Hi Mandy,
>
> Thank you very much for the review. I have added @modules java.instrument,
> making no other changes.
> Please, find the updated we
AM, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Hi,
>
> Could you, please, review this test-only change (adding a new test).
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8139368 "-javaagent and
> -Dcom.sun.management need to add to
Hi,
Could you, please, review this test-only change (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8139368 "-javaagent and
-Dcom.sun.management need to add to the initial set of modules to resolve"
Webrev: http://cr.openjdk.java.net/~akulyakh/8139368_03/
Best regards,
Hi,
Could I, please, have some feedback on the RFR below (adding a new test for the
-javaagent option)?
Best regards,
Alexander
- Forwarded Message -
From: alexander.kulyakh...@oracle.com
To: serviceability-dev@openjdk.java.net
Cc: christian.tornqv...@oracle.com,
ssLoader=2 and Module=19 commands.
Thanks,
Serguei
On 8/29/16 05:29, Alexander Kulyakhtin wrote:
Hi Sergey,
Thank you very much for your help. With the changes, as you have proposed, the
test now passes on all configurations.
Please, find the updated webrev at:
http://cr.openjdk.java.net
sed and can be removed (lines
41, 43).
test/serviceability/jdwp/Arch.java
It seems, this file/class is not really needed and can be removed.
test/serviceability/jdwp/JdwpReply.java
Nit: the empty lines 39 and 54 are not needed.
Thanks,
Serguei
On 8/12/16 05:55, Alexander Kulyakhtin wrot
any other reviews yet?
Thanks,
Serguei
On 8/12/16 05:55, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review the following test-only change (adding a new test):
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8148103
> Webrev: http://cr.openjdk.java.net/~akulyakh/
Hi,
Could you, please, review the following test-only change (adding a new test):
CR: https://bugs.openjdk.java.net/browse/JDK-8148103
Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/
The new test verifies the new JDWP commands: AllModules, Module, Name,
ClassLoader, CanRead.
It does
Hi,
Could you, please, review this test-only change (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8139368 "-javaagent and
-Dcom.sun.management need to add to the initial set of modules to resolve"
Webrev: http://cr.openjdk.java.net/~akulyakh/8139368_01/
The new tests starts
as the opening {.
Thanks,
Christian
From: Alexander Kulyakhtin [mailto:alexander.kulyakh...@oracle.com]
Sent: Friday, July 22, 2016 7:40 AM
To: serguei.spit...@oracle.com
Cc: christian.tornqv...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify
les loaded/defined, the Layer.defineModules
is part of the official Java API and is one of them. It doesn’t matter to JVMTI
if they come from JAR files on disk or if they’re defined using a Java API, so
I suggest you go with Layer.defineModules.
Thanks,
Christian
From: Alexander Kulyakh
he Layer.defineModules
is part of the official Java API and is one of them. It doesn’t matter to JVMTI
if they come from JAR files on disk or if they’re defined using a Java API, so
I suggest you go with Layer.defineModules.
Thanks,
Christian
From: Alexander Kulyakhtin [ mailto:alexan
ModulesInfo.java
module-info.java
Thanks,
Christian
From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net]
On Behalf Of serguei.spit...@oracle.com
Sent: Monday, May 2, 2016 6:06 PM
To: Alexander Kulyakhtin <alexander.kulyakh...@oracle.com>; Serviceabil
Sergey,
Could you, please, re-review the new test you have already reviewed and
approved before.
I had to change Module.empty() to Module.of() due to the changes in the APIs.
Otherwise the test is the same as before.
CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify
]
On Behalf Of serguei.spit...@oracle.com
Sent: Friday, June 17, 2016 7:39 PM
To: Alexander Kulyakhtin <alexander.kulyakh...@oracle.com>
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the
JVMTI
Hi Alexander,
I'm c
,
Serguei
On 5/5/16 04:25, Alexander Kulyakhtin wrote:
Sergey,
Thank you very much for the review.
I will be pushing the fix as soon as jtreg 4.2 is out, since 4.2 has the fix
for CODETOOLS-7901662, required for this test.
Best regards,
Alexander
From: serguei.spit...@oracle.com
Hi Dmitry,
With this change we are not launching jmap anymore, launching jhsdb instead.
I just wanted to make sure if it is ok not to test jmap anymore?
Perhaps, instead of changing we should make the test to test both ?
Best regards,
Alexander
- Original Message -
From:
Hi Kirill,
(I'm not a reviewer)
Is there a specification of what shall be thrown, or the justification of the
changes done?
One can think that the currently thrown NoSuchMethodException is correct since
methods, which differ in signature only, are still different methods.
Best regards,
, Alexander Kulyakhtin wrote:
Hi Sergey,
Thank you very much for the review.
Please, find the updated webrev with your findings corrected at:
http://cr.openjdk.java.net/~akulyakh/8153978_02/index.html
Best regards,
Alexander
- Original Message -
From: serguei.spit...@oracle.com
compareExcludingUnnamed(ModulesInfo other) {
I'd suggest to call it compareNamed.
Otherwise, the new test looks great.
Thanks a lot for taking care about it!
Thanks,
Serguei
On 4/29/16 06:12, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review these test-only changes (adding a new test).
CR
Hi,
Could you, please, review these test-only changes (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the
modules info as returned by the JVMTI"
Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/
The new test verifies that JVMTI returns the
> On Apr 21, 2016, at 5:23 AM, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Mandy,
>
> Thank you very much for your review.
>
> I have updated the fix per your comments, making ProcessTools.getProcessId()
> return long.
>
&
Hi,
Could you, please, review this small tests-only fix:
CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on
compact2 due to an unnecessary test library dependency"
Webrev:
On 4/6/16 02:56, Alexander Kulyakhtin wrote:
> Alan,
>
> What would be, the most suitable location for the test? I'm going to make
> sure this new test does not duplicate any existing one and, if not, will
> change the patch accordingly then.
>
> Best regards,
> Alexan
...@oracle.com, serviceability-dev@openjdk.java.net
Sent: Wednesday, April 6, 2016 12:51:44 PM GMT +03:00 Iraq
Subject: Re: RFR:8153584:New jtreg test to verify
PathSearchingVirutalMachine.bootClassPath() behaviour
On 06/04/2016 10:46, Alexander Kulyakhtin wrote:
> Hi,
>
> Could yo
Hi,
Could you, please, review, the following test-only changes (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify
PathSearchingVirutalMachine.bootClassPath() behaviour"
Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/
The new test verifies
Hi Cheleswer,
I doubt Thread.sleep() can ensure a program state. As Philip has pointed out,
some synchronization object would, probably, be more appropriate.
+// Ensuring that Jstack will always run after NamedThread is started +
Thread.sleep(2000);
Best regards,
Alexander
Hi,
Could you, please, review this trivial, test-only change (enabling a previously
excluded test)
Webrev:
http://cr.openjdk.java.net/~akulyakh/8147987/test/ProblemList.txt.udiff.html
CR: https://bugs.openjdk.java.net/browse/JDK-8147987 "Remove
/sun/jdi tests fail on Cygwin
but pass on MKS
Yes, it is a fix for JDK 8u only.
-Konstantin
On 02/19/2016 05:47 PM, Alexander Kulyakhtin wrote:
> Hi Konstantin,
>
> (not a reviewer)
>
> Could you, please, explain your fix a bit more, if possible?
> Since the comment to t
Hi Konstantin,
(not a reviewer)
Could you, please, explain your fix a bit more, if possible?
Since the comment to the CR says "Cannot be reproduced with JDK 9.", is this
fix for JDK 8 only?
Best regards,
Alexander
- Original Message -
From: konstantin.she...@oracle.com
To:
Hi,
Could you, please, review this trivial test-only change (quarantining the test):
CR: https://bugs.openjdk.java.net/browse/JDK-8150067
Webrev:
http://cr.openjdk.java.net/~akulyakh/8150067/test/serviceability/tmtools/jstat/GcCapacityTest.java.udiff.html
The test needs to be quarantined until
Hi,
Could I, please, have any feedback on this trivial tests-only review?
Best regards,
Alexander
- Forwarded Message -
From: alexander.kulyakh...@oracle.com
To: serviceability-dev@openjdk.java.net
Sent: Wednesday, February 3, 2016 2:21:44 PM GMT +03:00 Iraq
Subject: RFR:8147847:
Hi,
Could you, please, re-review the following tests-only fix:
CR: https://bugs.openjdk.java.net/browse/JDK-8147847
"serviceability/tmtools/jstat tests are failing with
-XX:+ExplicitGCInvokesConcurrent"
Webrev: http://cr.openjdk.java.net/~akulyakh/8147847_2/index.html
In addition to disabling
Hi,
Could you, please, review this trivial tests-only fix:
CR: https://bugs.openjdk.java.net/browse/JDK-8147847
"serviceability/tmtools/jstat tests are failing with
-XX:+ExplicitGCInvokesConcurrent"
Webrev: http://cr.openjdk.java.net/~akulyakh/8147847/index.html
The changed tests compare the
> On 28 jan. 2016, at 11:20, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Hi Staffan,
>
> I've changed the test fix for
> https://bugs.openjdk.java.net/browse/JDK-8147447
> "serviceability/tmtools/jstack/WaitNotifyThreadTest
y 21, 2016 7:35:46 PM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8147447: [TESTBUG]
serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails
> On 21 jan. 2016, at 16:52, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Dan,
>
> Thank you
/jstack/WaitNotifyThreadTest.java test fails
> On 21 jan. 2016, at 16:52, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Dan,
>
> Thank you very much for your help.
>
> I'm then going to modify the test accordingly.
> In the -Xmixed mode the
a better way to check if compiled mode is being used. Perhaps
System.getProperty("java.vm.info").contains("compiled”) ?
/Staffan
> On 19 jan. 2016, at 11:59, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Hi,
>
> Could you, ple
test fails
On 1/21/16 8:11 AM, Staffan Larsen wrote:
>> On 21 jan. 2016, at 15:33, Alexander Kulyakhtin
>> <alexander.kulyakh...@oracle.com> wrote:
>>
>> Staffan,
>>
>> Would it be sufficient to modify the code so that isCompMode() returns true
>
Hi,
Could you, please, review this quarantine request:
CR: https://bugs.openjdk.java.net/browse/JDK-8147848
"https://bugs.openjdk.java.net/browse/JDK-8147848;
Webrev: http://cr.openjdk.java.net/~akulyakh/8147848/index.html
The 3 tests need to be quarantined until the root cause of the failures
Hi,
Could you, please, review this minor test-only change
CR: https://bugs.openjdk.java.net/browse/JDK-8147447 "[TESTBUG]
serviceability/tmtools/jstack/WaitNotifyThreadTest.java test fails"
Webrev: http://cr.openjdk.java.net/~akulyakh/8147447/index.html
The test WaitNotifyThreadTest.java tries
Hi,
Could you, please, review this trivial test-only change:
CR: https://bugs.openjdk.java.net/browse/JDK-8147609 "Correct the @build
statements in the serviceability/dcmd/gc/HeapDumpAllTest.java and
HeapDumpTest.java tests"
Webrev: http://cr.openjdk.java.net/~akulyakh/8147609/index.html
The
Subject: Re: RFR: 8147609: Correct the @build statements in the
serviceability/dcmd/gc/HeapDumpAllTest.java and HeapDumpTest.java tests
On 19.1.2016 16:32, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this trivial test-only change:
>
> CR: https://bugs.openjdk.java
, 2016 7:30:08 PM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8130063: Refactoring tmtools jstat and jstack tests to
jtreg
Hi Alexander,
On 12.1.2016 15:22, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review the following test-only change
>
> CR: https://bugs.openjdk.java
Hi,
Could you, please, review the following test-only change
CR: https://bugs.openjdk.java.net/browse/JDK-8130063 "Refactoring tmtools jstat
and jstack tests to jtreg"
WebRev: http://cr.openjdk.java.net/~akulyakh/8130063_01/
Before the change we had a set of tests verifying the correctness of
Hi,
Could you, please, review this small test-only fix:
CR: https://bugs.openjdk.java.net/browse/JDK-8145408
"com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found"
Webrev:
http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html
The
: "com/sun/jdi/BreakpointWithFullGC.sh: Required
output "Full GC" not found"
On 16.12.2015 13:05, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this small test-only fix:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8145408
> "co
his will help anyone backporting test fixes to older releases.
Dan
On 12/16/15 5:05 AM, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this small test-only fix:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8145408
> "com/sun/jdi/BreakpointWithFullGC.sh: Re
on can never go through.
I would suggest retrying only once (or retrying a fixed number
of times) - and possibly introducing a small delay (Thread.sleep)
before retrying.
best regards,
-- daniel
On 23/11/15 12:19, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review this small, tes
conditions/platform where the test was observed failing?
best regards,
-- daniel
On 24/11/15 13:58, Alexander Kulyakhtin wrote:
> Hi,
>
> Following the finding from Martin, I have changed the delay before the
> retry to 10 ms
>
> Webrev:
> http://cr.openjdk.java.net/~aku
3 seconds sounds like an awfully long time between retries. I'd guess that 10ms
would be sufficient most of the time for other threads to get around to doing
something, and 100ms for other Java processes.
On Mon, Nov 23, 2015 at 7:00 AM, Alexander Kulyakhtin <
alexander.kulyakh...@oracle.
Hi,
Could you, please, review this small, test-only, change:
CR: https://bugs.openjdk.java.net/browse/JDK-8143121
Webrev:
http://cr.openjdk.java.net/~akulyakh/8143121/test/javax/management/remote/mandatory/loading/MethodResultTest.java.udiff.html
The precondition for this test is a
once (or retrying a fixed number
of times) - and possibly introducing a small delay (Thread.sleep)
before retrying.
best regards,
-- daniel
On 23/11/15 12:19, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this small, test-only, change:
>
> CR: https://bugs.openjdk.
)
before retrying.
best regards,
-- daniel
On 23/11/15 12:19, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this small, test-only, change:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8143121
> Webrev:
> http://cr.openjdk.java.net/~akulyakh/8143121/test/ja
fails
intermittently
Hi Alexander,
On 23/11/15 13:09, Alexander Kulyakhtin wrote:
> Hi Daniel,
>
> Thank you very much for the review.
>
> I presumed that in such case the jtreg will terminate the test by timeout and
> so I wanted to avoid any specific delays and counters.
On 9.11.2015 19:07, Alexander Kulyakhtin wrote:
> Hi,
>
> Following the comments from Jaroslav and Martin I've changed the test
> to use the unbound CountDownLatch.await()
>
> Since await() will wait undefinitely and thus the test, if fails, will
> now fail by timeout only the code
in com.sun.jmx.remote.internal.ClientNotifForwarder
Line 829:
synchronized (ClientNotifForwarder.this) {
if (state == STARTED) {
executor.execute(new NotifFetcher());
}
}
Thanks to work on this issue.
Shanliang
On 10 Nov 2015, at 12:36, Alexander Kulyakhtin <
alexander.kulyakh...@oracle.com > wrote
Hi,
Could you, please, review this test-only fix:
CR: https://bugs.openjdk.java.net/browse/JDK-8141591
Webrev:
http://cr.openjdk.java.net/~akulyakh/8141591_01/test/javax/management/remote/mandatory/threads/ExecutorTest.java.udiff.html
Before the fix, it was possible that we shut down the
/ExecutorTest.java fails intermittently
Hi Alexander,
On 9.11.2015 16:40, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this test-only fix:
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8141591
> Webrev:
> http://cr.openjdk.java.net/~akulyakh/8141591_01/
Subject: Re: RFR 8134641: serviceability/dcmd/compiler/CodelistTest.java fails
on sun.misc.Unsafe.getUnsafe
Looks good, not a (R)eviewer.
Erik
Den 09/09/15 kl. 12:54, skrev Alexander Kulyakhtin:
> Hi,
>
> Could someone, please, review the small, test-only fix in the mail below?
>
&g
Could you, please, review the following small test-only change:
Issue: https://bugs.openjdk.java.net/browse/JDK-8134641
"serviceability/dcmd/compiler/CodelistTest.java fails with "Test failed on:
sun.misc.Unsafe.getUnsafe()Lsun/misc/Unsafe;"
Webrev:
The fix has been updated to make sure that strings matching
"sun.misc.Unsafe.getUnsafe", and not simply "getUnsafe" get filtered
Webrev: http://cr.openjdk.java.net/~akulyakh/8134641_01/index.html
Best regards,
Alexander
- Original Message -
From: alexander.kulyakh...@oracle.com
To:
Hi,
Could you, please, review the following small test-only fix:
CR: JDK-8130527 Serviceability tests fails with Can't attach to process. (the
CR was submitted as confidential for other reasons, all changes are in the
public domain)
Webrev:
with this change.
However, I think it would be better to open a new issue for the code
cleanup and not use the nightly-failure related one - especially since
the change would not be really fixing the failure.
Thanks,
-JB-
On 17.7.2015 13:13, Alexander Kulyakhtin wrote:
Hi,
Can the changes
, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review these simple test-only changes:
CR: https://bugs.openjdk.java.net/browse/JDK-8114828 wrong class file error
when compiling tests
(All the changed files belong to the Open JDK. Since the CR was submitted as
confidential, the issue
in hotspot-dev as there's a meta-question here
Hi Alexander,
On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review these simple test-only changes:
CR: https://bugs.openjdk.java.net/browse/JDK-8114828 wrong class file error
when compiling tests
(All the changed files
to extend the
default security policy instead of override
Looks good!
-JB-
On 16.6.2015 14:29, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review the small test-only changes below:
CR: https://bugs.openjdk.java.net/browse/JDK-8062045 Update svc regression
tests to extend the default
Hi,
Could you, please, review the small test-only changes below:
CR: https://bugs.openjdk.java.net/browse/JDK-8062045 Update svc regression
tests to extend the default security policy instead of override
Webrev: http://cr.openjdk.java.net/~akulyakh/8062045/webrev/
This changes
Hi,
Could you, please, review the copyright change in the file below?
There's no code changes, only the copyright has been changed.
CR: https://bugs.openjdk.java.net/browse/JDK-8078962 Add Open JDK copyright to
PolynomialRoot.java test
Webrev:
To: alexander.kulyakh...@oracle.com, serviceability-dev@openjdk.java.net,
hotspot-...@openjdk.java.net
Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi Alex,
On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
Hi,
Could I
To: alexander.kulyakh...@oracle.com, serviceability-dev@openjdk.java.net,
hotspot-...@openjdk.java.net
Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi Alex,
On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
Hi,
Could I
:09:55 PM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Looks good!
Thanks,
/Staffan
On 28 apr 2015, at 15:09, Alexander Kulyakhtin
alexander.kulyakh...@oracle.com wrote:
Hi,
I've updated the webrev in accordance with David's comments
Hi,
Could someone, please, comment on the proposed renaming from
com.oracle.java.testlibrary to jdk.test.lib in the hotspot repo?
The changes have been verified by running all the hotspot tests and making sure
there are no compilation or other errors related to the change.
Best regards,
Hi,
Could I, please, have a review of this tests-only change:
https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the
com.oracle.java.testlibary package
Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
The change renames com.oracle.java.testlibrary package to
/compiler/debug/VerifyAdapterSharing.java
Thanks,
Lois
On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote:
Notifying hotspot-dev as well.
// Katja
On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote:
Could the reviewers, please, have a look at the proposed changes below?
In addition, we
test/compiler/cpuflags/RestoreMXCSR.java
test/compiler/debug/VerifyAdapterSharing.java
Thanks,
Lois
On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote:
Notifying hotspot-dev as well.
// Katja
On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote:
Could the reviewers, please, have
[mailto:serviceability-dev-boun...@openjdk.java.net]
On Behalf Of Alexander Kulyakhtin
Sent: Tuesday, March 24, 2015 10:05 AM
To: lois.fol...@oracle.com
Cc: hotspot-...@openjdk.java.net; serviceability-dev@openjdk.java.net;
alexandre.il...@oracle.com
Subject: Re: RFR: JDK-8075586: add @modules as needed to the open
Hi,
Could you, please, review the fix below.
CR: https://bugs.openjdk.java.net/browse/JDK-8075586
webrev: http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/
The fix adds @modules keyword to the existing hotspot tests, as needed, so that
the tests can access the required API
Hi,
Could you, please, review a small fix below.
bug: https://bugs.openjdk.java.net/browse/JDK-8072754
webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8072754/webrev.00/
The tests uses sun.misc.Version to check if the JVM version is greater than a
certain version.
For the JDK 9 the
Dhabi / Muscat
Subject: Re: RFR: JDK-8072754: Getting read of unnecessary sun.misc.Version in
the test
On 10/03/2015 12:38, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review a small fix below.
bug: https://bugs.openjdk.java.net/browse/JDK-8072754
webrev: http://cr.openjdk.java.net
” got broken.
Thanks,
/Staffan
On 28 jan 2015, at 17:24, Alexander Kulyakhtin
alexander.kulyakh...@oracle.com wrote:
Hi,
Could you, please, review the fix below.
bug: https://bugs.openjdk.java.net/browse/JDK-8071464
webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8071464
the review findings)
Looks god to me (not a reviewer).
// Katja
On 01/21/2015 11:23 AM, Alexander Kulyakhtin wrote:
Hi Katia,
Please, find attached the jdk.patch containing the changes per your findings.
The patch has been made by running the webrev tool.
Best regards,
Alex
- Original
(not a reviewer)
On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review the fix below.
To adress the previous review findings any referenes to test.jdk have been
removed.
bug: https://bugs.openjdk.java.net/browse/JDK-8067945
webrev: http://cr.openjdk.java.net
Hi,
Could you, please, review the fix below.
To adress the previous review findings any referenes to test.jdk have been
removed.
bug: https://bugs.openjdk.java.net/browse/JDK-8067945
webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/
References to tools.jar are
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8067945
webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.00/
References to tools.jar are removed from the tests as jdk9 drops tools.jar
Thanks,
Alex
Alan,
Thank you very much for the information.
I'm going to remove the @ignore annotation from the JDK-8068242 test as soon as
it's fixed, and will be using the ProblemList.txt for any future quarantine
requests.
Best regards,
Alexander
- Original Message -
From:
-8068242: quarantine the test
IsModifiableClassAgent.java until JDK-8068162 is resolved
Reviewed.
Merry Christmas, ho-ho-ho :)
On 24 December 2014 17:11:15 CET, dmitry.samers...@oracle.com wrote:
Looks good for me (not a reviewer).
--Dmitry
-Original Message-
From: Alexander
Hi,
Could I, please, have a review of this fix. This is a oneline change to
quarantine a test until JDK-8068162 is resolved
bug: https://bugs.openjdk.java.net/browse/JDK-8068242
webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/
@ignore JDK-8068162 added to the test
99 matches
Mail list logo
