Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

[Viktor Klang]

Seems legit

-- 
Cheers,
√

On Sep 26, 2016 23:29, "Attila Szegedi"  wrote:

> Not at all, you could just have a call to cancel() block until the future
> completes.
>
> *ducks*
>
> Attila.
>
> > On 25 Sep 2016, at 16:34, Viktor Klang  wrote:
> >
> > If that truely is the case then the only way of implementing a readonly
> > Future is by throwing an exception from cancel...
> >
> > --
> > Cheers,
> > √
> >
> > On Sep 25, 2016 4:20 PM, "Joe Bowbeer"  wrote:
> >
> >> This statement regarding what happens after cancel is called is correct:
> >>
> >> "*After this method returns, subsequent calls to **isDone**() will
> always
> >> return true*. Subsequent calls to isCancelled() will always return true
> >> if this method returned true."
> >>
> >> After cancel returns, the future is completed, hence isDone. If cancel
> >> returns true, i.e. it was cancelled, then  isCancelled returns true.
> But,
> >> for example if the future is already completed when cancel is called,
> then
> >> cancel will return false and isCancelled will return false.
> >>
> >> On Sep 25, 2016 6:49 AM, "David Holmes" 
> wrote:
> >>
> >>> I think that was meant to read “After this method returns _*true*_,
> >>> subsequent calls …”
> >>>
> >>>
> >>>
> >>> David
>

Re: We need to add blocking methods to CompletionStage!

[Viktor Klang]

On Sep 27, 2016 01:18, "Martin Buchholz"  wrote:
>
>
>
> On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang 
wrote:
>>>
>>>
>>>
>>> Test methods,
>>
>>
>> Yeah, I thought so as well, but it turns out that when you have tons of
async tests, not being able to start new tests until either that timeout or
result makes for a very slow test suite, so that's why most serious test
frameworks are growing support for dealing with async code. Then all you
want to be able to limit is work-in-progress (sloppily called parallelism)
>
>
> I don't see any support in junit or testng for multi-threaded tests.
 jtreg uses the strategy of having a set of reusable JVM processes, each of
which is running only one test at a time, which provides "pretty good"
isolation, and seems to work well.

It's less about multithreading per-se and more about async/non-blocking.

Here's one example of a fwk which supports it:
http://www.scalatest.org/user_guide/async_testing

>
>>>
>>> main methods
>>
>>
>> That's a common scenario, but one that can be solved by having
non-daemonic pooled worker threads.
>
>
> Do you have docs for such a thread pool?

You mean one which has a ThreadFactory which enables setDaemonic(false)?

>
>>>
>>> and unix process reapers are all examples where it's reasonable to
block forever.
>>
>>
>> What about waitpid() + WNOHANG?
>
>
> Are you suggesting periodic polling is better than blocking?

The botion of "better" requires some context to measure against:

>From a liveness, responsiveness and scalability PoV, I'd say, barring
selector support (which is arguably also polling), it's the next best
thing. Since it allows you to monitor N number of external processes with a
low constant factor.

>

 S: "I think it's unreasonable to not provide this for users
(especially when we can do so more efficiently)." <- If efficiency is
desired then blocking is definitely not the right solution.
>>>
>>>
>>> What about efficiently providing isComplete?
>>
>>
>> In my experience isComplete is virtually useless without being able to
extract the value, in which case you may as well introduce a non-blocking
`Optional poll()`
>
>
> Do you support adding the Polling methods from
> http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html
> to CompletionStage, i.e. isDone and getNow?

After thinking about it, I'd say 'No'. Since then people would ask to add
more polling options: isFailed etc.
Having been a part of creating s.c.Future I'd say adding the polling
methods (barring possibly 'value: Option[Try[T]]') has been proven to add
little in terms of value while adding a much larger API surface area.
Since Java lacks value-level try-catch (scala.util.Try) and Java lacks
disjoint union types, the signature of 'getNow' would have to throw, which
is generally a bad thing.

