Re: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

[Chris Plummer]

Unfortunately I need another review of these changes. I ran into a minor 
problem. Although all the jprt testing I tried passed, when I looked 
into the log files I noticed an issue. I saw the following:


Test results: passed: 1
Report written to 
/opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html
Results written to 
/opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork

/bin/sh: 15: [: 0: unexpected operator
Summary:
TEST STATS: name=  run=1  pass=1  fail=0
EXIT CODE: 0
EXIT CODE: 0

Notice the "unexpected operator" message in the middle. This only 
happens on our arm platforms. It doesn't seem to affect the test 
results, but should be cleaned up anyway. The "0" turns out to be the 
exit code. I see the same message if a test fails, except the 0 changes 
to a 2. Looking more closely at the code I added, I see I used ==, 
whereas other code nearby uses =. I change it to = and the error message 
went away. I retested with various test cases that fail, pass, or run no 
tests, and all of them do as expected still.


New webrev can be found at:

http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/

thanks,

Chris

On 8/2/16 7:50 AM, Chris Plummer wrote:

On 8/1/16 9:30 PM, Chris Plummer wrote:

On 8/1/16 7:25 PM, David Holmes wrote:

On 2/08/2016 12:11 PM, Chris Plummer wrote:

On 8/1/16 5:58 PM, David Holmes wrote:

Hi Chris,

On 2/08/2016 8:46 AM, Chris Plummer wrote:

Hello,

Please review this simple change:

https://bugs.openjdk.java.net/browse/JDK-8162670
http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/


You've split a compound expression with your code:

 227   jtregExitCode=$$? && \
 228   if [ $${jtregExitCode} == 1 ]; then \
 229 jtregExitCode=0; \
 230   fi ; \
 231   _summary="$(SUMMARY_TXT)"; \

I'm not clear exactly why the && was needed here but rather than find
out later I suggest rearranging the above to:

   jtregExitCode=$$? && \
   _summary="$(SUMMARY_TXT)"; \
   if [ $${jtregExitCode} == 1 ]; then \
 jtregExitCode=0; \
   fi ; \


Yeah, that makes sense. I'll make the change. However, it's really
unclear what the use case for && is here. How can jtregExitCode=$$? 
ever

fail?


I wonder if it evaluates to the $? value and so only sets _summary 
if we had a zero exit code? (Not that I understand why we would only 
set _summary in that context.)

I tried the following:

bash-4.1$ x=0 && echo "foo";

And "foo" is always printed. I also tried non-zero values for x. Here 
are some other examples:


bash-4.1$ (exit 1) && echo "foo"
bash-4.1$ (exit 0) && echo "foo"
foo

Commands evaluate to true if the exit status is 0, and false 
otherwise, so I guess you could say commands evaluate to !?$. For &&, 
the rhs is only executed if the lhs has a zero exit status.

Updated webrev:

http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/

thanks,

Chris


Chris


David


thanks,

Chris

Thanks,
David

Note the copyright dates haven't been updated in this webrev, but 
I did

update them locally after noticing that.

Tested with jprt test case given in the CR, and also with a jprt run
using "testset -hotspot" to make sure I didn't break anything.

thanks,

Chris

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

[Joe Wang]

On 8/3/16, 3:45 AM, Daniel Fuchs wrote:

Hi Frank,

I looked at the diffs of the diffs between webrev.02 and webrev.03 and
it looks good to me.

+1 - provided all tests pass :-)


+1, thanks for re-enabling the tests that had dependencies on 8162848. I 
also closed 8162848.




But I have the same question than Joe: aren't all the test supposed
to run twice: once with security manager and once without?
(except for those test that might explicitly require a security manager)


I agree, all of the tests need to run with and without security manager. 
It would be good to combine the  runWithSecurityManager and 
runWithoutSecurityManager methods into one with a condition that 
determines whether a security manager is present.


Best,
Joe



best regards,

-- daniel

On 03/08/16 11:12, Frank Yuan wrote:

Hi Joe

Thank you for your review!

I updated the tests according to the latest comments as well as had 
unittest/transform/TransformerTest.java up to date, please check

http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/


Thanks
Frank

-Original Message-
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP 
unit tests




On 8/2/16, 5:30 AM, Daniel Fuchs wrote:

