Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Andrey Nazarov
Thank you! > On 25 Jul 2017, at 18:20, Mandy Chung wrote: > > >> On Jul 25, 2017, at 6:18 PM, Andrey Nazarov > > wrote: >> >> >> Updated by this line. >> http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ >>

Re: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java

2017-07-25 Thread Amy Lu
On 7/25/17 1:15 AM, Mandy Chung wrote: Webrev updated:http://cr.openjdk.java.net/~amlu/8183377/webrev.01/ Looks good. One minor suggestion is to place the source files under a directory showing its package hierachy e.g. src/comSA/Alice.java, src/comSB/Bob.java No need for a new webrev. Than

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Mandy Chung
> On Jul 25, 2017, at 6:18 PM, Andrey Nazarov > wrote: > > > Updated by this line. > http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ > Looks good. Mandy

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Andrey Nazarov
> On 25 Jul 2017, at 18:01, Mandy Chung wrote: > > >> On Jul 25, 2017, at 5:29 PM, Andrey Nazarov > > wrote: >> >> Thanks, Mandy >> I’ve updated patch >> http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ >>

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Mandy Chung
> On Jul 25, 2017, at 5:29 PM, Andrey Nazarov > wrote: > > Thanks, Mandy > I’ve updated patch > http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ > > Thanks for the update. One suggestion: you could simpl

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Andrey Nazarov
Thanks, Mandy I’ve updated patch http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ —Andrei > On 25 Jul 2017, at 16:12, Mandy Chung wrote: > > >> On Jul 21, 2017, at 6:35 PM, Andrey Nazarov >> wrote: >> >>

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

2017-07-25 Thread Andrey Nazarov
Thanks, Brian —Andrei > On 25 Jul 2017, at 16:41, Brian Burkhalter > wrote: > > Hi Andrei, > > I think this looks good. > > Thanks, > > Brian > > On Jul 25, 2017, at 3:59 PM, Andrey Nazarov > wrote: > >> Can anyone look? >> >> —Thanks, >> Andrei >>> On 19 Jul 2017, at 18:21, Andrey Naza

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

2017-07-25 Thread Brian Burkhalter
Hi Andrei, I think this looks good. Thanks, Brian On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: > Can anyone look? > > —Thanks, > Andrei >> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >> >> Hi, >> >> Could you review fix in test library which should help to resolve >> intermitte

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Mandy Chung
> On Jul 21, 2017, at 6:35 PM, Andrey Nazarov > wrote: > > Hi, > > Please review changes in launcher tests. I’ve added absent @modules jtreg > tags. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ >

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

2017-07-25 Thread Andrey Nazarov
Can anyone look? —Thanks, Andrei > On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: > > Hi, > > Could you review fix in test library which should help to resolve > intermittent issues on Windows machines during directories clean up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >

Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

2017-07-25 Thread Andrey Nazarov
Can anyone look? —Thanks, Andrei > On 21 Jul 2017, at 18:35, Andrey Nazarov wrote: > > Hi, > > Please review changes in launcher tests. I’ve added absent @modules jtreg > tags. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ >

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

2017-07-25 Thread Xueming Shen
+1 On 7/23/17, 6:37 AM, Claes Redestad wrote: Hi, java.lang.CharacterDataLatin1 and others are generated at build time by the GenerateCharacter tool, which has a -string mode to generate lookup tables as Strings literals rather than arrays directly. This serves multiple purposes: 1. it red

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

2017-07-25 Thread Mandy Chung
> On Jul 25, 2017, at 1:33 AM, Doug Simon wrote: > > >> On 25 Jul 2017, at 01:37, Mandy Chung wrote: >> >> Vladimir, >> >> I believe you don’t want to add the dependency from JVMCI to >> java.management. Otherwise, JVMCI can’t run with only java.base. > > The dependency is unfortunate. Ca

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

2017-07-25 Thread Claes Redestad
Hi, On 07/25/2017 01:14 PM, Ulf Zibis wrote: Hi, Am 23.07.2017 um 15:37 schrieb Claes Redestad: 1. it reduces the size of the generated bytecode, which is necessary to keep code below method bytecode limits if the arrays generated are very large I always was wondering why filling large loo

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

2017-07-25 Thread Ulf Zibis
Hi, Am 23.07.2017 um 15:37 schrieb Claes Redestad: 1. it reduces the size of the generated bytecode, which is necessary to keep code below method bytecode limits if the arrays generated are very large I always was wondering why filling large lookup tables is done by static java code in the

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

2017-07-25 Thread Doug Simon
> On 25 Jul 2017, at 01:37, Mandy Chung wrote: > > Vladimir, > > I believe you don’t want to add the dependency from JVMCI to java.management. > Otherwise, JVMCI can’t run with only java.base. The dependency is unfortunate. Can you suggest how JVMCI platform beans could participate in platf