So I think a PollableCompletionStage would be a better option, where the
broader surface area of these kinds of ops can be contained.

Adding a CompletionStage constructor to CompletableFuture would make
conversions simple.

Reiterating Dougs sentiment: there is no API which will appease everyone,
and if everything always should be added, not only does every API become a
kitchen sink, but also all implementations thereof will be needlessly
complex, slow and hard to maintain.

>
>>>
>>> The result may already be available without actually blocking.  It may
even be known to be available immediately.  One would like to get the value
without additional allocation.
>>
>>
>> I've seen that use-case :), and it tends to either be a situation where
the value is available by pure luck (or…scheduling artifacts) or when one
is keeping CompletionStages where strict values could be kept instead
(think rebinding a value on completion).
>>
>> Reading what your'e writing, may I dare propose that what you're after
is something along the lines of a: PollableCompletionStage which sits in
between CompletionStage and CompletableFuture?
>
>
> I've been waffling!  Right now, I'm leaning towards having Java APIs
return fully mutable CompletableFutures as Benjamin and Pavel suggested
upthread.  Why?  Because a completion stage can be thought of as all of:
> - a consumer of an upstream value

Not this, CompletionStage doesn't specify how its value comes to be.

> - a subscription to the event that makes the upstream value available,
and

Never this, since CompletionStage is not cancellable.

> - the producer of a possible value for downstream consumers.

This is exactly what it is.

> Cancellation could be interpreted as a request to unsubscribe from
upstream producer or a notification to downstream consumers that no value
will be forthcoming, or both.

CompletionStage is not cancellable so this concern does not exist.

>
> Here's a problem with jdk9 minimalCompletionStage: even if you are happy
with the minimality of the source stage (perhaps it's shared) you might
want downstream stages to be mutable, but the methods such as thenApply
also create minimal completion stages.  

[9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Hamlin Li]

Please review the fix for JDK-8085192. The fix checks whether it fails 
to launch rmid due to "Port already in use" error, it will launch rmid 
again and again(20 times at most) until no such issue.


bug:
https://bugs.openjdk.java.net/browse/JDK-8085192
webrev:
http://cr.openjdk.java.net/~mli/8085192/webrev.00/

Thank you
-Hamlin

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Sergei Kovalev]

Hi Alan,

Looks like the root cause is jtreg issue. I'm going to close the CR as 
"Not an issue". Do you agree?


Thank you for review.

--
With best regards,
Sergei

26.09.16 10:06, Alan Bateman wrote:

On 25/09/2016 16:16, Sergei Kovalev wrote:

If I've drop jdk.jartool, I faced with ClassNotFound error as I 
showed in #3


 java.lang.ClassNotFoundException: 
jdk.security.jarsigner.JarSigner$Builder


As you can see TEST.properties contains both: jdk.compiler and 
jdk.jartool
I didn't suggesting dropping jdk.jartool, I was suggesting changing 
"@module java.compiler/javax.tools" to "@modules java.compiler".


I think we need to start a new thread on jtreg-dev about this issue as 
this is about test selection when TEST.properties is used to list the 
required modules.


-Alan 

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Roger Riggs]

Hi Hamlin,

Marking each test that uses RMID.launch with the bugid does not seem to 
be meaningful
since the bug is in the support infrastructure of the test and not 
specific to the test itself.
It would be overkill to try to confirm the bug was fixed by running all 
those tests.

Putting the bugid on 1 of the tests would be sufficient.

JavaVM.java:

 - 134-138:  Why define these private methods if they are not going to 
be used in outputContains?


- 185:  Its inefficient to convert the byte array to a string for when 
looking for each string.
It would be cleaner for JavaVM to have public outputString and 
errorString methods

and check them separately in RMID.
   (remove the JavaVM.outputContains method which hides which stream 
the string appeared in).



(It would be a bigger change to change this to use the test library 
ProcessTools and OutputAnalyzer).


Roger


On 9/27/2016 5:22 AM, Hamlin Li wrote:
Please review the fix for JDK-8085192. The fix checks whether it fails 
to launch rmid due to "Port already in use" error, it will launch rmid 
again and again(20 times at most) until no such issue.