Hi Frank,

I am intrigued by these change which do not seem
to have anything to do with the rest. I mean, I'm not opposed
as long as they are intended and that Joe validates them:



http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram 


es.html



118 spf.setNamespaceAware(false);


Not sure why this was changed.



http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra 


mes.html




The test itself wasn't very clear on the content it tests. If it only
verifies whether a resolver is used as is said, then this and related
changes in ResolverTest and publish.xml are fine. To the extent it
verifies, it didn't have to output to a file.



http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h 


tml




We have to let Frank explain why namespace was turned off for these
tests :-)  In this case, XMLReaderNSTableTest. In general, I would say
enabling security shouldn't change tests or gold files in this case.



http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html 



This looks like a desirable change - but what does it have to do
with enabling security manager?


Probably to remove the reference to that particular server?  Seems to be
fine as a cleanup. Again, it (the original test) only verifies a resolve
is used, it didn't even need to write out a file to prove that.


Also:


http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html 




  70
tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions;, 


true);

Is this needed only when there is a security manager?


Yes, when Security Manager is present, this feature is turned off by
default.




http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html 





 119 /*
 120 addPermission(new RuntimePermission("getClassLoader"));
 121 addPermission(new RuntimePermission("createClassLoader"));
 122 addPermission(new
RuntimePermission("createSecurityManager"));
 123 addPermission(new RuntimePermission("modifyThread"));
 124 addPermission(new PropertyPermission("*", "read,write"));
 125
 126 addPermission(new RuntimePermission("setIO"));
 127 addPermission(new
RuntimePermission("setContextClassLoader"));
 128 addPermission(new
RuntimePermission("accessDeclaredMembers"));*/


Please remove before pushing.




test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml 


test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl

It seems these two files have been removed, but shouldn't they have
been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform
instead?
I see they are used by
test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java

Did you forget to hg add them?




Otherwise the new JAXPPolicyManager & its Policy implementation
look good. This is much simpler and better than the first
iteration :-)

This was a *very* long patch - so congratulations for seeing
this through!


Very long patch, indeed! Thanks for the great effort!  Very well done
with the unified 

Re: Unexpected BindException in Endpoint.publish

[KUBOTA Yuji]

Hi Aleksej,

Thank you very much!
If you need some help about the patch, please mention me :)

Thanks,
Yuji

2016-08-03 19:56 GMT+09:00 Aleks Efimov :
> Hi Yuji,
>
> I've created JDK8 backport [1] for this issue and will work on it in the
> upcoming months.
>
> Best Regards,
>
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8162941
>
>
>
> On 02/08/16 08:33, KUBOTA Yuji wrote:
>>
>> Hi all,
>>
>> Could you let me know when this fix will be backport to JDK 8?
>> We need this backport to migrate our system from JDK 7 to JDK 8.
>>
>> Thanks,
>> Yuji
>>
>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji :
>>>
>>> Hi Miroslav,
>>>
>>> Thank you for your sponsor! :
>>> https://bugs.openjdk.java.net/browse/JDK-8146086
>>>
>>> Can I ask the schedule when does this fix backport to JDK8 ?
>>>
>>> Thanks,
>>> Yuji
>>>
>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos :

 Hi Yuji,
 thanks for the patch - it fixes the issue and looks ok to me. I'll
 integrate
 it to standalone JAX-WS repo and it will be integrated into openjdk
 during
 next syncup.

 Thanks
 Miran




 On 01/12/15 11:11, KUBOTA Yuji wrote:
>
> Hi Miroslav and all,
>
> Could you please review the below issue and patch?
>
> I got the advice by Alan at net-dev. So I want to ask you.
>
> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html
>
> 
> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
> community. This's second times from JavaOne14. :)
>
> We find an unexpected exception in JAX-WS, so I write a patch to fix
> it.
> We think that this issue may block the migration to JDK9 from JDK7.
>
> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
> following test code, JDK9 (and JDK8) returns "java.net.BindException:
> Address already in use.” as the below. But JDK7 does NOT return the
> exception.
>
> - Test code for reproduce
> ---
> import javax.jws.*;
> import javax.xml.ws.*;
>
> public class WSTest{
>
> @WebService
> public static class Method1{
>   @WebMethod
>   public String getMethod1Value(){
> return "from Method1";
>   }
> }
>
> @WebService
> public static class Method2{
>   @WebMethod
>   public String getMethod2Value(){
> return "from Method2";
>   }
> }
>
> public static void main(String[] args) throws Exception{
>   Endpoint endPoint1 =
> Endpoint.publish("http://0.0.0.0:8081/method1;,
>new
> Method1());
>   Endpoint endPoint2 =
> Endpoint.publish("http://0.0.0.0:8081/method2;,
>new
> Method2());
>
>   System.out.println("Sleep 3 secs...");
>
>   Thread.sleep(3000);
>
>   endPoint2.stop();
>   endPoint1.stop();
> }
>
> }
> ---
>
> - StackTrace
> ---
> Exception in thread "main"
> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
> Error: java.net.BindException: Address already in use
>   at
>
> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
>   at
>
> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
>   at
>
> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
>   at
>
> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
>   at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
>   at wstest.WSTest.main(WSTest.java:27)
> Caused by: java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind0(Native Method)
>   at sun.nio.ch.Net.bind(Net.java:432)
>   at sun.nio.ch.Net.bind(Net.java:424)
>   at
>
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>   at
> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>   at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
>   at
> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
>   at
>
> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
>   at
> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
>   at
>
> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
>   ... 5 more
> -
>
> To publishes the 

Re: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests

[David Holmes]

Hi Dmitrij,

I know this reflects the changes made in hotspot/test but I have a 
query. Does this:


+ requires.extraPropDefns.vmOpts = -XX:+UnlockDiagnosticVMOptions 
-XX:+WhiteBoxAPI -Xbootclasspath/a:bootClasses


mean that the VM under test is executed with those additional flags when 
running the tests? Or is it run once with those flags to establish the 
"requires" properties?


If the latter then I have no concern and this change seems fine.

Thanks,
David

On 3/08/2016 11:25 PM, Dmitrij Pochepko wrote:

Hi,

can somebody with official reviewer role review this?

Thanks,
Dmitrij

On 29.07.2016 21:42, Dmitrij Pochepko wrote:

Sure,

now including core-libs-dev

Thanks,
Dmitrij

On 29.07.2016 20:16, joe darcy wrote:

Hello,

I also recommend sending this review request over to core-libs-dev
since it affect the jdk repo.

Thanks,

-Joe


On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote:

Hi Dmitrij,

The change itself looks good.

One note: this change adds a little overhead (a very little) for
running tests in jdk repository, but it's required only for VM
specific tests stored in jdk. As alternative of this change I can
suggest moving VM specific tests from the 'jdk' to 'hotspot'
repository. Perhaps, such massive update is too late for JDK9 time
frame and could be done only in JDK10.
So, if the changes depending on 8162727 are not so critical and
could be deferred I would prefer to postpone this fix.

Thanks,
Dima


On 29.07.2016 4:29, Vladimir Kozlov wrote:

It affects all groups. Should be reviewed on hotspot-dev.

Thanks,
Vladimir

On 7/28/16 10:19 AM, Dmitrij Pochepko wrote:

Hi,

please review small patch for 8162727 - Testbug: additional
requires properties can't be used for filtering server vm in jdk
jtreg tests

A problem is that tests under jdk repo can't use additional jtreg
requires properties(like vm.flavor to filter out client or server
vm). The same functionality was introduced for hotspot repo as part
of JDK-8154956. So, in order to filter tests using these
additional properties a small fix is created.

webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/
CR: https://bugs.openjdk.java.net/browse/JDK-8162727

Thanks,
Dmitrij

HttpURLConnection.getResponseCode() documentation comment

[boris.x.shukhat]

To whom it may concern,

This comment is about API documentation on HttpURLConnection.getResponseCode() 
and it is based on the implementation details as well.

HttpURLConnection implementation caches response code that allows to repeatedly 
get a response code from HttpURLConnection  even after disconnect() is called. 
If a response code had been cached before disconnect() was called then its 
value is returned. But if the return code has not been cached, it (under some 
circumstances) opens a connection and leaves it opened if disconnect() is not 
called again. If called in the loop multiple times this design potentially can 
cause connection leakage and it happens in open source library
https://github.com/elastic/elasticsearch-metrics-reporter-java/blob/master/src/main/java/org/elasticsearch/metrics/ElasticsearchReporter.java
lines 397-406