bug:
https://bugs.openjdk.java.net/browse/JDK-8085192
webrev:
http://cr.openjdk.java.net/~mli/8085192/webrev.00/

Thank you
-Hamlin

Re: Proposal for adding O_DIRECT support into JDK 9

[Alan Bateman]

On 26/09/2016 19:50, Lu, Yingqi wrote:


Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-)
Apologies, I meant each of the native methods where the decision to use 
direct I/O or not would be a lot more maintainable in Java. You'll see 
that there are already code paths for direct vs. heap buffers.





Anyone else has other opinions on where is the best home for O_DIRECT flag? The 
flags under jdk.unsupported will eventually be removed in the future JDK 
release?

If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify that 
for sure.

I think ExtendedOpenOption is the right place. It's still TDB as to 
whether to put these extensions but that should be transparent to anyone 
using this when on the class path.


-Alan

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

[Roman Grigoriadi]

Thanks for pointing Mandy,

this package naming does apply to xerces types. I am not aware of any 
xerces package inside JAX-WS components.


I checked saaj-ri code and commented on issue (JDK-8166745). If 
elimination of com.sun.org.apache.xerces.internal.* is possible, it 
would not be an easy fix to include with this code sync.


Roman

On 09/26/2016 10:41 PM, Mandy Chung wrote:

I brought this up a while back.  SAAJ uses the java.xml's internal dom 
implementation.

Just to double check:
Is the standalone referencing com.sun.org.apache.xerces.internal.**?  Does the 
package naming apply only to the JAX-WS types (but not these xerces types)?

I couldn’t find any issue tracking it and will file one.

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

[Dávid Karnok]

If not a straight blocking method, a fluent conversion method to type R
could be useful IMO:

R to(Function, R> converter) {
return converter.apply(this);
}

This way, who needs a blocking get can have a function prepared with a
blocking operation:

 Function, T> blockingGet() {
   cs -> {
   Object[] result = { null, null };
   CountDownLatch cdl = new CountDownLatch();
   cs.whenComplete((v, e) -> {
   if (e != null) {
  result[1] = e;
   } else {
  result[0] = v;
   }
   cdl.countDown();
   });

   try {
   cdl.await();
   } catch (InterruptedException ex) {
   throw new RuntimeException(ex);
   }

   if (result[1] != null) {
  throw new RuntimeException(result[1]);
   }
   return result[0];
   }
}

T t = cs.to(blockingGet());


while others can convert it to a more enabled dataflow system:

cs.to(Flux::fromFuture)
.filter(v -> v < 50)
.defaultIfEmpty(-10)
.subscribe(System.out::println, Throwable::printStackTrace);

2016-09-27 10:39 GMT+02:00 Viktor Klang :

> Seems legit
>
> --
> Cheers,
> √
>
> On Sep 26, 2016 23:29, "Attila Szegedi"  wrote:
>
>> Not at all, you could just have a call to cancel() block until the future
>> completes.
>>
>> *ducks*
>>
>> Attila.
>>
>> > On 25 Sep 2016, at 16:34, Viktor Klang  wrote:
>> >
>> > If that truely is the case then the only way of implementing a readonly
>> > Future is by throwing an exception from cancel...
>> >
>> > --
>> > Cheers,
>> > √
>> >
>> > On Sep 25, 2016 4:20 PM, "Joe Bowbeer"  wrote:
>> >
>> >> This statement regarding what happens after cancel is called is
>> correct:
>> >>
>> >> "*After this method returns, subsequent calls to **isDone**() will
>> always
>> >> return true*. Subsequent calls to isCancelled() will always return true
>> >> if this method returned true."
>> >>
>> >> After cancel returns, the future is completed, hence isDone. If cancel
>> >> returns true, i.e. it was cancelled, then  isCancelled returns true.
>> But,
>> >> for example if the future is already completed when cancel is called,
>> then
>> >> cancel will return false and isCancelled will return false.
>> >>
>> >> On Sep 25, 2016 6:49 AM, "David Holmes" 
>> wrote:
>> >>
>> >>> I think that was meant to read “After this method returns _*true*_,
>> >>> subsequent calls …”
>> >>>
>> >>>
>> >>>
>> >>> David
>>
>
> ___
> Concurrency-interest mailing list
> concurrency-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Best regards,
David Karnok

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

[Benjamin Manes]

>
> I don't see any support in junit or testng for multi-threaded tests.


TestNG has basic support on @Test for running a test method concurrently.
This assumes synchronous code that does not perform complex coordination,
e.g. simple writes into a ConcurrentMap. Specifically the annotation
provides "threadPoolSize", "invocationCount", and "invocationTimeOut". It
does support multi-threaded test execution at the class or method level, or
isolation by JVM forking, for faster build times.

For test methods I most often use Awaitility
 with a JCiP-style test harness
. Lots of other options out
there depending on your needs.

I do think Doug's original design statement, quoted earlier, is probably
the best answer. It seems impossible for j.u.c. to provide the perfect API
for everyone for any given scenario. Instead CF is a building block that
you can limit or enhance by exposing a custom class. That may mean a
proliferation of subsets or over use of returning CF, but that could happen
regardless. Since it is easy to compose with lambdas, I consider the
approach taken pragmatic and the best of unsatisfying options.

Other than a few minor enhancements coming in JDK9, I'm pretty happy with
CF as is.

On Mon, Sep 26, 2016 at 4:18 PM, Martin Buchholz 
wrote:

>
>
> On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang 
> wrote:
>
>>
>>>
>> Test methods,
>>>
>>
>> Yeah, I thought so as well, but it turns out that when you have tons of
>> async tests, not being able to start new tests until either that timeout or
>> result makes for a very slow test suite, so that's why most serious test
>> frameworks are growing support for dealing with async code. Then all you
>> want to be able to limit is work-in-progress (sloppily called parallelism)
>>
>
> I don't see any support in junit or testng for multi-threaded tests.
>  jtreg uses the strategy of having a set of reusable JVM processes, each of
> which is running only one test at a time, which provides "pretty good"
> isolation, and seems to work well.
>
>
>> main methods
>>>
>>
>> That's a common scenario, but one that can be solved by having
>> non-daemonic pooled worker threads.
>>
>
> Do you have docs for such a thread pool?
>
>
>> and unix process reapers are all examples where it's reasonable to block
>>> forever.
>>>
>>
>> What about waitpid() + WNOHANG?
>>
>
> Are you suggesting periodic polling is better than blocking?
>
>
>> S: "I think it's unreasonable to not provide this for users
 (especially when we can do so more efficiently)." <- If efficiency is
 desired then blocking is definitely not the right solution.

>>>
>>> What about efficiently providing isComplete?
>>>
>>
>> In my experience isComplete is virtually useless without being able to
>> extract the value, in which case you may as well introduce a non-blocking
>> `Optional poll()`
>>
>
> Do you support adding the Polling methods from
> http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html
> to CompletionStage, i.e. isDone and getNow?
>
>
>> The result may already be available without actually blocking.  It may
>>> even be known to be available immediately.  One would like to get the value
>>> without additional allocation.
>>>
>>
>> I've seen that use-case :), and it tends to either be a situation where
>> the value is available by pure luck (or…scheduling artifacts) or when one
>> is keeping CompletionStages where strict values could be kept instead
>> (think rebinding a value on completion).
>>
>> Reading what your'e writing, may I dare propose that what you're after is
>> something along the lines of a: PollableCompletionStage which sits in
>> between CompletionStage and CompletableFuture?
>>
>
> I've been waffling!  Right now, I'm leaning towards having Java APIs
> return fully mutable CompletableFutures as Benjamin and Pavel suggested
> upthread.  Why?  Because a completion stage can be thought of as all of:
> - a consumer of an upstream value
> - a subscription to the event that makes the upstream value available, and
> - the producer of a possible value for downstream consumers.
> Cancellation could be interpreted as a request to unsubscribe from
> upstream producer or a notification to downstream consumers that no value
> will be forthcoming, or both.
>
> Here's a problem with jdk9 minimalCompletionStage: even if you are happy
> with the minimality of the source stage (perhaps it's shared) you might
> want downstream stages to be mutable, but the methods such as thenApply
> also create minimal completion stages.  If you want to convert to a mutable
> future, you can try calling toCompletableFuture, but there's no guarantee
> that will work, even if it doesn't throw UOE.  You can hand-construct a
> CompletableFuture which is then completed in a Runnable via thenRun, but
> then this is opaque to the CompletableFuture implementation, and
> implementation features such as stack overflow pr

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Alan,

Thank you for the explanation, we will modify the code accordingly and send it 
out soon for review.

Thanks,
Lucy

-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com] 
Sent: Tuesday, September 27, 2016 8:45 AM
To: Lu, Yingqi ; core-libs-dev@openjdk.java.net
Cc: nio-...@openjdk.java.net
Subject: Re: Proposal for adding O_DIRECT support into JDK 9