I do not think that it is reasonable to change the implementation at this point 
because it can break existing software but it has to be reflected in API help 
on HttpURLConnection.getResponseCode() that it can leave connection open and 
another disconnect() may need to be called.


The problem can be reproduced by running the following code long enough and 
using ss Linux command (netstat command on Windows) to periodically monitor 
sockets with established connection.

public class Test
{
public static void main(String...args) throws Exception
{
while(true)
{
URL url=new URL("...");
HttpURLConnection 
connection=(HttpURLConnection)url.openConnection();
connection.connect();
connection.disconnect();
int responseCode=connection.getResponseCode();
Thread.sleep(10);
}

}
}





Thanks,
Boris Shukhat



___

This message is for information purposes only, it is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is not intended for retail customer use. Intended for 
recipient only. This message is subject to the terms at: 
www.barclays.com/emaildisclaimer.

For important disclosures, please see: 
www.barclays.com/salesandtradingdisclaimer regarding market commentary from 
Barclays Sales and/or Trading, who are active market participants; and in 
respect of Barclays Research, including disclosures relating to specific 
issuers, please see http://publicresearch.barclays.com.

___

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

[Kim Barrett]

> On Aug 3, 2016, at 3:41 AM, David Holmes  wrote:
> 
> On 2/08/2016 4:46 AM, Kim Barrett wrote:
>> This updated webrev addresses the concerns around initialization order
>> for Throwable and OutOfMemoryError.  It doesn't address the VM API
>> used by the reference processor thread; that will be in a later
>> webrev.
>> 
>> New webrevs:
>> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/
>> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/
>> 
>> The jdk tree is unchanged from webrev.01.
>> 
>> I've backed out the change to initialize_java_lang_classes.  (To
>> verify this, look at the runtime/thread.cpp in the full webrev.)
>> 
>> Instead, Universe::gen_out_of_memory_error now also requires Throwable
>> to be initialized before it will attempt to fill in the stack trace.
>> This means that VM generated OOMEs occurring early in initialization
>> won't have a stack trace.
> 
> This change looks good to me.

Thanks!

Re: JDK 9 RFR of JDK-8161024: Remove intermittent key from java/lang/Runtime/exec/LotsOfOutput.java

[joe darcy]

Hi Amy,

The changes looks good; we'll keep an eye on the test to make sure it 
doesn't start misbehaving again :-)


Thanks,

-Joe


On 8/3/2016 12:49 AM, Amy Lu wrote:

java/lang/Runtime/exec/LotsOfOutput.java

This test was failing intermittently (JDK-8078582 JDK-8086117). 
Mentioned issues have been resolved and no open bug (no failure 
reported) till now.


This patch is to remove @key intermittent from the test.

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


Thanks,
Amy

--- old/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 
15:47:45.0 +0800
+++ new/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 
15:47:45.0 +0800

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,6 @@
  * @test
  * @bug 4369826 8078582
  * @summary Process with lots of output should not crash VM
- * @key intermittent
  * @author kladko
  */

Re: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests

[Dmitrij Pochepko]

Hi,

can somebody with official reviewer role review this?

Thanks,
Dmitrij

On 29.07.2016 21:42, Dmitrij Pochepko wrote:

Sure,

now including core-libs-dev

Thanks,
Dmitrij

On 29.07.2016 20:16, joe darcy wrote:

Hello,

I also recommend sending this review request over to core-libs-dev 
since it affect the jdk repo.


Thanks,

-Joe


On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote:

Hi Dmitrij,

The change itself looks good.

One note: this change adds a little overhead (a very little) for 
running tests in jdk repository, but it's required only for VM 
specific tests stored in jdk. As alternative of this change I can 
suggest moving VM specific tests from the 'jdk' to 'hotspot' 
repository. Perhaps, such massive update is too late for JDK9 time 
frame and could be done only in JDK10.
So, if the changes depending on 8162727 are not so critical and 
could be deferred I would prefer to postpone this fix.


Thanks,
Dima


On 29.07.2016 4:29, Vladimir Kozlov wrote:

It affects all groups. Should be reviewed on hotspot-dev.

Thanks,
Vladimir

On 7/28/16 10:19 AM, Dmitrij Pochepko wrote:

Hi,

please review small patch for 8162727 - Testbug: additional 
requires properties can't be used for filtering server vm in jdk 
jtreg tests


A problem is that tests under jdk repo can't use additional jtreg 
requires properties(like vm.flavor to filter out client or server 
vm). The same functionality was introduced for hotspot repo as part
of JDK-8154956. So, in order to filter tests using these 
additional properties a small fix is created.


webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/
CR: https://bugs.openjdk.java.net/browse/JDK-8162727

Thanks,
Dmitrij

Re: [8u] request for approval: "8152172: PPC64: Support AES intrinsics"

[Seán Coffey]

On 02/08/16 20:47, Volker Simonis wrote:

Hi Sean,

thanks a lot for your reply.

You're right - I'm still waiting for a review of the hotspot part. Any
volunteers :)

OK - would be good to get a hotspot reviewer to look at those first.


Regarding the noreg label: I used 'noreg-other' because there already
exist AES tests (they have never been part of this original change).
Is that the right label? There are simply too many different noreg
labels without documentation so if I selected the wrong one, please
advice which one to choose.
noreg labels are documented at : 
http://openjdk.java.net/guide/changePlanning.html#noreg
noreg-other seems fine. You might want to add a short comment to bug 
outlining your comment on existing AES tests.


regards,
Sean.


Thanks,
Volker


On Tue, Aug 2, 2016 at 9:58 AM, Seán Coffey  wrote:

Volker,

Have the jdk8u hotspot edits been reviewed ? Looks like they should be.

Can you add a suitable noreg label to the master bug report also.

Regards,
Sean.


On 29/07/2016 19:58, Volker Simonis wrote:

Ping!

Can I please have an approval for backporting this change to 8u-dev?

Thanks,
Volker


On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
 wrote:

Hi,

could you please approve the backport of the following, mostly ppc64
change to jdk8u-dev:

8152172: PPC64: Support AES intrinsics

Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
Review:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f

As you can see, the change consists of two parts - the main one in the
hotpsot repo and a small part in the jdk repo.

The jdk part applied cleanly to jdk8u (with the usual directory
shuffling).

The hotspot part required a small tweak, but only in the ppc-only
part. This is because the feature detection for the AES instructions
was already active in jdk9 when the original change was made but is
not available in jdk8u until now. You can find the additional changes
at the end of this mail for your convenience.

The required shared changes cleanly apply to jdk8u.

As Vladimir pointed out in a previous thread, shared Hotspot changes
have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
that and synchronously push both parts.

@Hiroshii: could you please verify that you are fine with the change?
I've done some tests on Power8LE but just want to be sure this
downport satisfies your needs as well.

Thank you and best regards,
Volker

=

diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
--- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
+++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
@@ -452,6 +476,7 @@
 a->popcntw(R7, R5);  // code[7] -> popcntw
 a->fcfids(F3, F4);   // code[8] -> fcfids
 a->vand(VR0, VR0, VR0);  // code[9] -> vand
+  a->vcipher(VR0, VR1, VR2);   // code[10] -> vcipher
 a->blr();

 // Emit function to set one cache line to zero. Emit function
descriptor and get pointer to it.
@@ -495,6 +520,7 @@
 if (code[feature_cntr++]) features |= popcntw_m;
 if (code[feature_cntr++]) features |= fcfids_m;
 if (code[feature_cntr++]) features |= vand_m;
+  if (code[feature_cntr++]) features |= vcipher_m;

 // Print the detection code.
 if (PrintAssembly) {
diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
--- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
+++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
@@ -42,6 +42,7 @@
   fcfids,
   vand,
   dcba,
+vcipher,
   num_features // last entry to count features
 };
 enum Feature_Flag_Set {
@@ -56,6 +57,7 @@
   fcfids_m  = (1 << fcfids ),
   vand_m= (1 << vand   ),
   dcba_m= (1 << dcba   ),
+vcipher_m = (1 << vcipher),
   all_features_m= -1
 };
 static int  _features;