On 26/09/2016 19:50, Lu, Yingqi wrote:

> Alan, you mean readv0/write0 or read0/write0? I just want to make sure 
> :-)
Apologies, I meant each of the native methods where the decision to use direct 
I/O or not would be a lot more maintainable in Java. You'll see that there are 
already code paths for direct vs. heap buffers.


>
> Anyone else has other opinions on where is the best home for O_DIRECT flag? 
> The flags under jdk.unsupported will eventually be removed in the future JDK 
> release?
>
> If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify 
> that for sure.
>
I think ExtendedOpenOption is the right place. It's still TDB as to whether to 
put these extensions but that should be transparent to anyone using this when 
on the class path.

-Alan

RFR: JEP draft for Linux/s3990x port

[Volker Simonis]

Hi,

can you please review and endorse the following draft JEP for the
integration of the Linux/s390x port into the jkd9 master repository:

https://bugs.openjdk.java.net/browse/JDK-8166730

As detailed in the JEP, the Linux/s390x requires very few shared
changes and we therefore don't foresee any impact on the existing
platforms at all. Following you can find a short description of the
planned changes:

hotspot:
===

Out for review:
8166560: [s390] Basic enablement of s390 port.
http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/

Reviewed:
8166562: C2: Suppress relocations in scratch emit.
http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/

Will send RFR soon (depends on 8166560):
8166561: [s390] Adaptions needed for s390 port in C1 and C2.
http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01

We are still investigating the need of these shared changes:
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/911-pass_PC_to_retAddrOffset.patch
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/916-constant_table_offset.patch

And finally the patch with the s390x-only platform files. We are still
editing these to get them into OpenJdk style and shape.
Hotspot passes most jck, jtreg and spec tests with these.
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch

top-level repository:
===

The following is just adding some s390x specific compiler flags to flags.m4
8166800: [s390] Top-level build changes required for Linux/s390x
https://bugs.openjdk.java.net/browse/JDK-8166800

jdk repository:


This one just adds a new jvm.cfg file for s390x
8166801: [s390] Add jvm.cfg file for Linux/s390x
https://bugs.openjdk.java.net/browse/JDK-8166801


And finally we plan to do one more change which fixes the jtreg test
on Linux/s390x. But this is mainly for the correct detection of the
platform and for excluding the tests which are not appropriate for
s390x.

Thank you and best regards,
Volker

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

[Volker Simonis]

Hi Alan,

I've created a JEP. You can find it here:

https://bugs.openjdk.java.net/browse/JDK-8166730

I've also just sent an RFR for the JEP to the various list with some
more detailed information.

It would be great if you could review it for the class library. The
changes to the jdk-repo are really minimal - just adding a jvm.cfg
file for s390x.

Thank you and best regards,
Volker


On Sat, Sep 24, 2016 at 12:08 PM, Alan Bateman  wrote:
> On 23/09/2016 06:52, Lindenmaier, Goetz wrote:
>
>> Hi,
>>
>> This change is part of the s390 port. It contains some basic adaptions
>> needed for a full hotspot port for linux s390x.
>>
>>
> Out of curiosity, is there is JEP for the Linux/S390 port? There were JEPs
> for the Linux/AArch64 and PowerPC/AIX ports and just wondering if there is
> one coming for the S390 port too?
>
> -Alan

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

[Volker Simonis]

On Fri, Sep 23, 2016 at 8:11 AM, David Holmes  wrote:
> Hi Goetz,
>
> I see a change not related directly to S390 ie change from ARM to ARM32 in
> src/os/linux/vm/os_linux.cpp
>

The change looks a little confusing because Goetz reordered the ifdef
cascades alphabetically (which I think is good).

Besides that, the only real change not related to s390 is indeed the
change from ARM to ARM32 which happend two times in the file.

@Goetz: have you done this intentionally?

> It will be a while before I can go through this in any detail.
>
> David
>
>
> On 23/09/2016 3:52 PM, Lindenmaier, Goetz wrote:
>>
>> Hi,
>>
>> This change is part of the s390 port. It contains some basic adaptions
>> needed for a full hotspot port for linux s390x.
>>
>> It defines the required macros, platform names and includes.
>>
>> The s390 port calles CodeCache::contains() in current_frame(), which is
>> used in NMT. As NMT already collects stack traces before the CodeCache is
>> initialized, contains() needs a check for this.
>>
>>  Wherever a row of platforms are listed, I sorted them alphabetically.
>>
>>  The jdk requires the file jvm.cfg.
>>
>> Please review. I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/
>> http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/
>>
>> Best regards,
>>   Goetz.
>>
>

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Brent Christian]

Thanks for making some improvements to these intermittent RMI tests.

I agree with Roger that I don't think we want to add the id to the @bug 
of every test.


Also, it looks like there's an indentation change in JavaVM.java:

53 public static final long POLLTIME_MS = 100L;

(I believe running webrev with '-b' will include whitespace changes.)

Thanks,
-Brent

On 9/27/16 2:22 AM, Hamlin Li wrote:

Please review the fix for JDK-8085192. The fix checks whether it fails
to launch rmid due to "Port already in use" error, it will launch rmid
again and again(20 times at most) until no such issue.

bug:
https://bugs.openjdk.java.net/browse/JDK-8085192
webrev:
http://cr.openjdk.java.net/~mli/8085192/webrev.00/

Thank you
-Hamlin

Re: RFR: JEP draft for Linux/s3990x port

[Vladimir Kozlov]

On 9/27/16 10:49 AM, Volker Simonis wrote:

Hi,

can you please review and endorse the following draft JEP for the
integration of the Linux/s390x port into the jkd9 master repository:

https://bugs.openjdk.java.net/browse/JDK-8166730


Good.
Add links to webrevs in a comment. It will help to get umbrella FC 
extension approval.




As detailed in the JEP, the Linux/s390x requires very few shared
changes and we therefore don't foresee any impact on the existing
platforms at all. Following you can find a short description of the
planned changes:

hotspot:
===

Out for review:
8166560: [s390] Basic enablement of s390 port.
http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/

Reviewed:
8166562: C2: Suppress relocations in scratch emit.
http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01/

Will send RFR soon (depends on 8166560):
8166561: [s390] Adaptions needed for s390 port in C1 and C2.
http://cr.openjdk.java.net/~goetz/wr16/8166562-scratch_emit/webrev.01


Wrong link.

Thanks,
Vladimir



We are still investigating the need of these shared changes:
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/911-pass_PC_to_retAddrOffset.patch
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/916-constant_table_offset.patch

And finally the patch with the s390x-only platform files. We are still
editing these to get them into OpenJdk style and shape.
Hotspot passes most jck, jtreg and spec tests with these.
http://cr.openjdk.java.net/~goetz/wr16/s390x_patch_queue/hotspot/9000101-zFiles.patch