@@ -83,6 +85,7 @@
 static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
 static bool has_vand(){ return (_features & vand_m) != 0; }
 static bool has_dcba(){ return (_features & dcba_m) != 0; }
+  static bool has_vcipher() { return (_features & vcipher_m) != 0; }

 static const char* cpu_features() { return _features_str; }

Re: Unexpected BindException in Endpoint.publish

[Aleks Efimov]

Hi Yuji,

I've created JDK8 backport [1] for this issue and will work on it in the 
upcoming months.


Best Regards,

Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8162941


On 02/08/16 08:33, KUBOTA Yuji wrote:

Hi all,

Could you let me know when this fix will be backport to JDK 8?
We need this backport to migrate our system from JDK 7 to JDK 8.

Thanks,
Yuji

2016-02-10 10:17 GMT+09:00 KUBOTA Yuji :

Hi Miroslav,

Thank you for your sponsor! : https://bugs.openjdk.java.net/browse/JDK-8146086

Can I ask the schedule when does this fix backport to JDK8 ?

Thanks,
Yuji

2015-12-02 22:39 GMT+09:00 Miroslav Kos :

Hi Yuji,
thanks for the patch - it fixes the issue and looks ok to me. I'll integrate
it to standalone JAX-WS repo and it will be integrated into openjdk during
next syncup.

Thanks
Miran




On 01/12/15 11:11, KUBOTA Yuji wrote:

Hi Miroslav and all,

Could you please review the below issue and patch?

I got the advice by Alan at net-dev. So I want to ask you.
http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html


I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
community. This's second times from JavaOne14. :)

We find an unexpected exception in JAX-WS, so I write a patch to fix it.
We think that this issue may block the migration to JDK9 from JDK7.

If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
following test code, JDK9 (and JDK8) returns "java.net.BindException:
Address already in use.” as the below. But JDK7 does NOT return the
exception.

- Test code for reproduce
---
import javax.jws.*;
import javax.xml.ws.*;

public class WSTest{

@WebService
public static class Method1{
  @WebMethod
  public String getMethod1Value(){
return "from Method1";
  }
}

@WebService
public static class Method2{
  @WebMethod
  public String getMethod2Value(){
return "from Method2";
  }
}

public static void main(String[] args) throws Exception{
  Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1;,
   new
Method1());
  Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2;,
   new
Method2());

  System.out.println("Sleep 3 secs...");

  Thread.sleep(3000);

  endPoint2.stop();
  endPoint1.stop();
}

}
---

- StackTrace
---
Exception in thread "main"
com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
Error: java.net.BindException: Address already in use
  at
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
  at
com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
  at
com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
  at
com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
  at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
  at wstest.WSTest.main(WSTest.java:27)
Caused by: java.net.BindException: Address already in use
  at sun.nio.ch.Net.bind0(Native Method)
  at sun.nio.ch.Net.bind(Net.java:432)
  at sun.nio.ch.Net.bind(Net.java:424)
  at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
  at
sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
  at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
  at
sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
  at
sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
  at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
  at
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
  ... 5 more
-

To publishes the Endpoint, JAX-WS checks whether the HttpContext has
been created by given address, then creates a HttpContext if do not
exist.
If we sets 0.0.0.0 as given address, JAX-WS checks by
ServerSocket#getLocalSocketAddress() (server local address), so
returns BindException when 0.0.0.0 has been blinded already.

Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think
about above situation. And JAX_WS-941 does not back port to JDK7.

So I write a patch which is based jdk9/dev/jaxws
(changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941.

Please review this patch :)

[1]: https://java.net/jira/browse/JAX_WS-941

- Patch
---
diff -r 2d84c6f4cbba

src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
---
a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Thu Oct 22 08:47:47 2015 -0700
+++

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

[Daniel Fuchs]

Hi Frank,

I looked at the diffs of the diffs between webrev.02 and webrev.03 and
it looks good to me.

+1 - provided all tests pass :-)

But I have the same question than Joe: aren't all the test supposed
to run twice: once with security manager and once without?
(except for those test that might explicitly require a security manager)

best regards,

-- daniel

On 03/08/16 11:12, Frank Yuan wrote:

Hi Joe

Thank you for your review!

I updated the tests according to the latest comments as well as had 
unittest/transform/TransformerTest.java up to date, please check
http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/