top-level repository:
===

The following is just adding some s390x specific compiler flags to flags.m4
8166800: [s390] Top-level build changes required for Linux/s390x
https://bugs.openjdk.java.net/browse/JDK-8166800

jdk repository:


This one just adds a new jvm.cfg file for s390x
8166801: [s390] Add jvm.cfg file for Linux/s390x
https://bugs.openjdk.java.net/browse/JDK-8166801


And finally we plan to do one more change which fixes the jtreg test
on Linux/s390x. But this is mainly for the correct detection of the
platform and for excluding the tests which are not appropriate for
s390x.

Thank you and best regards,
Volker

[9] RFR: 8166645: Include locales plugin throws InternalError with "*" specified.

[Naoto Sato]

Hello,

Please review the changes for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8166645

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8166645/webrev.00/

The fix makes sure that the supported language tags created by the 
plugin are in the original supported language tags.


Naoto

Re: RFR: 8165944 jar utility doesn't process more than one -C argument

[Steve Drach]

After a discussion with Paul Sandoz, I’ve simplified and, hopefully, thus 
clarified the changeset.  The new webrev is

http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/ 


> On Sep 26, 2016, at 12:31 PM, Steve Drach  wrote:
> 
> Hi,
> 
> Please review these changes to the jar tool to fix a capability regression I 
> introduced in an earlier revision.  The issue is that this
> 
> $ jar -cf test.jar -C test1 . -C test2 .
> 
> only puts the files under test1 in the jar and ignores the files under test2. 
>  The DoubleCs test verified the problem and the solution.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8165944 
> 
> webrev: http://cr.openjdk.java.net/~sdrach/8165944/webrev.00/ 
> 
> 
> Thanks,
> Steve
> 

Review Request: JDK-8166238 Update jdeps for GNU-style long form options

[Mandy Chung]

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166238/webrev.00/index.html

This patch renames the following options added in JDK 9 jdeps
  --gen-module-info => —generate-module-info
  -inverse  => —-inverse
  -requires => —-require

and also adds the long-form option corresponding to a few existing options:
  —-api-only
  —-dot-output
  -—jdk-internals
  —-package
  —-regex
  -—version

Mandy

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Hamlin Li]

Hi Roger,

Thank you for reviewing.
Please check the new webrev: 
http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline 
below.


On 2016/9/27 23:14, Roger Riggs wrote:

Hi Hamlin,

Marking each test that uses RMID.launch with the bugid does not seem 
to be meaningful
since the bug is in the support infrastructure of the test and not 
specific to the test itself.
It would be overkill to try to confirm the bug was fixed by running 
all those tests.

Putting the bugid on 1 of the tests would be sufficient.

Remove all bug ids except of the one in CheckImplClassLoader.java.


JavaVM.java:

 - 134-138:  Why define these private methods if they are not going to 
be used in outputContains?


- 185:  Its inefficient to convert the byte array to a string for when 
looking for each string.
It would be cleaner for JavaVM to have public outputString and 
errorString methods

and check them separately in RMID.
   (remove the JavaVM.outputContains method which hides which stream 
the string appeared in).

Fixed.
(It would be a bigger change to change this to use the test library 
ProcessTools and OutputAnalyzer).
Thank you suggestion. Yes, you're right, it will be a little bit 
complicated to use ProcessTools and OutputAnalyzer in this situation, 
need to modify these classes, because they will block until process 
terminates. So I prefer to use current implementation, as it's simple 
and clear.


Thank you
-Hamlin


Roger


On 9/27/2016 5:22 AM, Hamlin Li wrote:
Please review the fix for JDK-8085192. The fix checks whether it 
fails to launch rmid due to "Port already in use" error, it will 
launch rmid again and again(20 times at most) until no such issue.


bug:
https://bugs.openjdk.java.net/browse/JDK-8085192
webrev:
http://cr.openjdk.java.net/~mli/8085192/webrev.00/

Thank you
-Hamlin

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Hamlin Li]