Thanks
Frank

-Original Message-
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests



On 8/2/16, 5:30 AM, Daniel Fuchs wrote:

Hi Frank,

I am intrigued by these change which do not seem
to have anything to do with the rest. I mean, I'm not opposed
as long as they are intended and that Joe validates them:




http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram
es.html



118 spf.setNamespaceAware(false);


Not sure why this was changed.




http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra
mes.html




The test itself wasn't very clear on the content it tests. If it only
verifies whether a resolver is used as is said, then this and related
changes in ResolverTest and publish.xml are fine. To the extent it
verifies, it didn't have to output to a file.




http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h
tml




We have to let Frank explain why namespace was turned off for these
tests :-)  In this case, XMLReaderNSTableTest. In general, I would say
enabling security shouldn't change tests or gold files in this case.



http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html

This looks like a desirable change - but what does it have to do
with enabling security manager?


Probably to remove the reference to that particular server?  Seems to be
fine as a cleanup. Again, it (the original test) only verifies a resolve
is used, it didn't even need to write out a file to prove that.


Also:


http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html


  70
tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions;,
true);

Is this needed only when there is a security manager?


Yes, when Security Manager is present, this feature is turned off by
default.




http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html



 119 /*
 120 addPermission(new RuntimePermission("getClassLoader"));
 121 addPermission(new RuntimePermission("createClassLoader"));
 122 addPermission(new
RuntimePermission("createSecurityManager"));
 123 addPermission(new RuntimePermission("modifyThread"));
 124 addPermission(new PropertyPermission("*", "read,write"));
 125
 126 addPermission(new RuntimePermission("setIO"));
 127 addPermission(new
RuntimePermission("setContextClassLoader"));
 128 addPermission(new
RuntimePermission("accessDeclaredMembers"));*/


Please remove before pushing.




test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml
test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl

It seems these two files have been removed, but shouldn't they have
been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform
instead?
I see they are used by
test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java

Did you forget to hg add them?




Otherwise the new JAXPPolicyManager & its Policy implementation
look good. This is much simpler and better than the first
iteration :-)

This was a *very* long patch - so congratulations for seeing
this through!


Very long patch, indeed! Thanks for the great effort!  Very well done
with the unified Policy/Permission management.

Best,
Joe



cheers,

-- daniel


On 02/08/16 11:20, Frank Yuan wrote:

Hi Joe and Daniel

I have finished the rework as your comments, please check
http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/

JAXP tests use Policy classes, as well as 3 other patterns provided
by JAXPTestUtilities:
1. runWithAllPerm methods, are only used for user setup code, never
run jaxp code with them.
2. 

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

[Frank Yuan]

Hi Joe

Thank you for your review! 

I updated the tests according to the latest comments as well as had 
unittest/transform/TransformerTest.java up to date, please check
http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/


Thanks
Frank 

-Original Message-
From: Joe Wang [mailto:huizhe.w...@oracle.com] 
Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests



On 8/2/16, 5:30 AM, Daniel Fuchs wrote:
> Hi Frank,
>
> I am intrigued by these change which do not seem
> to have anything to do with the rest. I mean, I'm not opposed
> as long as they are intended and that Joe validates them:
> 
>
>
http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram
es.html 
>
>
> 118 spf.setNamespaceAware(false);

Not sure why this was changed.
>
>
http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra
mes.html 
>

The test itself wasn't very clear on the content it tests. If it only 
verifies whether a resolver is used as is said, then this and related 
changes in ResolverTest and publish.xml are fine. To the extent it 
verifies, it didn't have to output to a file.
>
>
http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h
tml 
>

We have to let Frank explain why namespace was turned off for these 
tests :-)  In this case, XMLReaderNSTableTest. In general, I would say 
enabling security shouldn't change tests or gold files in this case.

>
> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html
>  
>
> This looks like a desirable change - but what does it have to do
> with enabling security manager?

Probably to remove the reference to that particular server?  Seems to be 
fine as a cleanup. Again, it (the original test) only verifies a resolve 
is used, it didn't even need to write out a file to prove that.
>
> Also:
> 
>
> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html
>  
>
>
>   70 
> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions;,
>  
> true);
>
> Is this needed only when there is a security manager?