Hi Brent,

Thank you for reviewing.
Please check the new webrev: 
http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline 
below.



On 2016/9/28 2:07, Brent Christian wrote:

Thanks for making some improvements to these intermittent RMI tests.

I agree with Roger that I don't think we want to add the id to the 
@bug of every test.

Yes, I think it's reasonable too. Fixed.


Also, it looks like there's an indentation change in JavaVM.java:

53 public static final long POLLTIME_MS = 100L;

(I believe running webrev with '-b' will include whitespace changes.)

Fixed, thank you for the tip, new webrev is generated with "-b". :-)

Thank you
-Hamlin


Thanks,
-Brent

On 9/27/16 2:22 AM, Hamlin Li wrote:

Please review the fix for JDK-8085192. The fix checks whether it fails
to launch rmid due to "Port already in use" error, it will launch rmid
again and again(20 times at most) until no such issue.

bug:
https://bugs.openjdk.java.net/browse/JDK-8085192
webrev:
http://cr.openjdk.java.net/~mli/8085192/webrev.00/

Thank you
-Hamlin

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[Michael Haupt]

Hello,

reviews, please ... ?

Thanks,

Michael

> Am 26.09.2016 um 21:01 schrieb Michael Haupt :
> 
> Hi John, all,
> 
> thank you very much for your reviews - may I ask for a second round?
> 
> The updated webrev is at 
> http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ 
> ;
> an accompanying specdiff, at 
> http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ 
> .
> 
> Thanks,
> 
> Michael
> 
>> Am 16.08.2016 um 01:39 schrieb John Rose :
>> 
>> I'm working on this.  The javadoc has some re-filling which creates lots of 
>> diffs of whitespace only, which makes things go a little slower.
>> 
>> I am trying to like the cleaner, more restricted semantics for the utility 
>> methods, but they really do some harm to the use cases.  The really notable 
>> change is the loss of defaulting behavior of the first parameter to 
>> iteratedLoop, which was List::iterator.  That was intended to corresponding 
>> to the for-each syntax, and it is hard (and probably non-performant) to ask 
>> the user to rebuild a MH for Iterable::iterator at each use site for 
>> iteratedLoop.
>> 
>> — John
> 
> 
> -- 
> 
> 
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> 
> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
> München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
> 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> Oracle is committed to developing 
> practices and products that help protect the environment
> 

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

[John Rose]

On Sep 26, 2016, at 12:01 PM, Michael Haupt  wrote:
> 
> thank you very much for your reviews - may I ask for a second round?
> 
> The updated webrev is at 
> http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ 
>   >;
> an accompanying specdiff, at 
> http://cr.openjdk.java.net/~mhaupt/8151179/specdiff.01/ 
>   >.

Reviewed.  This is a huge leap forward.

A few small comments to consider:

In FacLoop, the argument k should be named acc:
+-  int fin(int i, int k) { return k; }
++  int fin(int i, int acc) { return acc; }

This affects *two* files, a JDE.java and MHs.java.

Fix awkwardness:  s/A similar same example/A similar example

I'm really glad to see the FacLoop example, BTW; I think it is often the right 
pattern to use.

There is a redundant phrase in the javadoc which reads oddly:

+ A non-void value returned from the body (which must also be of type V) 

But the previous line just defined V as the return value of the body:
+ If the body handle returns a non-void type V, a leading loop iteration 
variable of that type is also present. 

Seems like you can just omit "(which must also be of type V)" or shorten it to 
"(of type V)" or perhaps "(which is the leading iteration variable)".  In any 
case, the role of "V" is fully described in the bullet item list that follows.

The whole section beginning "Example. As a consequence of step 1A above" is 
kind of fluffy.  It doesn't add much, although it is technically correct.  You 
could take it out if you feel the same.  (The fact that the "pred" guys are 
assumed to take no arguments means that it's a pretty useless loop.)  I don't 
mind leaving it in, though, in the interests of converging this review process!

Thank you for putting in the extra working examples.  That will really help 
users pick the right patterns.

— John