Yes, when Security Manager is present, this feature is turned off by 
default.
>
> 
>
> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html
>  
>
>
>
>  119 /*
>  120 addPermission(new RuntimePermission("getClassLoader"));
>  121 addPermission(new RuntimePermission("createClassLoader"));
>  122 addPermission(new 
> RuntimePermission("createSecurityManager"));
>  123 addPermission(new RuntimePermission("modifyThread"));
>  124 addPermission(new PropertyPermission("*", "read,write"));
>  125
>  126 addPermission(new RuntimePermission("setIO"));
>  127 addPermission(new 
> RuntimePermission("setContextClassLoader"));
>  128 addPermission(new 
> RuntimePermission("accessDeclaredMembers"));*/
>
>
> Please remove before pushing.
>
>
> 
>
> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml
> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl
>
> It seems these two files have been removed, but shouldn't they have
> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform
> instead?
> I see they are used by 
> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java
>
> Did you forget to hg add them?
>
> 
>
>
> Otherwise the new JAXPPolicyManager & its Policy implementation
> look good. This is much simpler and better than the first
> iteration :-)
>
> This was a *very* long patch - so congratulations for seeing
> this through!

Very long patch, indeed! Thanks for the great effort!  Very well done 
with the unified Policy/Permission management.

Best,
Joe

>
> cheers,
>
> -- daniel
>
>
> On 02/08/16 11:20, Frank Yuan wrote:
>> Hi Joe and Daniel
>>
>> I have finished the rework as your comments, please check 
>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/
>>
>> JAXP tests use Policy classes, as well as 3 other patterns provided 
>> by JAXPTestUtilities:
>> 1. runWithAllPerm methods, are only used for user setup code, never 
>> run jaxp code with them.
>> 2. tryRunWithPolicyManager method, is used to run some test methods 
>> with security manager and run the others without security
>> manager in single test class
>> 3. runWithTmpPermission methods, which may run jaxp code with some 
>> limited 

JDK 9 RFR of JDK-8161024: Remove intermittent key from java/lang/Runtime/exec/LotsOfOutput.java

[Amy Lu]

java/lang/Runtime/exec/LotsOfOutput.java

This test was failing intermittently (JDK-8078582 JDK-8086117). 
Mentioned issues have been resolved and no open bug (no failure 
reported) till now.


This patch is to remove @key intermittent from the test.

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


Thanks,
Amy

--- old/test/java/lang/Runtime/exec/LotsOfOutput.java   2016-08-03 
15:47:45.0 +0800
+++ new/test/java/lang/Runtime/exec/LotsOfOutput.java   2016-08-03 
15:47:45.0 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,7 +25,6 @@
  * @test
  * @bug 4369826 8078582
  * @summary Process with lots of output should not crash VM
- * @key intermittent
  * @author kladko
  */
 

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

[David Holmes]

On 2/08/2016 4:46 AM, Kim Barrett wrote:

This updated webrev addresses the concerns around initialization order
for Throwable and OutOfMemoryError.  It doesn't address the VM API
used by the reference processor thread; that will be in a later
webrev.

New webrevs:
full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/
incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/

The jdk tree is unchanged from webrev.01.

I've backed out the change to initialize_java_lang_classes.  (To
verify this, look at the runtime/thread.cpp in the full webrev.)

Instead, Universe::gen_out_of_memory_error now also requires Throwable
to be initialized before it will attempt to fill in the stack trace.
This means that VM generated OOMEs occurring early in initialization
won't have a stack trace.


This change looks good to me.

Thanks,
David


An alternative that I considered was to remove the assert at the end
of fill_in_stack_trace_of_preallocated_backtrace that requires
java_lang_Throwable;:unassigned_stacktrace() to return non-NULL.  I
did some testing that seemed to work and provide stacktraces, relying
on code in the Throwable class that special cases this "out of
protocol" state.  However, having read some of the history around that
(JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to
have been intended to be temporary, and expected to be removed.
(Though I didn't find an RFE for doing so, and I'm not doing so here.)
Even if we decided it wasn't going to be removed, this approach seems
somewhat fragile.

[Note to Coleen: This is the reverse of what you and I talked about a
few days ago; I hadn't reviewed the history carefully then.]