From joe.darcy at oracle.com Tue Dec 1 01:32:52 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 30 Nov 2015 17:32:52 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56586A7A.2040007@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> Message-ID: <565CF8C4.1020208@oracle.com> Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: > On 2015-11-25 02:54, Iris Clark wrote: >> Hi. >> >> Please review the new classes jdk.Version and jdk.OracleVersion. >> These are >> simple Java APIs to parse, validate, and compare version numbers. >> >> Bug >> >> 8072379: Implement jdk.Version and jdk.OracleVersion >> https://bugs.openjdk.java.net/browse/JDK-8072379 >> >> Webrev >> >> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > > Hi Iris, > > I thought the end agreement was that the + should always be present > even if build was empty, if opt was present but not pre. That is, > "9-foo" should unambigiously parse as vnum=9 and pre="foo", while > "9-+foo" should umambigously parse as vnum=9 and opt="foo". The > javadoc does not seem to reflect this. > > I've also had to read and re-read the regexp and parsing logic in the > constructor to convince myself that this (most likely) will be > correctly handled. Perhaps a few comments around this would be helpful? > > The comparison of two version strings which differs only in "pre" does > not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared > numerically when they consist only of digits, and lexiographically > otherwise. Numeric identifiers are considered to be less than > non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a > > I'm also surprised that equals() does not produce the same result as > compareTo(). If opt is to be ignored, surely it should be so in > equals() as well? > I'm one of the maintainers of BigDecimal, one of the few Comparable classes in the JDK where compareTo is "inconsistent with equals" (see "Effective Java, 2nd edition", Item 12 - Considering implementing Comparable). It is consistently surprising to users if compareTo is inconsistent with equals ;-) Therefore, if at all possible it is preferable to have compareTo be *consistent* rather than *inconsistent* with equals; although there are cases where the inconsistency is necessary or at least defensible. I suggest providing multiple compareFoo methods for version that did or did not include certain components, some of these could be consistent with equals and others not. HTH, -Joe From gil at azul.com Tue Dec 1 02:58:16 2015 From: gil at azul.com (Gil Tene) Date: Tue, 1 Dec 2015 02:58:16 +0000 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> Message-ID: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Update: After some significant back-and-forth between Doug and I on naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we think is a good spec and name selection for this thing. We're proposing to add a new static method to the Runtime class: class Runtime { /... /** * Method signifying that the caller is momentarily unable to * progress until the occurrence of one or more actions of one or * more other activities. When invoked within each iteration, this * method typically improves performance of spin wait loop * constructions. */ public static void onSpinWait() {}; } See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk. ? Gil. From huaming.li at oracle.com Tue Dec 1 03:37:40 2015 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 1 Dec 2015 11:37:40 +0800 Subject: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service Message-ID: <565D1604.3000508@oracle.com> Hi all, Would you please help to review the test development of JDK-8144215 : Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service. webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ Thank you -Hamlin From staffan.larsen at oracle.com Tue Dec 1 09:22:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Dec 2015 10:22:48 +0100 Subject: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting In-Reply-To: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com> References: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com> Message-ID: <7F734C89-75CE-462D-B73D-11CFEC42B30F@oracle.com> Looks good and sorry for the delay. Thanks, /Staffan > On 24 nov. 2015, at 20:13, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ >> 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg > > Hi, > > Could you please review the webrev[0] for JEP 279[1]? > > The scope of the JEP is an implementation of a library which uses jtreg timeout handler and observer extension points to collect information about environment in case of test failures (including timeouts) and about test processes in case of timeouts. This data is then presented together with the test failure to simplify analysis. > > To make it easier to specify which tools should be run by the library on which platform when a test failure or timeout occurs, we use properties files to configure the library. Each platform family uses its own property file (named .properties) and common.properties, which contains platform independent tools, such as jps. Using property files allows to easily extend the tools that are used to collect information on test failure or timeout in the future. See the JEP for a more thorough overview of the collected data. Currently, we are using the following tools: > - on all platforms[3]: jps, jstack, jmap, jinfo, jcmd > - on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, dmesg, sysctl, top, free, vmstat, netstat > - on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat > - on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, df, env, dmesg, sysctl, ps, top, vm_stat, netstat > - on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, tasklist, ps, top, free, vmstat, openfiles, netstat > > More information can be found in the JEP[1] and README[2]. > > The library integration into makefiles will be done later as the fix for JDK-8132962[8]. > > [0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ > [1] https://bugs.openjdk.java.net/browse/JDK-8075621 > [2] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html > [3] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html > [4] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html > [5] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html > [6] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html > [7] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html > [8] https://bugs.openjdk.java.net/browse/JDK-8132962 > > Thanks, > ? Igor From kubota.yuji at gmail.com Tue Dec 1 10:11:08 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 1 Dec 2015 19:11:08 +0900 Subject: Unexpected BindException in Endpoint.publish Message-ID: 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 +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Tue Oct 27 19:48:35 2015 +0900 @@ -38,6 +38,7 @@ import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.logging.Logger; +import java.util.Optional; /** * Manages all the WebService HTTP servers created by JAXWS runtime. @@ -81,24 +82,38 @@ synchronized(servers) { state = servers.get(inetAddress); if (state == null) { - logger.fine("Creating new HTTP Server at "+inetAddress); - // Creates server with default socket backlog - server = HttpServer.create(inetAddress, 0); - server.setExecutor(Executors.newCachedThreadPool()); - String path = url.toURI().getPath(); - logger.fine("Creating HTTP Context at = "+path); - HttpContext context = server.createContext(path); - server.start(); + final int finalPortNum = port; + Optional stateOpt = + servers.values() + .stream() + .filter(s -> s.getServer() + .getAddress() + .getPort() == finalPortNum) + .findAny(); - // we have to get actual inetAddress from server, which can differ from the original in some cases. - // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, - // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address - inetAddress = server.getAddress(); + if (inetAddress.getAddress().isAnyLocalAddress() && + stateOpt.isPresent()) { + state = stateOpt.get(); + } else { + logger.fine("Creating new HTTP Server at "+inetAddress); + // Creates server with default socket backlog + server = HttpServer.create(inetAddress, 0); + server.setExecutor(Executors.newCachedThreadPool()); + String path = url.toURI().getPath(); + logger.fine("Creating HTTP Context at = "+path); + HttpContext context = server.createContext(path); + server.start(); - logger.fine("HTTP server started = "+inetAddress); - state = new ServerState(server, path); - servers.put(inetAddress, state); - return context; + // we have to get actual inetAddress from server, which can differ from the original in some cases. + // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, + // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address + inetAddress = server.getAddress(); + + logger.fine("HTTP server started = "+inetAddress); + state = new ServerState(server, path); + servers.put(inetAddress, state); + return context; + } } } server = state.getServer(); --- Thanks, Yuji From sgehwolf at redhat.com Tue Dec 1 10:17:09 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 11:17:09 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1447061525.3551.3.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> Message-ID: <1448965029.4309.10.camel@redhat.com> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > I believe this updated webrev addresses all concerns and > > incorporates > > suggestions brought up by Jaroslav and Daniel. > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > this > > as well? Thank you! > > Ping? Friendly reminder that I still need reviewers and a sponsor for > this. Anyone? > Thanks, > Severin > > > Cheers, > > Severin > > > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > > Hi, > > > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > > Hi Severin, > > > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > > that's > > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > > maybe > > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > > > I will let serviceability team members comment on the > > > > > > hotspot > > > > > > changes. > > > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > > Factory) > > > > > > and > > > > > > ssf??(Server Socket Factory) variables rather than > > > > > > introduce > > > > > > the > > > > > > two > > > > > > new variables rmiServerSocketFactory and > > > > > > rmiClientSocketFactory. > > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > > variable, > > > > > > if that makes the code more readable. > > > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > > work, > > > > > > the client socket factory will be serialized and sent to > > > > > > the > > > > > > client > > > > > > side. This is problematic for interoperability, as the > > > > > > class > > > > > > may > > > > > > not > > > > > > present in the remote client - if the remote client is e.g. > > > > > > jdk > > > > > > 8. > > > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > > doesn't do > > > > > > anything useful - so I would suggest to simply get rid of > > > > > > it, > > > > > > and > > > > > > only > > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > > > Tests: > > > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > > scripts > > > > > > rather than introducing new ones :-) > > > > > > Could the test be rewritten in pure java using the Process > > > > > > API? > > > > > > > > > > > > I believe there's even a test library that will let you do > > > > > > that > > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > > (see ProcessTools.java) > > > > > > > > It'll take me a bit to rewrite the test in pure Java, but > > > > should > > > > be > > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > > > Other: > > > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > > src/java.management/share/conf/management.properties > > > > > > > > Docs have been updated > > > > in src/java.management/share/conf/management.properties. > > > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > > related > > > > > to javax.rmi.ssl - someone maintaining this library should > > > > > also > > > > > comment here. > > > > > > > > > > Also, the change is introducing new API (system property) and > > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > > public > > > > > constructors) so compatibility review process will have to be > > > > > involved. > > > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > > this > > > > process. Note that the intent would be to get this backported > > > > to > > > > JDK 8. > > > Not much for you. But for the potential Oracle sponsor this means > > > she > > > will have to remember to go through some extra hoops before > > > integrating your patch. > > > > I see. Thanks for clarifying it. > > > > > -JB- > > > > > > > > > > > New webrev at: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > -JB- > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > > the > > > > > > > JMX > > > > > > > agent > > > > > > > binds to the wildcard address by default, preventing > > > > > > > users > > > > > > > to > > > > > > > use > > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > > Given > > > > > > > a > > > > > > > host > > > > > > > with local network interfaces, 192.168.0.1 and > > > > > > > 192.168.0.2 > > > > > > > say, > > > > > > > it's > > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > > but > > > > > > > to > > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > > the > > > > > > > above > > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > > that > > > > > > > the > > > > > > > second > > > > > > > Java process would get a "Connection refused" error > > > > > > > because > > > > > > > another > > > > > > > process has already been bound to the specified JMX/RMI > > > > > > > port > > > > > > > pairs. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > 64 > > > > > > > 25 > > > > > > > 769/ > > > > > > > 00/ > > > > > > > > > > > > > > Testing done: > > > > > > > jdk_jmx and jdk_management tests all pass after this > > > > > > > change > > > > > > > (no > > > > > > > regressions). There is also a new JTREG test which fails > > > > > > > prior > > > > > > > this > > > > > > > change and passes after. Updates to the diagnostic > > > > > > > command > > > > > > > have > > > > > > > been > > > > > > > tested manually. > > > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot > > > > > > > changes > > > > > > > should get > > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > > it's > > > > > > > only a > > > > > > > doc-update for the new JDK property in the relevant > > > > > > > diagnostic > > > > > > > command. > > > > > > > > > > > > > > Could someone please review and sponsor this change? > > > > > > > Please > > > > > > > let > > > > > > > me know > > > > > > > if there are questions. > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > From paul.sandoz at oracle.com Tue Dec 1 10:28:28 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Dec 2015 11:28:28 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> Message-ID: <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> > On 30 Nov 2015, at 23:33, Paul Sandoz wrote: > > >> On 30 Nov 2015, at 23:05, Christian Tornqvist wrote: >> >> Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. >> > > jtreg comes bundled with testng so what is there to reduce? > Here is an analogy: jtreg is to testng as launcher is to library They are complementary to each other i.e. think of testng as an implicit @library that helps one better organize tests and report errors. ? Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. Paul. From daniel.fuchs at oracle.com Tue Dec 1 10:32:50 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Dec 2015 11:32:50 +0100 Subject: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping. In-Reply-To: <565C32EC.7050806@oracle.com> References: <565C32EC.7050806@oracle.com> Message-ID: <565D7752.4060203@oracle.com> Hi Hamlin, I see that you're going to push a test for this with JDK-8144215; Looks good to me. Do you need a sponsor for this fix? best regards, -- daniel On 30/11/15 12:28, Hamlin Li wrote: > Hi all, > > Would you please help to review for > http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug > https://bugs.openjdk.java.net/browse/JDK-8144214. > > Thank you > -Hamlin > From paul.sandoz at oracle.com Tue Dec 1 10:36:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 Dec 2015 11:36:45 +0100 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> > On 1 Dec 2015, at 03:58, Gil Tene wrote: > > Update: After some significant back-and-forth between Doug and I on naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we think is a good spec and name selection for this thing. We're proposing to add a new static method to the Runtime class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } > Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP. If you like I can help guide this through the JEP process. > See updated details, including a link to the updated JEP draft, as well as links to working prototype implementations, webrevs against OpenJDK9b94, and example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest . All names have changed to reflect the new naming (onSpinWait, -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). > > As an interesting stat, the total changes in the WebRevs amount to 78 added lines (across 14 files) , and 0 lines removed or changed. Hopefully a good indication of relatively low footprint and risk. > I agree, the JDK and hotspot patches (for x86 support) are quite small. Paul. From daniel.fuchs at oracle.com Tue Dec 1 10:40:52 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Dec 2015 11:40:52 +0100 Subject: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service In-Reply-To: <565D1604.3000508@oracle.com> References: <565D1604.3000508@oracle.com> Message-ID: <565D7934.8080201@oracle.com> Hi Hamlin, You should probably create a new open RFE for pushing this new test. I'm not sure we can use internal task ids in commit/push comments. From looking at the test, it would be preferable to create the loggers after setting up the stub that pretend that the VM is not yet booted. In other words - in BootstrapLoggerAPIsTest lines 53-56 should preferably be moved after line 74. best regards, -- daniel On 01/12/15 04:37, Hamlin Li wrote: > Hi all, > > Would you please help to review the test development of JDK-8144215 > : Test development > task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and > Service. > webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ > > Thank you > -Hamlin From chris.hegarty at oracle.com Tue Dec 1 10:41:10 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Dec 2015 10:41:10 +0000 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <5656F463.9080804@oracle.com> References: <5656F463.9080804@oracle.com> Message-ID: On 26 Nov 2015, at 12:00, Aleksey Shipilev wrote: > On 11/26/2015 12:55 PM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ > > Both JDK and Hotspot changes look good to me. +1, both webrevs look good to me. Thanks for fixing my shortcut when moving Unsafe. -Chris. From peter.levart at gmail.com Tue Dec 1 11:22:50 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 1 Dec 2015 12:22:50 +0100 Subject: RFE Pre-review: Support for cloning exceptions Message-ID: <565D830A.10508@gmail.com> Hi, There are at least two places in java.util.concurrent where it would be beneficial if java.lang.Throwable was Cloneable: - ForkJoinTask::getException() returns original exception thrown by the computation of the task when the task is completed exceptionally. The same exception is re-thrown in ForkJoinTask::join() or ForkJoinTask::invoke(). In order for the re-thrown exception to contain meaningful and non-misleading stack-trace, the original exception is attempted to be replaced with the exception of the same type, with original exception attached as the cause, so both stack-traces are visible - the original stack trace and the stack-trace of the thread executing join() or invoke(). In order to do that, ForkJoinTask resorts to using reflection and trying to construct new exception by invoking a constructor on the j.l.Class of the original exception. It 1st tries the constructor taking j.l.Throwable parameter (assumes it will be the cause) and if that doesn't work, it tries the no-arg constructor followed by calling initCause() on the result. This usually works for public exceptions with suitable public constructors, but is not guaranteed. So in case it doesn't work, it simply re-throws the original exception with the original stack-trace, which hides the point at which it was re-thrown (at join() or invoke()). I assume this will become more problematic with jigsaw where constructors of non-exported exceptions will become inaccessible. - CompletableFuture::whenComplete[Async]() are methods that return: "...a new CompletionStage with the same result or exception as this stage, that executes the given action when this stage completes...". Given 'action' is a BiConsumer receiving the result or exception from 'this' stage, so it can act as a clean-up action. If this cleanup throws an exception, it becomes the result of the returned stage unless 'this' stage also completes with exception. Like in try-with-resources, the exception thrown in the body of try-with-resources statement has precedence over clean-up exception. Clean-up exception is added as suppressed exception. In CompletableFuture this presents a problem, because adding a suppressed exception to the exception of previous stage effectively modifies the result of the previous stage that has already completed. This is undesirable. So I would like to ask for feedback on a proposal to add cloning support to java.lang.Throwable and also how to proceed if this turns out to be acceptable (perhaps a CCC request?). The proposal is as follows: - add "implements Cloneable" to the j.l.Throwable - add the following public static method to j.l.Throwable: /** * Returns a {@link Object#clone() clone} of given {@code exception} * which shares all state with original exception (shallow clone) and is * augmented in the following way: *

* If {@code resetCause} parameter is {@code true}, then clone's * {@link #getCause() cause} is reset to an uninitialized state so it can be * {@link #initCause(Throwable) initialized} again. If {@code resetCause} * parameter is {@code false}, then clone's cause is inherited from original * exception (either initialized or uninitialized). *

* If {@code resetSuppressed} parameter is {@code true} and original exception * has suppression enabled, then clone's suppressed exceptions are cleared. * If {@code resetSuppressed} parameter is {@code false} * (or original exception has suppression disabled) then clone's * suppressed exceptions are inherited from original exception (or clone's * suppression is disabled too). In either case, clone's suppressed * exceptions are independent of original exception's suppressed * exceptions. Any further {@link #addSuppressed(Throwable) additions} to * the clone's suppressed exceptions do not affect original exception's * suppressed exceptions and vice versa. * * @param exception the exception to clone. * @param the type of exception * @param resetCause if {@code true}, clone's cause is reset to an * uninitialized state. * @param resetSuppressed if {@code true} and original exception has suppression * enabled, clone's suppressed exceptions are cleared. * @return shallow clone of given exception augmented according to passed-in * flags. * @since 1.9 */ @SuppressWarnings("unchecked") public static T clone(T exception, boolean resetCause, boolean resetSuppressed) { try { synchronized (exception) { Throwable clone = (Throwable) exception.clone(); if (resetCause) { // reset to uninitialized state clone.cause = clone; } if (clone.suppressedExceptions != null && clone.suppressedExceptions != SUPPRESSED_SENTINEL) { // suppressedExceptions has already been added to // and suppression is enabled clone.suppressedExceptions = resetSuppressed ? new ArrayList<>() : new ArrayList<>(clone.suppressedExceptions); } return (T) clone; } } catch (CloneNotSupportedException e) { throw new InternalError(e); } } In ForkJoinTask the code to construct the re-thrown exception could be reduce to: Throwable original = ...; Throwable rethrown = Throwable.clone(original, true, true).fillInStackTrace().initCause(original); In CompletableFuture::whenComplete[Async] the exceptional result of the new stage in case of both original and cleanup exceptions could be computed as: Throwable original = ...; Throwable cleanup = ...; Throwable result = Throwable.clone(original, false, false); result.addSuppressed(cleanup); So what do you think of adding such feature and do you see any problems with it? Regards, Peter From jaroslav.bachorik at oracle.com Tue Dec 1 11:33:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 12:33:38 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1448965029.4309.10.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> Message-ID: <565D8592.6020701@oracle.com> On 1.12.2015 11:17, Severin Gehwolf wrote: > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev with jtreg test in Java: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>> >>> I believe this updated webrev addresses all concerns and >>> incorporates >>> suggestions brought up by Jaroslav and Daniel. >>> >>> I'm still looking for a sponsor and a hotspot/servicability-dev >>> reviewer. Could somebody maintaining javax.rmi.ssl have a look at >>> this >>> as well? Thank you! >> >> Ping? Friendly reminder that I still need reviewers and a sponsor for >> this. > > Anyone? I'm sorry for not spotting this earlier: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html * L442 - the log would contain 'com.sun.management.jmxremote.host = null' if host is not specified; might be better not to print this out at all Other than that the change looks good to me. If no one else is volunteering I may sponsor this change. Cheers, -JB- > >> Thanks, >> Severin >> >>> Cheers, >>> Severin >>> >>> On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: >>>> On 2.11.2015 19:06, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Thanks Jaroslav and Daniel for the reviews! Comments inline. >>>>> >>>>> On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: >>>>>> Hi, >>>>>> >>>>>> On 2.11.2015 16:19, Daniel Fuchs wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> Adding serviceability-dev at openjdk.java.net into the loop - >>>>>>> that's >>>>>>> a better alias than hotspot-dev for this kind of changes - >>>>>>> maybe >>>>>>> someone from serviceability-dev will offer to sponsor :-) >>>>>>> >>>>>>> I will let serviceability team members comment on the >>>>>>> hotspot >>>>>>> changes. >>>>>>> >>>>>>> ConnectorBootstrap.java >>>>>>> >>>>>>> I have one suggestion and one concern: >>>>>>> >>>>>>> Suggestion: I would suggest to reuse 'csf' (Client Socket >>>>>>> Factory) >>>>>>> and >>>>>>> ssf (Server Socket Factory) variables rather than >>>>>>> introduce >>>>>>> the >>>>>>> two >>>>>>> new variables rmiServerSocketFactory and >>>>>>> rmiClientSocketFactory. >>>>>>> You might want to create a new boolean 'useSocketFactory' >>>>>>> variable, >>>>>>> if that makes the code more readable. >>>>>>> >>>>>>> Concern: If I understand correctly how RMI socket factories >>>>>>> work, >>>>>>> the client socket factory will be serialized and sent to >>>>>>> the >>>>>>> client >>>>>>> side. This is problematic for interoperability, as the >>>>>>> class >>>>>>> may >>>>>>> not >>>>>>> present in the remote client - if the remote client is e.g. >>>>>>> jdk >>>>>>> 8. >>>>>>> >>>>>>> As far as I can see, your new DefaultClientSocketFactory >>>>>>> doesn't do >>>>>>> anything useful - so I would suggest to simply get rid of >>>>>>> it, >>>>>>> and >>>>>>> only >>>>>>> set the Server Socket Factory when SSL is not involved. >>>>> >>>>> Thanks. Fixed in updated webrev. >>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Concerning the tests - we're trying to get rid of shell >>>>>>> scripts >>>>>>> rather than introducing new ones :-) >>>>>>> Could the test be rewritten in pure java using the Process >>>>>>> API? >>>>>>> >>>>>>> I believe there's even a test library that will let you do >>>>>>> that >>>>>>> easily jdk/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> (see ProcessTools.java) >>>>> >>>>> It'll take me a bit to rewrite the test in pure Java, but >>>>> should >>>>> be >>>>> fine. This is not yet fixed in the updated webrev. >>>>> >>>>>>> Other: >>>>>>> >>>>>>> Also - I believe the new option should be documented in: >>>>>>> src/java.management/share/conf/management.properties >>>>> >>>>> Docs have been updated >>>>> in src/java.management/share/conf/management.properties. >>>>> >>>>>> I share Daniel's concerns. Also, the part of the changeset is >>>>>> related >>>>>> to javax.rmi.ssl - someone maintaining this library should >>>>>> also >>>>>> comment here. >>>>>> >>>>>> Also, the change is introducing new API (system property) and >>>>>> changing the existing one (adding SslRmiServerSocketFactory >>>>>> public >>>>>> constructors) so compatibility review process will have to be >>>>>> involved. >>>>> >>>>> OK. What exactly is there for me to do? I'm not familiar with >>>>> this >>>>> process. Note that the intent would be to get this backported >>>>> to >>>>> JDK 8. >>>> Not much for you. But for the potential Oracle sponsor this means >>>> she >>>> will have to remember to go through some extra hoops before >>>> integrating your patch. >>> >>> I see. Thanks for clarifying it. >>> >>>> -JB- >>>> >>>>> >>>>> New webrev at: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> -JB- >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 02/11/15 11:38, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is a patch addressing JDK-6425769. The issue is that >>>>>>>> the >>>>>>>> JMX >>>>>>>> agent >>>>>>>> binds to the wildcard address by default, preventing >>>>>>>> users >>>>>>>> to >>>>>>>> use >>>>>>>> system properties for JMX agents on multi-homed hosts. >>>>>>>> Given >>>>>>>> a >>>>>>>> host >>>>>>>> with local network interfaces, 192.168.0.1 and >>>>>>>> 192.168.0.2 >>>>>>>> say, >>>>>>>> it's >>>>>>>> impossible to start two JMX agents binding to fixed ports >>>>>>>> but >>>>>>>> to >>>>>>>> different network interfaces, 192.168.0.1:{9111,9112} and >>>>>>>> 192.168.0.2:{9111,9112} say. >>>>>>>> >>>>>>>> The JDK would bind to all local interfaces by default. In >>>>>>>> the >>>>>>>> above >>>>>>>> example to 192.168.0.1 *and* 192.168.0.2. The effect is >>>>>>>> that >>>>>>>> the >>>>>>>> second >>>>>>>> Java process would get a "Connection refused" error >>>>>>>> because >>>>>>>> another >>>>>>>> process has already been bound to the specified JMX/RMI >>>>>>>> port >>>>>>>> pairs. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- >>>>>>>> 64 >>>>>>>> 25 >>>>>>>> 769/ >>>>>>>> 00/ >>>>>>>> >>>>>>>> Testing done: >>>>>>>> jdk_jmx and jdk_management tests all pass after this >>>>>>>> change >>>>>>>> (no >>>>>>>> regressions). There is also a new JTREG test which fails >>>>>>>> prior >>>>>>>> this >>>>>>>> change and passes after. Updates to the diagnostic >>>>>>>> command >>>>>>>> have >>>>>>>> been >>>>>>>> tested manually. >>>>>>>> >>>>>>>> I understand that, if approved, the JDK and hotspot >>>>>>>> changes >>>>>>>> should get >>>>>>>> pushed together? Hotspot changes are fairly trivial since >>>>>>>> it's >>>>>>>> only a >>>>>>>> doc-update for the new JDK property in the relevant >>>>>>>> diagnostic >>>>>>>> command. >>>>>>>> >>>>>>>> Could someone please review and sponsor this change? >>>>>>>> Please >>>>>>>> let >>>>>>>> me know >>>>>>>> if there are questions. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vitalyd at gmail.com Tue Dec 1 12:16:24 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 1 Dec 2015 07:16:24 -0500 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: Minor quibble, but why the "on" prefix in the name? Maybe just me, but onXYX is typically used for event notification style APIs. Also, the "wait" part seems inappropriate as the method itself isn't doing any waiting. What was wrong with the original spinLoopHint name? Or cpuRelax()? sent from my phone On Nov 30, 2015 9:59 PM, "Gil Tene" wrote: > Update: After some significant back-and-forth between Doug and I on naming > and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have > what we think is a good spec and name selection for this thing. We're > proposing to add a new static method to the Runtime class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } > > See updated details, including a link to the updated JEP draft, as well as > links to working prototype implementations, webrevs against OpenJDK9b94, > and example here: > https://github.com/giltene/GilExamples/tree/master/SpinWaitTest < > https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All > names have changed to reflect the new naming (onSpinWait, > -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). > > As an interesting stat, the total changes in the WebRevs amount to 78 > added lines (across 14 files) , and 0 lines removed or changed. Hopefully a > good indication of relatively low footprint and risk. > > ? Gil. > > > > > > From dl at cs.oswego.edu Tue Dec 1 12:43:41 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 1 Dec 2015 07:43:41 -0500 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> <87110734-3922-434C-B2D7-11F9AD0A5D0E@oracle.com> Message-ID: <565D95FD.3000906@cs.oswego.edu> On 12/01/2015 05:36 AM, Paul Sandoz wrote: > >> On 1 Dec 2015, at 03:58, Gil Tene wrote: >> >> class Runtime { /... >> /** >> * Method signifying that the caller is momentarily unable to >> * progress until the occurrence of one or more actions of one or >> * more other activities. When invoked within each iteration, this >> * method typically improves performance of spin wait loop >> * constructions. >> */ >> public static void onSpinWait() {}; >> } >> > > Short and sweet. I like it. I think it would be useful to add an @apiNote with explanatory text similar to that in the motivation section of the JEP. > Or maybe not. Recent experience suggests that it is hard to add a brief explanatory note or usage guidance without saying something confusing or wrong wrt usages focussing on latency, throughput, or power -- these effects may vary across processors with different instructions (possibly just no-op) used to implement it. Not a lot, but this accounts for the bland wording of "typically improves performance". -Doug From rafael.wth at gmail.com Tue Dec 1 12:45:44 2015 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 1 Dec 2015 13:45:44 +0100 Subject: ClassFileTransformer does not apply to anonymous classes Message-ID: Hello everybody, classes that are loaded via Unsafe::defineAnonymousClass are not transformed by a registered ClassFileTransformer. At the same time, it is possible to retransform / redefine such an anonymous classes using the instrumentation API. Here is a rather confusing bug that I encountered when working with an internally used Java agent after upgrading a code base to Java 8: The Java agent attaches at runtime (agentmain). It then registers a ClassFileTransformer that also applies for retransformation. Afterwards, all loaded classes that fullfil a given condition are explicitly registered to be retransformed by the agent. (Doing so, anonymous classes are returned by Instrumentation::getAllLoadedClasses.) This resulted in the following behavior of the agent: a) If the agent was attached after an anonymous class was loaded, the retransformation would apply to an anonymous class. b) If the agent was attached "too early", the (non-re-)transformation would not apply to an anonymous class. I wonder if it is intentional that a ClassFileTransformer is not applied when an anonymous class is loaded. Personally, I find this counter-intuitive, especially when converting anonymous inner classes to lambda expressions where many users of instrumentation do not forsee the behavioral change. It also puts a very unforseeable limit to the instrumentation API. I would therefore like to suggest that ClassFileTransformers are also applied to anonymous classes when Unsafe::defineAnonymousClass is called just as when going via ClassLoader::defineClass. I can tell that this behavior has not only affected me as I had this question comming up by multiple users of my open-source code generation library. What is your view on this? Thank you for your feedback! Best regards, Rafael From sgehwolf at redhat.com Tue Dec 1 13:19:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 14:19:05 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <565D8592.6020701@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> Message-ID: <1448975945.4309.16.camel@redhat.com> Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > On 1.12.2015 11:17, Severin Gehwolf wrote: > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev with jtreg test in Java: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > I believe this updated webrev addresses all concerns and > > > > incorporates > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > > > this > > > > as well? Thank you! > > > > > > Ping? Friendly reminder that I still need reviewers and a sponsor for > > > this. > > > > Anyone? > > I'm sorry for not spotting this earlier: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html > * L442 - the log would contain 'com.sun.management.jmxremote.host =? > null' if host is not specified; might be better not to print this out at all Updated webrev which does not print 'com.sun.management.jmxremote.host = null' if unset: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > Other than that the change looks good to me. If no one else is > volunteering I may sponsor this change. Thank you! Cheers, Severin > Cheers, > > -JB- From Roger.Riggs at Oracle.com Tue Dec 1 14:21:50 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 1 Dec 2015 09:21:50 -0500 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <565CD731.5050706@oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> Message-ID: <565DACFE.10801@Oracle.com> Hi Sherman, On 11/30/2015 6:09 PM, Xueming Shen wrote: > On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >> Converting LocalDate<-> java.util.Date is the question with the >> largest number of votes on SO: >> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >> >> The proposed method is designed to make the conversion easier. It also >> plugs an obvious gap in the API. >> >> While the LocalTime/OffsetTime methods are of lower importance, not >> having them would result in inconsistency between the various classes. >> We've already added factory methods to LocalTime for Java 9, these are >> just the other half of the picture. >> > > I'm not sure I understand the idea of "the proposed method is designed to > make the conversion easier", as the SO is mainly about > j.u.Date->LocalDate, > not the other way around, from LocalDate -> j.u.Date. I think the issue is about *other* libraries that manipulate time via epochSeconds not about j.u.Date conversions. The concern was about performance and creating garbage along the way. Roger > > As I said in the previous email, it might be "common" to use the > j.u.Date to > abstract a "local date" and/or a "local time" (no other choice) before > java.time, > and now there is the need to provide a migration path from those > "local date/ > time" to the j.t.LocalDate/Time. But convert backward from the new > date/time > type to the "old" j.u.Date should not be encouraged (guess this is > also the > consensus we agreed on back to jsr203). > > What are the "factory methods" you are referring to here? JDK-8133079, > The > LocalDate/LocalTime.ofInstant()? > (btw, these two methods see missing the "since 1.9/9" tag) > > It seems to me that the ofInstant(Instant, ZondId) is from a > "super-set" of > date/time to a "sub-set", without any assumption of "default value", > it is > similar to the conversion from zdt->ldt->ld/lt, and I can see the "small" > improvement > > from| > Date input = new Date(); > LocalDatedate > =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| > > to > > |LocalDatedate > =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| > > The proposed pair toEpochSecond() however is doing the other way > around and > with an unusual assumption of the missing date/time piece to a > "default value" > (midnight, the epoch day). > > personally I think > > localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); > localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); > > is clean and good enough to help this backward conversion (with the > addition > of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to > remove that LocalDateTime middle man, with some arrangement. > > -Sherman > >> Note that these methods are specifically not referencing >> java.util.Date itself. Epoch seconds is the appropriate intermediate >> form here, and still widely used. >> >> Stephen >> >> >> >> On 30 November 2015 at 19:36, Xueming Shen >> wrote: >>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>> This is based on user difficulties picked up via Stack Overflow. These >>>> methods aim to provide a simpler and faster approach, particularly for >>>> cases converting to/from java.util.Date. >>> Can you be a little more specific on this one? We now have Instance<=> >>> Date, >>> and considerably we might add LocalDateTime<=> Date with an offset, if >>> really >>> really desired (for performance? to save a Instant object as the >>> bridge?). >>> But I'm >>> a little confused about the connection among LocalDate/LocalTime, epoch >>> seconds >>> and j.u.Date here. Are you saying someone wants to convert >>> >>> j.t.LocalDate -> epoch seconds -> j.u.Date >>> j.t.LocalTime -> epoch seconds -> j.u.Date >>> >>> and uses the converted j.u.Date to represent a local date (date with >>> time >>> part to >>> be 0) and/or the local time (with year/month/day to be epoch time) >>> in the >>> "old" >>> system which only has j.u.Date, and has to use the j.u.Date to >>> abstract the >>> "local >>> date" and "local time"? >>> >>> I think we agreed back to JSR310 that we don't try to add such kind of >>> "bridge/ >>> convenient/utility" methods into the new java.time package, but only >>> in the >>> old date/calendar classes, if really needed. So if these methods are >>> only to >>> help >>> migrate/bridge between the "old" and "new" calendar systems, the >>> java.time >>> might not be the best place for them? >>> >>>> For the time cases, the convention of 1970-01-01 is natural and >>>> commonly used in many codebases. >>>> >>> I'm not sure about that, especially the "natural" part. It might be >>> "common" >>> in >>> the old days if you only have j.u.Date", and might be forced to use >>> 1970-01-01 >>> to fill in the "date" part even when you are really only interested in >>> "time" part >>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>> now we >>> have >>> separate abstract for these different need, I don't see the common >>> need of >>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>> misunderstood >>> something here. >>> >>> -Sherman >>> >>> >>> >>>> Stephen >>>> >>>> >>>> >>>> On 30 November 2015 at 18:15, Xueming Shen >>>> wrote: >>>>> Hi, >>>>> >>>>> While it is kinda understandable to have LocalDate.toEpochSecond(...) >>>>> to get the epoch seconds since 1970.1.1, with the assumption of the >>>>> time is at the midnight of that day. It is strange to have the >>>>> Local/OffsetTime >>>>> to have two public methods with the assumption of the "date" is at >>>>> epoch >>>>> year/month/day. What's the use case/scenario for these two proposed >>>>> methods? >>>>> >>>>> -Sherman >>>>> >>>>> >>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>> The method Javadoc (specs) for each of the three new methods >>>>>> needs to >>>>>> be enhanced. >>>>>> >>>>>> For the date ones it needs to say >>>>>> "The resulting date will have a time component of midnight at the >>>>>> start of the day." >>>>>> >>>>>> For the time ones it needs to say >>>>>> "The resulting time will be on 1970-01-01." >>>>>> >>>>>> Some of the line wrapping in the tests looks like it is not indented >>>>>> correctly. >>>>>> >>>>>> Otherwise looks fine, >>>>>> thanks >>>>>> Stephen >>>>>> >>>>>> >>>>>> On 30 November 2015 at 11:50, nadeesh >>>>>> tv wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a fix for >>>>>>> >>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>> >>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>> >>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>> >>>>>>> -- Thanks and Regards, >>>>>>> Nadeesh TV >>>>> >>>>

>>> > From scolebourne at joda.org Tue Dec 1 14:36:08 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 1 Dec 2015 14:36:08 +0000 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <565DACFE.10801@Oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> Message-ID: As Roger says, these new methods are about performance as well as conversion. While I fully acknowledge the time methods make an assumption, it is not a crazy one, after all 1970-01-01 is just zero. Key I think is it allows: long epochSecs = date.toEpochSeconds(offset) + time.toEpochSeconds(offset); to efficiently merge two objects without garbage. It also means that no-one has to think hard about the conversion, as it is just there. It tends to be when people try to work this stuff out for themselves that they get it wrong. Stephen On 1 December 2015 at 14:21, Roger Riggs wrote: > Hi Sherman, > > On 11/30/2015 6:09 PM, Xueming Shen wrote: >> >> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>> >>> Converting LocalDate<-> java.util.Date is the question with the >>> largest number of votes on SO: >>> >>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>> The proposed method is designed to make the conversion easier. It also >>> plugs an obvious gap in the API. >>> >>> While the LocalTime/OffsetTime methods are of lower importance, not >>> having them would result in inconsistency between the various classes. >>> We've already added factory methods to LocalTime for Java 9, these are >>> just the other half of the picture. >>> >> >> I'm not sure I understand the idea of "the proposed method is designed to >> make the conversion easier", as the SO is mainly about >> j.u.Date->LocalDate, >> not the other way around, from LocalDate -> j.u.Date. > > > I think the issue is about *other* libraries that manipulate time via > epochSeconds > not about j.u.Date conversions. The concern was about performance and > creating garbage along the way. > > Roger > > > >> >> As I said in the previous email, it might be "common" to use the j.u.Date >> to >> abstract a "local date" and/or a "local time" (no other choice) before >> java.time, >> and now there is the need to provide a migration path from those "local >> date/ >> time" to the j.t.LocalDate/Time. But convert backward from the new >> date/time >> type to the "old" j.u.Date should not be encouraged (guess this is also >> the >> consensus we agreed on back to jsr203). >> >> What are the "factory methods" you are referring to here? JDK-8133079, The >> LocalDate/LocalTime.ofInstant()? >> (btw, these two methods see missing the "since 1.9/9" tag) >> >> It seems to me that the ofInstant(Instant, ZondId) is from a "super-set" >> of >> date/time to a "sub-set", without any assumption of "default value", it is >> similar to the conversion from zdt->ldt->ld/lt, and I can see the "small" >> improvement >> >> from| >> Date input = new Date(); >> LocalDatedate >> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >> >> to >> >> |LocalDatedate >> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >> >> The proposed pair toEpochSecond() however is doing the other way around >> and >> with an unusual assumption of the missing date/time piece to a "default >> value" >> (midnight, the epoch day). >> >> personally I think >> >> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >> >> is clean and good enough to help this backward conversion (with the >> addition >> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >> remove that LocalDateTime middle man, with some arrangement. >> >> -Sherman >> >>> Note that these methods are specifically not referencing >>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>> form here, and still widely used. >>> >>> Stephen >>> >>> >>> >>> On 30 November 2015 at 19:36, Xueming Shen >>> wrote: >>>> >>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>> >>>>> This is based on user difficulties picked up via Stack Overflow. These >>>>> methods aim to provide a simpler and faster approach, particularly for >>>>> cases converting to/from java.util.Date. >>>> >>>> Can you be a little more specific on this one? We now have Instance<=> >>>> Date, >>>> and considerably we might add LocalDateTime<=> Date with an offset, if >>>> really >>>> really desired (for performance? to save a Instant object as the >>>> bridge?). >>>> But I'm >>>> a little confused about the connection among LocalDate/LocalTime, epoch >>>> seconds >>>> and j.u.Date here. Are you saying someone wants to convert >>>> >>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>> >>>> and uses the converted j.u.Date to represent a local date (date with >>>> time >>>> part to >>>> be 0) and/or the local time (with year/month/day to be epoch time) in >>>> the >>>> "old" >>>> system which only has j.u.Date, and has to use the j.u.Date to abstract >>>> the >>>> "local >>>> date" and "local time"? >>>> >>>> I think we agreed back to JSR310 that we don't try to add such kind of >>>> "bridge/ >>>> convenient/utility" methods into the new java.time package, but only in >>>> the >>>> old date/calendar classes, if really needed. So if these methods are >>>> only to >>>> help >>>> migrate/bridge between the "old" and "new" calendar systems, the >>>> java.time >>>> might not be the best place for them? >>>> >>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>> commonly used in many codebases. >>>>> >>>> I'm not sure about that, especially the "natural" part. It might be >>>> "common" >>>> in >>>> the old days if you only have j.u.Date", and might be forced to use >>>> 1970-01-01 >>>> to fill in the "date" part even when you are really only interested in >>>> "time" part >>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is now we >>>> have >>>> separate abstract for these different need, I don't see the common need >>>> of >>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>> misunderstood >>>> something here. >>>> >>>> -Sherman >>>> >>>> >>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> On 30 November 2015 at 18:15, Xueming Shen >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> While it is kinda understandable to have LocalDate.toEpochSecond(...) >>>>>> to get the epoch seconds since 1970.1.1, with the assumption of the >>>>>> time is at the midnight of that day. It is strange to have the >>>>>> Local/OffsetTime >>>>>> to have two public methods with the assumption of the "date" is at >>>>>> epoch >>>>>> year/month/day. What's the use case/scenario for these two proposed >>>>>> methods? >>>>>> >>>>>> -Sherman >>>>>> >>>>>> >>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>> >>>>>>> The method Javadoc (specs) for each of the three new methods needs to >>>>>>> be enhanced. >>>>>>> >>>>>>> For the date ones it needs to say >>>>>>> "The resulting date will have a time component of midnight at the >>>>>>> start of the day." >>>>>>> >>>>>>> For the time ones it needs to say >>>>>>> "The resulting time will be on 1970-01-01." >>>>>>> >>>>>>> Some of the line wrapping in the tests looks like it is not indented >>>>>>> correctly. >>>>>>> >>>>>>> Otherwise looks fine, >>>>>>> thanks >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a fix for >>>>>>>> >>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>> >>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>> >>>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>> >>>>>>>> -- Thanks and Regards, >>>>>>>> Nadeesh TV >>>>>> >>>>>> >>>>> >>>> >>>> >> > From daniel.fuchs at oracle.com Tue Dec 1 16:05:33 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Dec 2015 17:05:33 +0100 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: <565CD363.4070207@oracle.com> References: <565C86A4.9040009@oracle.com> <565C8AD9.1080607@oracle.com> <565C937A.4050601@oracle.com> <565CD363.4070207@oracle.com> Message-ID: <565DC54D.1020507@oracle.com> Hi Stuart, Thanks for the feedback! On 30/11/15 23:53, Stuart Marks wrote: > Hi all, > > Thanks for considering JEP 277 in this discussion. It's far from being > finalized at this point, but SUPERSEDED seems like the most likely of > the deprecation reasons from the proposal that would be applied here. > > While it seems that getMillis() is merely a convenience method for > calling getInstant().toEpochMilli(), there are a couple subtle semantic > differences that might warrant consideration beyond the loss of > nanosecond resolution. > > First, LogRecord now contains an Instant instead of a millis-since-epoch > value. Instant is explicitly intended to support points in time prior to > the epoch. It's possible for a LogRecord to contain such a time via > setInstant(). Thus, getMillis() can now return a negative number. This > isn't explicitly allowed or disallowed as far as I can see, but > historically millis-since-epoch values have always been non-negative. I > suspect that most code out there implicitly assumes this and would > unprepared to deal with negative return values. This would only apply to code that explicitly used to call LogRecord.setMillis() with negative values: the number of milliseconds in LogRecord historically comes from System.currentTimeMillis() - and using Instant is not changing that - since we are now using Instant.now() - which underneath still ends up calling System.currentTimeMillis() with an additional nano second adjsutment. > Second, Instant uses a long to store seconds before or after the epoch, > whereas a long millis-since-epoch value can only represent 1/1000th of > that range. Instant.toEpochMilli() throws an exception in such cases. > This behavior would show through to LogRecord.getMillis(). (It looks > like this limitation is also present in the serial form of LogRecord.) Interesting. Maybe we should throw an IllegalArgumentException in setInstant() if the instant we're given exceeds the capacity of a long millis-since-epoch value. Or maybe it is acceptable to let the exception be thrown at serialization time - and deal with the issue in serialization when it is clear that there is a requirement for representing such points in time in LogRecord (dealing with this would mean altering the serial form of LogRecord - and I'm not convinced we need to support such extreme values). In any case, such an Instant would have to be constructed from the calling code - and set explicitely through setInstant() since Instant.now() is precisely constructed behind the scene from a long millis-since-epoch + a nano second adjustment, and therefore it should always be possible to retrofit it in those two quantities. > My hunch is that it's exceedingly rare for a LogRecord contain a time > before 1970 or 292 million years in the future, but the API allows it, > so it could happen, and it should be specified. Time before 1970 shouldn't be a problem - I think. I mean that using Instant makes it now clear what a negative value represents. In what concerns 292 million years in the future, then maybe we could schedule a RFE for Java 97333333.0 ;-) Or more seriously wait until the Clock.systemClock()/Instant.now() are able to return such value? > This doesn't imply that getMillis() should or shouldn't be deprecated. > The deciding factor here is whether you think it's important for > programmers to migrate away from this API. It may be that getMillis() > works just fine under all but the most extreme cases, so there's no > practical need for programmers to migrate away from it. Right. Stephen has convinced me that removing the @Deprecated and adding an @apiNote is the appropriate thing to do :-) best regards, -- daniel > > s'marks > > > > On 11/30/15 10:20 AM, Daniel Fuchs wrote: >> On 30/11/15 18:43, Roger Riggs wrote: >>> Hi Daniel, >>> >>> I think it makes sense to keep getMillis (and document it) as a >>> convenience method. >> >> Thanks Roger, Jason, I logged >> https://bugs.openjdk.java.net/browse/JDK-8144262 >> >> best regards, >> >> -- daniel >> >>> >>> Roger >>> >>> >>> On 11/30/2015 12:25 PM, Daniel Fuchs wrote: >>>> On 30/11/15 18:04, Jason Mehrens wrote: >>>>> Hi Daniel, >>>>> >>>>> >>>>> When JDK-8072645 - java.util.logging should use java.time to get more >>>>> precise time stamps was commited the LogRecord.getMillis() method was >>>>> marked as deprecated with the reason "To get the full nanosecond >>>>> resolution event time, use getInstant". I can see marking >>>>> LogRecord.setMillis as deprecated since using that would be an >>>>> untended loss of precision. However, it seems excessive to deprecate >>>>> LogRecord.getMillis when it could be treated as a convenience method >>>>> that could simply note that if the caller wants nanosecond resolution >>>>> use getInstant. It would be extremely helpful compatibility wise to >>>>> have this undeprecated for libs that have support pre-Java 9. If it >>>>> can't be undeprecated what is the proper way to target support as low >>>>> as JDK7 but might end up executing on JDK9? >>>> >>>> Hi Jason, >>>> >>>> I see your point. >>>> >>>> As you noted, the main reason for deprecating getMillis() is that we >>>> actually wanted to deprecate setMillis(). >>>> If I remember well there was a discussion at the time around >>>> whether calling setMillis() should or should not set the nano >>>> second adjustment to 0. >>>> >>>> We ended up adding an Instant field instead of simply adding >>>> a new 'nanos' field adjustment, and then we deprecated >>>> getMillis()/setMillis() in favor of getInstant()/setInstant(). >>>> >>>> That said - I agree that the only really problematic API here >>>> is setMillis(). >>>> >>>> I wouldn't be opposed to 'undeprecate' getMillis() - I wonder >>>> whether that would be a good use case for JEP 277 though. >>>> (enhanced deprecation http://openjdk.java.net/jeps/277 ) >>>> >>>> Any other opinion? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> Jason >>>>> >>>> >>> >> From claes.redestad at oracle.com Tue Dec 1 16:06:23 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 01 Dec 2015 17:06:23 +0100 Subject: RFR: 8143131: Remove unused code from java.lang.invoke Message-ID: <565DC57F.4010308@oracle.com> Hi, please review this patch to cleanup various things in and around java.lang.invoke: Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ /Claes From frederic.parain at oracle.com Tue Dec 1 16:21:47 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 1 Dec 2015 17:21:47 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56548F9B.1000507@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> Message-ID: <565DC91B.9060206@oracle.com> Hi Dan, Thank you for your detailed review. My answers are in-lined below. New webrev: http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ On 24/11/2015 17:26, Daniel D. Daugherty wrote: > > src/cpu/sparc/vm/frame_sparc.cpp > (old) L635: if (fp() - sp() > 1024 + > m->max_stack()*Interpreter::stackElementSize) { > (new) L635: if (fp() - unextended_sp() > 1024 + > m->max_stack()*Interpreter::stackElementSize) { > This looks like a bug fix independent of this fix. Correct, this is the SPARC version of JDK-8068655. > src/share/vm/runtime/thread.hpp > L953: intptr_t* _reserved_stack_activation; > L1382: intptr_t* reserved_stack_activation() const { return > _reserved_stack_activation; } > L1383: void set_reserved_stack_activation(intptr_t* addr) { > > I was expecting this type to be 'address' instead of 'intptr_t*'. > > Update: I've gone back through the changes and I still don't > see a reason that this is 'intptr_t*'. The _reserved_stack_activation has been declared as an 'intptr_t*' just to be consistent with the _sp and _fp fields of the frame class. However, this is not really a requirement, the content stored at the _reserved_stack_activation address is never read. This address is just a "marker" on the stack to quickly check if the thread has exited the annotated code section or not. I've change the type to address, there's slightly less casts, and it doesn't impact the ReservedStackArea logic. Note: I've removed all further comments about _reserved_stack_activation type in order to improve the e-mail readability. > L1341: { return stack_yellow_zone_base();} > '{' should be at the end of the previous line. > Missing space after ';'. Fixed > L1343: { return StackReservedPages * os::vm_page_size(); } > '{' should be at the end of the previous line. Fixed > src/share/vm/runtime/thread.cpp > L2543: // The base notation is from the stacks point of view, > growing downward. > L2565: // The base notation is from the stacks point of view, > growing downward. > Typo: "stacks point of view" -> "stack's point of view" Fixed > L2552: } else { > L2553: warning("Attempt to guard stack reserved zone failed."); > L2554: } > L2555: enable_register_stack_guard(); > > Should enable_register_stack_guard() be called when we issued > the warning on L2553? > > L2571: } else { > L2572: warning("Attempt to unguard stack reserved zone failed."); > L2573: } > L2574: disable_register_stack_guard(); > > Should disable_register_stack_guard() be called when we issued > the warning on L2572? enable_register_stack_guard() and disable_register_stack_guard() are relics of the Itanium code (Itanium had a very different stack management). These methods are currently empty on all OpenJDK and Oracle platforms. May be another clean up opportunity here. Regarding the placement of the calls, I followed the same pattern as the other red/yellow pages management functions. > src/share/vm/runtime/sharedRuntime.cpp > > L784: java_lang_Throwable::set_message(exception_oop, > L785: Universe::delayed_stack_overflow_error_message()); > Wrong indent; this should line up under the 'e' after the '('. Fixed > L2976: if (fr.is_interpreted_frame()) { > L2978: prv_fr = fr; > L2982: prv_fr = fr; > This line is in both branches of the if-statement on L2976. > Is there a reason not to save prv_fr before L2976? No particular reason, fixed. > L2996 continue; > Wrong indent; needs one more space. Fixed > L2958: frame activation; > L3013: return activation; > The return on L3013 can return a default constructed 'frame'. > Is that default safe to return here? Yes, the caller performs a check before using the returned frame: if (activation.sp() != NULL) { ... > > src/os/bsd/vm/os_bsd.hpp > L109: static bool get_frame_at_stack_banging_point(JavaThread* > thread, ucontext_t* uc, frame* fr); > Wrong indent; needs one less space. Fixed > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > L322: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L323: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L379: assert(fr->safe_for_sender(thread), "Safety check"); > L380: if (!fr->is_first_java_frame()) { > L381: *fr = fr->java_sender(); > The assert() on L379 should be before the java_sender() > call on L381. Fixed > src/os/linux/vm/os_linux.cpp > L1902: jt->stack_guards_enabled()) { // No pending > stack overflow exceptions > This line's comment used to align with the previous line's comment. > Can you move the previous line's comment to align with this one? Done. > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > L135: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L136: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L192: assert(fr->safe_for_sender(thread), "Safety check"); > L193: if (!fr->is_first_java_frame()) { > L194: *fr = fr->java_sender(); > The assert() on L192 should be before the java_sender() > call on L194. Fixed > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > L209: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L210: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L265: assert(fr->safe_for_sender(thread), "Safety check"); > L266: if (!fr->is_first_java_frame()) { > L267: *fr = fr->java_sender(); > The assert() on L265 should be before the java_sender() > call on L267. Fixed > L279: //assert(fr->safe_for_sender(thread), "Safety check"); > Delete this line; you copied it to L282. Done > L287 return true; > Should this assert be added above this line? > assert(fr->is_java_frame(), "Safety check"); Yes, this assert exists on other platforms, and there's no reason to omit it on Solaris/SPARC > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > L195: // For Forte Analyzer AsyncGetCallTrace profiling support - > thread > L196: // is currently interrupted by SIGPROF. > Now fetch_frame_from_ucontext() is also used for stack overflow > signal handling. Fixed > L253: assert(fr->safe_for_sender(thread), "Safety check"); > L254: if (!fr->is_first_java_frame()) { > L255: *fr = fr->java_sender(); > The assert() on L253 should be before the java_sender() > call on L255. Fixed > L273: *fr = fr->java_sender(); > Wrong indent; one too many spaces. Fixed > src/os/windows/vm/os_windows.cpp > L2364: assert(fr->safe_for_sender(thread), "Safety check"); > L2365: if (!fr->is_first_java_frame()) { > L2366: *fr = fr->java_sender(); > The assert() on L2364 should be before the java_sender() > call on L2366. Fixed > L2387: return true; > Should this assert be added above this line? > assert(fr->is_java_frame(), "Safety check"); Certainly, fixed. > src/share/vm/oops/method.hpp > (old) L87: u1 _flags; > (new) L88: u2 _flags; > Ouch - just needed one more bit... The initial implementation of the reserved stack area used the last bit, but unfortunately, someone else steal it before I could push my code :-( So I had to extend the flags field > L834: return (_flags & _reserved_stack_access) != 0; > Wrong indent; two fewer spaces. Fixed > src/share/vm/runtime/globals.hpp > L3549: range(MIN_STACK_RESERVED_PAGES, > (DEFAULT_STACK_RESERVED_PAGES+10))\ > Wrong indent; should line up below the double quote in > the previous line. Fixed > src/share/vm/interpreter/interpreterRuntime.cpp > L328 IRT_ENTRY(void, > InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* thread)) > > The regular throw_StackOverflowError() increments > a counter: > > L313: Atomic::inc(&Exceptions::_stack_overflow_errors); > > Should this function increment the same counter or > a different counter? Good catch! I've added the counter increment to the method throw_delayed_StackOverflowError(). I don't see a strong rational to create a new counter for delayed stack overflows, so it increments the same counter as throw_StackOverflowError(). > > src/cpu/sparc/vm/macroAssembler_sparc.hpp > L1423: // Check for reserved stack access in method being exited > (for the compilers) > The X86 version says "for JIT compilers". I prefer "JIT". Fixed > src/cpu/x86/vm/macroAssembler_x86.hpp > L643: // Check for reserved stack access in method being exited > (for JIT compilers) > The SPARC version says "for the compilers". Fixed > src/share/vm/ci/ciMethod.cpp > L95: _has_reserved_stack_access = > h_m()->has_reserved_stack_access(); > Wrong indent; should be only one space before '='. Fixed > src/share/vm/c1/c1_GraphBuilder.cpp > L3323: if(callee->has_reserved_stack_access()) { > L3336: if(callee->has_reserved_stack_access()) { > L3356: if(callee->has_reserved_stack_access()) { > Missing space between 'if' and '('. All fixed. > src/cpu/x86/vm/x86_32.ad > L737: size += 64; // added to support ReservedStackAccess > Usually I hate literals like this, but this function has > them in spades. :-( I agree but I didn't find a better solution. > src/cpu/x86/vm/x86_64.ad > L960: MacroAssembler _masm(&cbuf); > L965: MacroAssembler _masm(&cbuf); > > I think you can delete the _masm on L965. Right, removed. > src/share/vm/opto/compile.cpp > L675: _has_reserved_stack_access(target->has_reserved_stack_access()) { > Wrong indent; should be a single space between ')' and '{'. Fixed > test/runtime/ReservedStack/ReservedStackTest.java > L26: * @run main/othervm -XX:-Inline > -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread > ReservedStackTest > > Should the comma before 'setExclusiveOwnerThread' be a period? > Perhaps both formats work... Both formats work, but I changed it to be a period, it's cleaner. > L47: * else > Wrong indent; needs one more space before 'else'. > > L52: * successfully update the status of the lock but he method > Typo: 'update the' -> 'updates the' > Typo: 'he method' -> 'the method' > > L60: * first StackOverflowError is thrown, the Error is catched > Typo: 'is catched' -> 'is caught' > > L61: * and a few dozens frames are exited. Now the thread has > Typo: 'a few dozens frames' -> 'a few dozen frames' > > L66: * of its invocation, tries to acquire the next lock > Typo: 'its invocation' -> 'its invocations' > > L81: * stack to prevent false sharing. The test is using this > Perhaps 'The test is using this' > -> 'The test relies on this' > > to better match wording on L225-6. > > L82: * to have different stack alignments and hit the targeted > Grammar: 'and hit' -> 'when it hits' > > L102: * exploit the property that interpreter frames are (much) > Typo: 'exploit' -> 'exploits' > Delete extra space after 'the'. > > L123: //LOCK_ARRAY_SIZE value > Add a space after '//'. > > L188: @jdk.internal.vm.annotation.ReservedStackAccess > This isn't privileged code and -XX:-RestrictReservedStack > isn't specified so what does this do? It checks that by default the annotation is ignored for non-privileged code, in case it is not ignored, the test would fail. > > L201: System.exit(-1); > Wrong indent; needs two more spaces. All fixed. Thank you very much! Fred >> >> On 20/11/2015 19:44, Karen Kinnear wrote: >>> Frederic, >>> >>> Code review for web revs you sent out. >>> Code looks good. I am not as familiar with the compiler code. >>> >>> I realize you need to check in at least a subset of the >>> java.util.concurrent changes for >>> the test to work, so maybe I should not have asked Doug about his >>> preference there. >>> Sorry. >>> >>> I am impressed you found a way to make a reproducible test! >>> >>> Comments/questions: >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >> >> Fixed >> >>> 2. IIRC, due to another bug with windows handling of our guard pages, >>> this >>> is disabled for Windows. Would it be worth putting a comment in the >>> bug , 8067946, that once this is fixed, the reserved stack logic on >>> windows >>> will need testing before enabling? >> >> More than testing, the implementation would have to be completed on >> Windows. I've added a comment to JDK-8067946. >> >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>> this is in interpreter code, you explicitly return the Java sender >>> of the current frame. I was expecting to see that on Solaris_sparc >>> and Windows >>> as well? I do see the assertion in caller that you do have a java frame. >> >> It doesn't make sense to check the current frame (no bytecode has been >> executed yet, so risk of partially executed critical section). I did the >> change but not for all platforms. This is now fixed for Solaris_SPARC >> and Windows too. >> >>> 4. test line 83 ?writtent? -> ?written? >> >> Fixed >> >>> 5. I like the way you set up the preallocated exception and then set >>> the message - we may >>> try that for default methods in future. >>> >>> 6. I had a memory that you had found a bug in safe_for_sender - did >>> you already check that in? >> >> I've fixed x86 platforms in JDK-8068655. >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >> I had hoped it would have been silently accepted :-) >> >> >>> 7. I see the change in trace.xml, and I see an include added to >>> SharedRuntime.cpp, >>> but I didn?t see where it was used - did I just miss it? >> >> trace.xml changes define a new event. >> This event is created at sharedRuntime.cpp::3006 and it is used >> in the next 3 lines. >> >> Thanks, >> >> Fred >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From michael.haupt at oracle.com Tue Dec 1 16:30:18 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 1 Dec 2015 17:30:18 +0100 Subject: RFR: 8143131: Remove unused code from java.lang.invoke In-Reply-To: <565DC57F.4010308@oracle.com> References: <565DC57F.4010308@oracle.com> Message-ID: <87A7FD4F-9EC8-4405-8AD9-99DB86E5857C@oracle.com> Hi Claes, note that this is a lower-case review: thumbs up. Good catches! Thanks! :-) Best, Michael > Am 01.12.2015 um 17:06 schrieb Claes Redestad : > > Hi, > > please review this patch to cleanup various things in and around java.lang.invoke: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 > Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ > > /Claes -- 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 is committed to developing practices and products that help protect the environment From nadeesh.tv at oracle.com Tue Dec 1 16:50:16 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 01 Dec 2015 22:20:16 +0530 Subject: RFR:JDK-8144349: @since tag missed Message-ID: <565DCFC8.2020103@oracle.com> Hi all, Please review a fix for BugID - https://bugs.openjdk.java.net/browse/JDK-814434 Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since 9 tag. webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/ -- Thanks and Regards, Nadeesh TV From scolebourne at joda.org Tue Dec 1 16:54:13 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 1 Dec 2015 16:54:13 +0000 Subject: RFR:JDK-8144349: @since tag missed In-Reply-To: <565DCFC8.2020103@oracle.com> References: <565DCFC8.2020103@oracle.com> Message-ID: Those are not the right methods on LocalDate and LocalTime Stephen On 1 December 2015 at 16:50, nadeesh tv wrote: > Hi all, > Please review a fix for > BugID - https://bugs.openjdk.java.net/browse/JDK-814434 > Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since > 9 tag. > webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/ > > -- > Thanks and Regards, > Nadeesh TV From xueming.shen at oracle.com Tue Dec 1 17:33:56 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 1 Dec 2015 09:33:56 -0800 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> Message-ID: <565DDA04.7040802@oracle.com> On 12/1/15 6:36 AM, Stephen Colebourne wrote: > As Roger says, these new methods are about performance as well as conversion. > > While I fully acknowledge the time methods make an assumption, it is > not a crazy one, after all 1970-01-01 is just zero. > > Key I think is it allows: > long epochSecs = date.toEpochSeconds(offset) + time.toEpochSeconds(offset); > to efficiently merge two objects without garbage. So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean approach LocalDate date = ... LocalDate time = ... ZoneOffset offset = ... ==> long spochSecs = LocalDateTime.of(date, time).toEpochSeconds(offset); we are adding APIs to provide a "fastpath" with the special assumption that the LocalDate "date" here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) and the LocalTime "time" again actually means a "LocalDateTime" (the "time" of 1970-01-01), to let the third party "libraries" to fool the basic date/time abstract in java.time package, simply to avoid creating the garbage middle man, localDateTime? it really does not sound right to me. First, if someone needs to mix/link LocalDate, LocalTime and Offset to epoch seconds in their libraries, they really SHOULD think hard about the conversion and make it right (it should not be encouraged to use these classes LocalDate, LocalTime and Offset without even understand what these classes are). But if we really have to provide such fastpath, personally I think it might be better either to provide these "utility/convenient" methods in a "utilities" class, or with an explicit date/time parameters (instead of the false assumption) for the missing date/time piece, such as localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); Sherman > > It also means that no-one has to think hard about the conversion, as > it is just there. It tends to be when people try to work this stuff > out for themselves that they get it wrong. > > Stephen > > > On 1 December 2015 at 14:21, Roger Riggs wrote: >> Hi Sherman, >> >> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>> Converting LocalDate<-> java.util.Date is the question with the >>>> largest number of votes on SO: >>>> >>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>> The proposed method is designed to make the conversion easier. It also >>>> plugs an obvious gap in the API. >>>> >>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>> having them would result in inconsistency between the various classes. >>>> We've already added factory methods to LocalTime for Java 9, these are >>>> just the other half of the picture. >>>> >>> I'm not sure I understand the idea of "the proposed method is designed to >>> make the conversion easier", as the SO is mainly about >>> j.u.Date->LocalDate, >>> not the other way around, from LocalDate -> j.u.Date. >> >> I think the issue is about *other* libraries that manipulate time via >> epochSeconds >> not about j.u.Date conversions. The concern was about performance and >> creating garbage along the way. >> >> Roger >> >> >> >>> As I said in the previous email, it might be "common" to use the j.u.Date >>> to >>> abstract a "local date" and/or a "local time" (no other choice) before >>> java.time, >>> and now there is the need to provide a migration path from those "local >>> date/ >>> time" to the j.t.LocalDate/Time. But convert backward from the new >>> date/time >>> type to the "old" j.u.Date should not be encouraged (guess this is also >>> the >>> consensus we agreed on back to jsr203). >>> >>> What are the "factory methods" you are referring to here? JDK-8133079, The >>> LocalDate/LocalTime.ofInstant()? >>> (btw, these two methods see missing the "since 1.9/9" tag) >>> >>> It seems to me that the ofInstant(Instant, ZondId) is from a "super-set" >>> of >>> date/time to a "sub-set", without any assumption of "default value", it is >>> similar to the conversion from zdt->ldt->ld/lt, and I can see the "small" >>> improvement >>> >>> from| >>> Date input = new Date(); >>> LocalDatedate >>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>> >>> to >>> >>> |LocalDatedate >>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>> >>> The proposed pair toEpochSecond() however is doing the other way around >>> and >>> with an unusual assumption of the missing date/time piece to a "default >>> value" >>> (midnight, the epoch day). >>> >>> personally I think >>> >>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>> >>> is clean and good enough to help this backward conversion (with the >>> addition >>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>> remove that LocalDateTime middle man, with some arrangement. >>> >>> -Sherman >>> >>>> Note that these methods are specifically not referencing >>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>> form here, and still widely used. >>>> >>>> Stephen >>>> >>>> >>>> >>>> On 30 November 2015 at 19:36, Xueming Shen >>>> wrote: >>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>> This is based on user difficulties picked up via Stack Overflow. These >>>>>> methods aim to provide a simpler and faster approach, particularly for >>>>>> cases converting to/from java.util.Date. >>>>> Can you be a little more specific on this one? We now have Instance<=> >>>>> Date, >>>>> and considerably we might add LocalDateTime<=> Date with an offset, if >>>>> really >>>>> really desired (for performance? to save a Instant object as the >>>>> bridge?). >>>>> But I'm >>>>> a little confused about the connection among LocalDate/LocalTime, epoch >>>>> seconds >>>>> and j.u.Date here. Are you saying someone wants to convert >>>>> >>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>> >>>>> and uses the converted j.u.Date to represent a local date (date with >>>>> time >>>>> part to >>>>> be 0) and/or the local time (with year/month/day to be epoch time) in >>>>> the >>>>> "old" >>>>> system which only has j.u.Date, and has to use the j.u.Date to abstract >>>>> the >>>>> "local >>>>> date" and "local time"? >>>>> >>>>> I think we agreed back to JSR310 that we don't try to add such kind of >>>>> "bridge/ >>>>> convenient/utility" methods into the new java.time package, but only in >>>>> the >>>>> old date/calendar classes, if really needed. So if these methods are >>>>> only to >>>>> help >>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>> java.time >>>>> might not be the best place for them? >>>>> >>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>> commonly used in many codebases. >>>>>> >>>>> I'm not sure about that, especially the "natural" part. It might be >>>>> "common" >>>>> in >>>>> the old days if you only have j.u.Date", and might be forced to use >>>>> 1970-01-01 >>>>> to fill in the "date" part even when you are really only interested in >>>>> "time" part >>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is now we >>>>> have >>>>> separate abstract for these different need, I don't see the common need >>>>> of >>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>> misunderstood >>>>> something here. >>>>> >>>>> -Sherman >>>>> >>>>> >>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> >>>>>> On 30 November 2015 at 18:15, Xueming Shen >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> While it is kinda understandable to have LocalDate.toEpochSecond(...) >>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of the >>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>> Local/OffsetTime >>>>>>> to have two public methods with the assumption of the "date" is at >>>>>>> epoch >>>>>>> year/month/day. What's the use case/scenario for these two proposed >>>>>>> methods? >>>>>>> >>>>>>> -Sherman >>>>>>> >>>>>>> >>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>> The method Javadoc (specs) for each of the three new methods needs to >>>>>>>> be enhanced. >>>>>>>> >>>>>>>> For the date ones it needs to say >>>>>>>> "The resulting date will have a time component of midnight at the >>>>>>>> start of the day." >>>>>>>> >>>>>>>> For the time ones it needs to say >>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>> >>>>>>>> Some of the line wrapping in the tests looks like it is not indented >>>>>>>> correctly. >>>>>>>> >>>>>>>> Otherwise looks fine, >>>>>>>> thanks >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>> wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review a fix for >>>>>>>>> >>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>> >>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>> >>>>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>> >>>>>>>>> -- Thanks and Regards, >>>>>>>>> Nadeesh TV >>>>>>> >>>>>> >>>>> From nadeesh.tv at oracle.com Tue Dec 1 18:38:30 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 02 Dec 2015 00:08:30 +0530 Subject: RFR:JDK-8144349: @since tag missed In-Reply-To: References: <565DCFC8.2020103@oracle.com> Message-ID: <565DE926.4000902@oracle.com> Hi , Sorry. I made a mistake. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8144349/webrev.01 Regards, Nadeesh On 12/1/2015 10:24 PM, Stephen Colebourne wrote: > Those are not the right methods on LocalDate and LocalTime > Stephen > > On 1 December 2015 at 16:50, nadeesh tv wrote: >> Hi all, >> Please review a fix for >> BugID - https://bugs.openjdk.java.net/browse/JDK-814434 >> Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since >> 9 tag. >> webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/ >> >> -- >> Thanks and Regards, >> Nadeesh TV -- Thanks and Regards, Nadeesh TV From Roger.Riggs at Oracle.com Tue Dec 1 18:43:04 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 1 Dec 2015 13:43:04 -0500 Subject: RFR:JDK-8144349: @since tag missed In-Reply-To: <565DE926.4000902@oracle.com> References: <565DCFC8.2020103@oracle.com> <565DE926.4000902@oracle.com> Message-ID: <565DEA38.8020005@Oracle.com> Hi Nadeesh, Thanks for the correction, looks fine. Reviewed, Roger p.s. I can sponsor that and get it integrated On 12/1/2015 1:38 PM, nadeesh tv wrote: > Hi , > Sorry. I made a mistake. > Please see the updated webrev > > http://cr.openjdk.java.net/~ntv/8144349/webrev.01 > > Regards, > Nadeesh > > On 12/1/2015 10:24 PM, Stephen Colebourne wrote: >> Those are not the right methods on LocalDate and LocalTime >> Stephen >> >> On 1 December 2015 at 16:50, nadeesh tv wrote: >>> Hi all, >>> Please review a fix for >>> BugID - https://bugs.openjdk.java.net/browse/JDK-814434 >>> Issue - while fixing JDK-8071919, JDK-8133079 I forgot to >>> add @since >>> 9 tag. >>> webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/ >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV > From daniel.fuchs at oracle.com Tue Dec 1 18:48:50 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Dec 2015 19:48:50 +0100 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: References: Message-ID: <565DEB92.6040502@oracle.com> Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html As Stuart noted, java.time.Instant has a greater range than what can be constructed from a long milliseconds-since-epoch + a nano-time adjustment. This does not apply to instants returned by the system clock, since those are constructed precisely from such long milliseconds-since-epoch + nano-time adjustment. However - someone could conceivably construct such an Instant and pass it to a LogRecord. If that happens, then LogRecord.getMillis() could potentially throw an undocumented ArithmeticException. So we have at least 3 possibilities: 1. do nothing 2. document that getMillis() can throw ArithmeticException, with the additional consequence that serializing a LogRecord thus constructed would also throw an ArithmeticException. 3. modify setInstant() to validate that the instant will fit in a long milliseconds-since-epoch. The above patch implements option 3 (which currently has my preference). Is that the best solution? I would very much like to hear your opinion. If it seems like the best then I'll add a unit test, send an RFR, and do the paper work for the spec change... best regards, and thanks for all the valuable feedback! -- daniel On 30/11/15 18:04, Jason Mehrens wrote: > Hi Daniel, > > > When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant". I can see marking LogRecord.setMillis as deprecated since using that would be an untended loss of precision. However, it seems excessive to deprecate LogRecord.getMillis when it could be treated as a convenience method that could simply note that if the caller wants nanosecond resolution use getInstant. It would be extremely helpful compatibility wise to have this undeprecated for libs that have support pre-Java 9. If it can't be undeprecated what is the proper way to target support as low as JDK7 but might end up executing on JDK9? > > > Thanks, > > > Jason > From john.r.rose at oracle.com Tue Dec 1 18:53:08 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Dec 2015 10:53:08 -0800 Subject: RFR: 8143131: Remove unused code from java.lang.invoke In-Reply-To: <565DC57F.4010308@oracle.com> References: <565DC57F.4010308@oracle.com> Message-ID: <45C3074A-158D-4912-A861-8998B43750FD@oracle.com> CDE = Code Deletion Engineering. Yes! Reviewed. ? John On Dec 1, 2015, at 8:06 AM, Claes Redestad wrote: > > Hi, > > please review this patch to cleanup various things in and around java.lang.invoke: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 > Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ > > /Claes From christian.tornqvist at oracle.com Tue Dec 1 19:19:17 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 1 Dec 2015 14:19:17 -0500 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> Message-ID: <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> Hi Paul, Tests in hotspot/test/runtime needs to be jtreg tests. Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? (adding the hotspot-dev mail alias) Thanks, Christian -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz Sent: Tuesday, December 1, 2015 5:28 AM Cc: hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables > On 30 Nov 2015, at 23:33, Paul Sandoz wrote: > > >> On 30 Nov 2015, at 23:05, Christian Tornqvist wrote: >> >> Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. >> > > jtreg comes bundled with testng so what is there to reduce? > Here is an analogy: jtreg is to testng as launcher is to library They are complementary to each other i.e. think of testng as an implicit @library that helps one better organize tests and report errors. ? Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK? Sorry to push back, but I don?t agree with that position (if correct). I am reluctant to change the tests. Please don?t think that complete pigheadedness on my part :-) I just don?t think it?s the right thing to do. If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught. Paul. From claes.redestad at oracle.com Tue Dec 1 19:43:17 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 01 Dec 2015 20:43:17 +0100 Subject: RFR: 8143131: Remove unused code from java.lang.invoke In-Reply-To: <45C3074A-158D-4912-A861-8998B43750FD@oracle.com> References: <565DC57F.4010308@oracle.com> <45C3074A-158D-4912-A861-8998B43750FD@oracle.com> Message-ID: <565DF855.2050808@oracle.com> John, Michael, thanks for reviewing! /Claes On 2015-12-01 19:53, John Rose wrote: > CDE = Code Deletion Engineering. Yes! > > Reviewed. > > ? John > > On Dec 1, 2015, at 8:06 AM, Claes Redestad wrote: >> Hi, >> >> please review this patch to cleanup various things in and around java.lang.invoke: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 >> Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ >> >> /Claes From john.r.rose at oracle.com Tue Dec 1 20:16:11 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Dec 2015 12:16:11 -0800 Subject: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic In-Reply-To: <56547194.5040701@oracle.com> References: <564FA538.2060405@oracle.com> <5650D631.3060106@oracle.com> <5650F334.2030208@oracle.com> <5650F644.7000702@oracle.com> <56521E9C.5010604@oracle.com> <5652DE11.9020004@oracle.com> <5652F553.3050001@oracle.com> <565315FB.5000908@oracle.com> <56532BD6.1080401@oracle.com> <56533D94.8020500@oracle.com> <05C2EB7E-CD5D-4463-AB1C-D407728003C3@oracle.com> <5653882F.9060309@oracle.com> <524FDB9C-3727-4944-8E96-CB7A7E6C0DCB@oracle.com> <565444DE.7040805@oracle.com> <56547194.5040701@oracle.com> Message-ID: <425E9D3A-AA70-4F7E-8CC5-3E01D14D3D81@oracle.com> On Nov 24, 2015, at 6:17 AM, Aleksey Shipilev wrote: > > Oh no, I don't. Pre-integration JPRT runs exposed an opaque dependency > on Integer.sizeTable field from C2 OptimizeStringConcat. I added the > field declaration back: > http://cr.openjdk.java.net/~shade/8136500/webrev.07/ > > Cleaning up the compiler code would require much more time, so I would > like to push this JDK part now, and deal with Hotspot compiler later: > https://bugs.openjdk.java.net/browse/JDK-8143900 > > Objections? None. Is there a tracking bug for CDE-ing OptimizeStringConcat? There should be. (I realize that will require sorting through some indy bootstrap issues.) ? John From mikael.vidstedt at oracle.com Tue Dec 1 21:29:04 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Dec 2015 13:29:04 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: References: Message-ID: <565E1120.2040106@oracle.com> This is as far as I got before I got interrupted: http://cr.openjdk.java.net/~mikael/NioBenchmark.java I haven't had time yet to verify that the benchmark code even measures the right thing, much less figure out why I get the performance impact with my fix. I can see many reasons why that could be the case, but it would be good to know if it's something trivial which can be easily fixed. In general, it sure would be nice to make this code behave and perform without compiler specific annotations, especially given that reliance on unaligned memory accesses and the cast specifically is sketchy at best. Cheers, Mikael On 2015-11-30 10:13, Alexander Smundak wrote: > On Wed, Nov 25, 2015 at 2:52 PM, wrote: >> Have you looked anything at the performance of the generated code? > No. I looked at the emitted code, saw 'MOVQDU' instruction being used > (it was 'MOVQDA' before that resulted in alignment error), and concluded > that the compiler knows what it's doing :-) >> It would be interesting to understand what type of performance you see with >> your patch. > If you have specific benchmark in mind, I am willing to run it. > > Sasha From jason_mehrens at hotmail.com Tue Dec 1 22:31:59 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 1 Dec 2015 22:31:59 +0000 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: <565DEB92.6040502@oracle.com> References: , <565DEB92.6040502@oracle.com> Message-ID: Hi Daniel, I like proposed #3 solution too. Usually is best to not allow "poisoning the well". This will really help me out with supporting older platforms and keeping the code smell to a minimum. Thanks for taking this on, Jason ________________________________________ From: Daniel Fuchs Sent: Tuesday, December 1, 2015 12:48 PM To: Jason Mehrens; Core-Libs-Dev; Stuart Marks Subject: Re: Deprecation of LogRecord.getMillis in JDK9 Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html As Stuart noted, java.time.Instant has a greater range than what can be constructed from a long milliseconds-since-epoch + a nano-time adjustment. This does not apply to instants returned by the system clock, since those are constructed precisely from such long milliseconds-since-epoch + nano-time adjustment. However - someone could conceivably construct such an Instant and pass it to a LogRecord. If that happens, then LogRecord.getMillis() could potentially throw an undocumented ArithmeticException. So we have at least 3 possibilities: 1. do nothing 2. document that getMillis() can throw ArithmeticException, with the additional consequence that serializing a LogRecord thus constructed would also throw an ArithmeticException. 3. modify setInstant() to validate that the instant will fit in a long milliseconds-since-epoch. The above patch implements option 3 (which currently has my preference). Is that the best solution? I would very much like to hear your opinion. If it seems like the best then I'll add a unit test, send an RFR, and do the paper work for the spec change... best regards, and thanks for all the valuable feedback! -- daniel On 30/11/15 18:04, Jason Mehrens wrote: > Hi Daniel, > > > When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant". I can see marking LogRecord.setMillis as deprecated since using that would be an untended loss of precision. However, it seems excessive to deprecate LogRecord.getMillis when it could be treated as a convenience method that could simply note that if the caller wants nanosecond resolution use getInstant. It would be extremely helpful compatibility wise to have this undeprecated for libs that have support pre-Java 9. If it can't be undeprecated what is the proper way to target support as low as JDK7 but might end up executing on JDK9? > > > Thanks, > > > Jason > From stuart.marks at oracle.com Wed Dec 2 01:13:00 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 1 Dec 2015 17:13:00 -0800 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: <565DEB92.6040502@oracle.com> References: <565DEB92.6040502@oracle.com> Message-ID: <565E459C.9070702@oracle.com> I think #3 or a variation is best. Clearly, #1 is inconsistent and simply documenting it (#2) isn't much better. I'd recommend making setInstant() be more explicit about the range of Instant values that are allowed, namely those created from Instant.ofEpochMilli(long), which allows +/- 292 million years from the epoch. Otherwise the reader is forced to try to understand when Instant.toEpochMilli() throws the exception. Now that we've constrained the range of instants that a LogRecord can contain, is it still necessary for setMillis(long) to be deprecated? Every value is valid. It can set (almost) the full range of Instant values, just not with nanosecond resolution. If you don't care about nanosecond resolution, this seems like a perfectly fine method to use. s'marks On 12/1/15 10:48 AM, Daniel Fuchs wrote: > Hi Jason, Stuart, > > Here is a potential fix for the issue: > > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html > > > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html > > > > As Stuart noted, java.time.Instant has a greater range than what can > be constructed from a long milliseconds-since-epoch + a nano-time > adjustment. This does not apply to instants returned by the system > clock, since those are constructed precisely from such long > milliseconds-since-epoch + nano-time adjustment. > > However - someone could conceivably construct such an Instant > and pass it to a LogRecord. If that happens, then LogRecord.getMillis() > could potentially throw an undocumented ArithmeticException. > > So we have at least 3 possibilities: > > 1. do nothing > 2. document that getMillis() can throw ArithmeticException, with the > additional consequence that serializing a LogRecord thus constructed > would also throw an ArithmeticException. > 3. modify setInstant() to validate that the instant will fit in a > long milliseconds-since-epoch. > > > The above patch implements option 3 (which currently has my > preference). Is that the best solution? > > I would very much like to hear your opinion. > If it seems like the best then I'll add a unit test, send an RFR, and > do the paper work for the spec change... > > best regards, and thanks for all the valuable feedback! > > -- daniel > > > > On 30/11/15 18:04, Jason Mehrens wrote: >> Hi Daniel, >> >> >> When JDK-8072645 - java.util.logging should use java.time to get more precise >> time stamps was commited the LogRecord.getMillis() method was marked as >> deprecated with the reason "To get the full nanosecond resolution event time, >> use getInstant". I can see marking LogRecord.setMillis as deprecated since >> using that would be an untended loss of precision. However, it seems >> excessive to deprecate LogRecord.getMillis when it could be treated as a >> convenience method that could simply note that if the caller wants nanosecond >> resolution use getInstant. It would be extremely helpful compatibility wise >> to have this undeprecated for libs that have support pre-Java 9. If it can't >> be undeprecated what is the proper way to target support as low as JDK7 but >> might end up executing on JDK9? >> >> >> Thanks, >> >> >> Jason >> > From roger.riggs at oracle.com Wed Dec 2 01:49:31 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 1 Dec 2015 20:49:31 -0500 Subject: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error Message-ID: <565E4E2B.30901@oracle.com> Please review this change in ProcessHandle to validate parent pids provided by the OS. Children of a process have start times that are the same or later than the parent. The implementation of descendants(), and children(), and getParent() are updated to validate the parent pid. The problem is most pronounced on Windows; the parent pid reported for a process may be stale if the parent exited. The validation is applied in platform neutral code and used on all platforms. Platform specific code is used on Windows for getParent(); the Linux platforms do the right thing. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/ Issue: https://bugs.openjdk.java.net/browse/JDK-8143876 Thanks, Roger From vladimir.kozlov at oracle.com Wed Dec 2 01:55:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 Dec 2015 17:55:06 -0800 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> Message-ID: <565E4F7A.2050607@oracle.com> I reviewed 8143355 today and my main question is where are range checks? Thanks, Vladimir On 11/25/15 1:53 AM, Paul Sandoz wrote: > Hi, > > And this is the review for the Java part: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ > > Which will be updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is pushed. [1] > > The plan is all reviewed changes will be pushed to hs-comp and then we follow up: > > 1) adding the intrinsic to other platforms > > 2) improving C1 (perhaps even the interpreter?) since the intrinsic is a stub which IIUC makes it easier to plug in. > > 3) take a swing at consolidating other equal/compare intrinsics, such as those for char[]/String-based equal/compare > > 4) adding methods to String such as mismatch method. > > I can help by pushing all reviewed patches. I will kick off a JPRT run with all patches applied. > > I did evaluate/test the HotSpot patch (stared at the patch and generated code for UseAVX < 2, and measured) and reviewed with my limited knowledge of HotSpot. > > Paul. > > [1] > diff -r 01b49c2960fd src/java.base/share/classes/java/util/ArraysSupport.java > --- a/src/java.base/share/classes/java/util/ArraysSupport.java Tue Nov 17 15:42:53 2015 +0100 > +++ b/src/java.base/share/classes/java/util/ArraysSupport.java Tue Nov 17 17:05:09 2015 +0100 > @@ -24,7 +24,7 @@ > */ > package java.util; > > -//import jdk.internal.HotSpotIntrinsicCandidate; > +import jdk.internal.HotSpotIntrinsicCandidate; > import jdk.internal.misc.Unsafe; > > class ArraysSupport { > @@ -72,7 +72,7 @@ > * If a mismatch is not found the negation of one plus the number of > * remaining pairs of elements to be checked in the tail of the two arrays. > */ > -// @HotSpotIntrinsicCandidate > + @HotSpotIntrinsicCandidate > static int vectorizedMismatch(Object a, long aOffset, > Object b, long bOffset, > int length, > >> On 25 Nov 2015, at 01:00, Deshpande, Vivek R wrote: >> >> Hi all >> >> We would like to contribute a patch from Intel which optimizes vectorizedMismatch() method in java.util.ArraysSupport.java for X86 architecture using AVX instructions. >> The improvement gives more than 2x gain over Unsafe implementation for long arrays. >> The bug is blocked by bug: vectorized support for array equals/compare/mismatch using Unsafe (https://bugs.openjdk.java.net/browse/JDK-8136924.) >> Could you please review and sponsor this patch. >> >> Bug-id: >> https://bugs.openjdk.java.net/browse/JDK-8143355 >> webrev: >> http://cr.openjdk.java.net/~mcberg/8143355/webrev.01/ >> >> Thanks and regards, >> Vivek > From joe.darcy at oracle.com Wed Dec 2 01:54:07 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 01 Dec 2015 17:54:07 -0800 Subject: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error In-Reply-To: <565E4E2B.30901@oracle.com> References: <565E4E2B.30901@oracle.com> Message-ID: <565E4F3F.7020801@oracle.com> Hi Roger, Looks fine. Do you know if there are clock skew issues to be concerned with if the parent and child are spawned on different CPUs? Thanks, -Joe On 12/1/2015 5:49 PM, Roger Riggs wrote: > Please review this change in ProcessHandle to validate parent pids > provided by the OS. > Children of a process have start times that are the same or later than > the parent. > The implementation of descendants(), and children(), and getParent() > are updated to validate the parent pid. > > The problem is most pronounced on Windows; the parent pid reported for a > process may be stale if the parent exited. The validation is applied in > platform neutral code and used on all platforms. Platform specific code > is used on Windows for getParent(); the Linux platforms do the right > thing. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8143876 > > Thanks, Roger > From roger.riggs at oracle.com Wed Dec 2 02:05:31 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 1 Dec 2015 21:05:31 -0500 Subject: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error In-Reply-To: <565E4F3F.7020801@oracle.com> References: <565E4E2B.30901@oracle.com> <565E4F3F.7020801@oracle.com> Message-ID: <565E51EB.4060903@oracle.com> Hi Joe, I do not know of any specific skew issues at the resolutions used. For example, Linux records the start time in ticks (1/60th to 100th of a second), not the full resolution of the time of day clock. Typically, the child start time is at least a bit later than the parent. If the maximum possible skew was known or estimated, the comparison could take that into account. For example, I would expect the skew across processors to be less than 1sec (or more likely 10ms) or there would be bigger issues among native processes. Thanks, Roger On 12/1/15 8:54 PM, Joseph D. Darcy wrote: > Hi Roger, > > Looks fine. > > Do you know if there are clock skew issues to be concerned with if the > parent and child are spawned on different CPUs? > > Thanks, > > -Joe > > On 12/1/2015 5:49 PM, Roger Riggs wrote: >> Please review this change in ProcessHandle to validate parent pids >> provided by the OS. >> Children of a process have start times that are the same or later >> than the parent. >> The implementation of descendants(), and children(), and getParent() >> are updated to validate the parent pid. >> >> The problem is most pronounced on Windows; the parent pid reported for a >> process may be stale if the parent exited. The validation is applied in >> platform neutral code and used on all platforms. Platform specific code >> is used on Windows for getParent(); the Linux platforms do the right >> thing. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8143876 >> >> Thanks, Roger >> > From joe.darcy at oracle.com Wed Dec 2 02:11:15 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 1 Dec 2015 18:11:15 -0800 Subject: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error In-Reply-To: <565E51EB.4060903@oracle.com> References: <565E4E2B.30901@oracle.com> <565E4F3F.7020801@oracle.com> <565E51EB.4060903@oracle.com> Message-ID: <565E5343.1060408@oracle.com> Hi Roger, On 12/1/2015 6:05 PM, Roger Riggs wrote: > Hi Joe, > > I do not know of any specific skew issues at the resolutions used. For > example, > Linux records the start time in ticks (1/60th to 100th of a second), > not the full resolution > of the time of day clock. Typically, the child start time is at least > a bit later > than the parent. If the maximum possible skew was known or estimated, > the comparison > could take that into account. For example, I would expect the skew > across processors > to be less than 1sec (or more likely 10ms) or there would be bigger > issues among native processes. Okay; if the start time precision is relatively coarse that reduces the hazard of a problem here. I think it is reasonable to go ahead with the current changes if is this kind of issue comes up in the future, a "fuzz" factor is determined and taken into consideration. Thanks, -Joe > > Thanks, Roger > > > On 12/1/15 8:54 PM, Joseph D. Darcy wrote: >> Hi Roger, >> >> Looks fine. >> >> Do you know if there are clock skew issues to be concerned with if >> the parent and child are spawned on different CPUs? >> >> Thanks, >> >> -Joe >> >> On 12/1/2015 5:49 PM, Roger Riggs wrote: >>> Please review this change in ProcessHandle to validate parent pids >>> provided by the OS. >>> Children of a process have start times that are the same or later >>> than the parent. >>> The implementation of descendants(), and children(), and getParent() >>> are updated to validate the parent pid. >>> >>> The problem is most pronounced on Windows; the parent pid reported >>> for a >>> process may be stale if the parent exited. The validation is >>> applied in >>> platform neutral code and used on all platforms. Platform specific >>> code >>> is used on Windows for getParent(); the Linux platforms do the right >>> thing. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8143876 >>> >>> Thanks, Roger >>> >> > From huaming.li at oracle.com Wed Dec 2 02:16:22 2015 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 2 Dec 2015 10:16:22 +0800 Subject: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping. In-Reply-To: <565D7752.4060203@oracle.com> References: <565C32EC.7050806@oracle.com> <565D7752.4060203@oracle.com> Message-ID: <565E5476.1030901@oracle.com> On 2015/12/1 18:32, Daniel Fuchs wrote: > Hi Hamlin, > > I see that you're going to push a test for this with > JDK-8144215; I will also ask for your help to push the test code after the test pass the open review. > > Looks good to me. > > Do you need a sponsor for this fix? Hi Daniel, Yes, I need a sponsor for this fix, it will be great if you could help to push the code. :-) Please check the push message below : 8144214: Some log messages will be discarded when VM is bootstrapping Summary: use logp rather than log. Reviewed-by: dfuchs Contributed-by: Hamlin Li Thank you -Hamlin > > best regards, > > -- daniel > > On 30/11/15 12:28, Hamlin Li wrote: >> Hi all, >> >> Would you please help to review for >> http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug >> https://bugs.openjdk.java.net/browse/JDK-8144214. >> >> Thank you >> -Hamlin >> > From john.r.rose at oracle.com Wed Dec 2 02:29:40 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Dec 2015 18:29:40 -0800 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <565599BB.2000109@gmail.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> <565599BB.2000109@gmail.com> Message-ID: <75C90F26-9AED-4351-A0BB-DD50E8022083@oracle.com> On Nov 25, 2015, at 3:21 AM, Peter Levart wrote: > > The mentioning of "reference component types" in javadoc for vectorizedMismatch: > > 52 /** > 53 * Find the relative index of the first mismatching pair of elements in two > 54 * arrays of the same component type. For reference component types the > 55 * reference values (as opposed to what they reference) will be matched. > 56 * Pairs of elements will be tested in order relative to given offsets into > 57 * both arrays. > > ... is probably a left-over, since there is no caller of the method using reference arrays (yet?). You should probably mention that doing so is not safe. As you might know, object pointers are a "movable target". GC can rewrite them as it moves objects around and if you "cast" an object pointer (or two of them) into a long value and store it in a long variable, GC can't track that and update the value, so you might be comparing an old address of an object with new address of the same object and get a mismatch. > > I don't know much about intrinsified code. Whether it can be interrupted by GC or not, so it might be able to compare object references directly, but then the bytecode version of the method would have to have a special-case for reference arrays if it is executed in this form anytime. Here's the scoop on reading references as ints or longs: Just don't. Calling Unsafe.getLong or Unsafe.getInt on a reference variable is never a good idea. The reason is that the GC is allowed to run between the moment the reference is picked up (as a bit image in a primitive value) and the moment something is done with it. This is rare but if it happens, it will cause the bit image to be stale, with unpredictable results. Can the GC execute if the live interval of the bit image is very, very short? Probably not if the code was compiled, but remember that the code might sometimes be interpreted also, even after it is compiled. In the case of array-mismatch, comparing a broken bit-image of a pointer against another non-broken one might produce a false equality result. Very, very rarely. And won't that be a nice surprise for someone? ? John From stuart.marks at oracle.com Wed Dec 2 02:35:57 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 1 Dec 2015 18:35:57 -0800 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) Message-ID: <565E590D.3090007@oracle.com> Hi all, Thanks for the previous round of review comments. Here's an updated API and implementation for review. I've run specdiff with the --hu ("hide unchanged") option, so only the bits of the specification that have changed are shown. As before, though, please ignore the spurious change to EnumSet caused by a javadoc bug. API changes: - add clarifying notes on immutability - remove wording that implied creation of new objects - add "value-based" disclaimers - add ordering specification for List and non-ordering disclaimers for Set and Map - clarify that Map.ofEntries() doesn't store the Map.Entry objects, instead it extracts keys and values - Map.Entry instances returned from Map.entry() are *not* serializable Other: - markup cleanups - small implementation cleanups JEP: http://openjdk.java.net/jeps/269 API spec (basically List, Map, and Set): http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ Thanks, s'marks From brian.goetz at oracle.com Wed Dec 2 03:02:54 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Dec 2015 22:02:54 -0500 Subject: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <56565448.3000801@oracle.com> References: <56540313.8070309@oracle.com> <6882C9A35DFB9B4FA2779F7BF5B9757D208647E2EC@GSCMAMP06EX.firmwide.corp.gs.com> <56565448.3000801@oracle.com> Message-ID: <565E5F5E.9000000@oracle.com> Value-based is a property of types, not of instances. For disclaimers regarding the result of factory methods, it seems clearer to go to the traditional "make no assumptions about the type, mutability, serializability, or identity..." sort of language. On 11/25/2015 7:37 PM, Stuart Marks wrote: > I think the main point of including the "value-based" admonition is to > warn developers not to depend on identity semantics of these things. > This should help preserve flexibility when/if we decide to convert > them to value types in the future. It might be that there's no > advantage in doing so, in which case we presumably won't do it. :-) > > I'm somewhat distant from the current state of the value types work, > but I can imagine that it would provide some advantage even for the > empty List. Clearly the overall heap savings wouldn't be large, since > as you point out, there's only ever a single instance. But if it were > a value type, it could live entirely on the stack, avoiding a memory > dereference, a cache miss, etc. > > s'marks > > On 11/24/15 7:52 PM, Rezaei, Mohammad A. wrote: >> Value based things make a lot of sense for types that don't belong to >> well established reference hierarchies. I can even see great uses for >> a value based List implementation, so long as it's preferentially >> referenced as the exact type (e.g. private ValueBasedList someList = >> ...) and rarely cast to the interface type (List). >> >> But I've been scratching my head about the empty collections (of()) >> and I can't figure out why value based would be a good idea. >> Currently, there is only one instance in the entire VM, so it's >> unlikely to get any memory benefits. The most likely use for the >> return value is either a variable/member of type List or something >> that can hold a List (like a Map), which will likely cause >> an immediate boxing. In some cases this can be elided (lots of >> inlining and optimization), but that's the less likely case. >> >> What's the rationale for the value based spec for the empty >> implementations? >> >> Thanks >> Moh >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>> On Behalf >>> Of John Rose >>> Sent: Tuesday, November 24, 2015 9:08 PM >>> To: Stuart Marks >>> Cc: core-libs-dev >>> Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation >>> (JDK- >>> 8139232) >>> >>> On Nov 23, 2015, at 10:26 PM, Stuart Marks >>> wrote: >>>> >>>> Please review these API and implementation changes that comprise >>>> the first >>> integration of JEP 269. I intend to push this under the "initial API >>> and >>> skeleton implementation" subtask, JDK-8139232. >>> >>> Please strengthen the specification to assert that the new >>> immutables are in >>> fact value-based. >>> >>> http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html >>> >>> >>> >>> >>> This will prevent people from relying on their identity (acmp) and >>> synchronization (monitorenter). >>> It will allow optimizations more freedom to use flatter storage >>> formats and to >>> reuse list values. >>> >>> If we don't do this now, then we will not be able to retroactively >>> make or >>> enforce the claim, >>> and the optimizations will be impossible. >>> >>> ? John From Mohammad.Rezaei at gs.com Wed Dec 2 03:11:43 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Tue, 1 Dec 2015 22:11:43 -0500 Subject: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <565E5F5E.9000000@oracle.com> References: <56540313.8070309@oracle.com> <6882C9A35DFB9B4FA2779F7BF5B9757D208647E2EC@GSCMAMP06EX.firmwide.corp.gs.com> <56565448.3000801@oracle.com> <565E5F5E.9000000@oracle.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D208647E3C4@GSCMAMP06EX.firmwide.corp.gs.com> That makes sense (and it's consistent with my layman's interpretation that List as a value-based is weird). In this particular case, I believe Stuart does want to make explicit claims for immutability and serializability. In the case of the empty methods, I don't see why a strong claim about identity can't be made. The same claim exists today in Collections.empty*. As a user of the API, the more clarity/guarantees I can get, the better I feel about using the method. If I know a method is garbage-free, for example, I will use it, but if I don't have that guarantee, I might as well do my own "static final List EMPTY = ...". Thanks Moh >-----Original Message----- >From: Brian Goetz [mailto:brian.goetz at oracle.com] >Sent: Tuesday, December 01, 2015 10:03 PM >To: Stuart Marks; Rezaei, Mohammad A. [Tech] >Cc: 'core-libs-dev' >Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK- >8139232) > >Value-based is a property of types, not of instances. > >For disclaimers regarding the result of factory methods, it seems >clearer to go to the traditional "make no assumptions about the type, >mutability, serializability, or identity..." sort of language. > > > >On 11/25/2015 7:37 PM, Stuart Marks wrote: >> I think the main point of including the "value-based" admonition is to >> warn developers not to depend on identity semantics of these things. >> This should help preserve flexibility when/if we decide to convert >> them to value types in the future. It might be that there's no >> advantage in doing so, in which case we presumably won't do it. :-) >> >> I'm somewhat distant from the current state of the value types work, >> but I can imagine that it would provide some advantage even for the >> empty List. Clearly the overall heap savings wouldn't be large, since >> as you point out, there's only ever a single instance. But if it were >> a value type, it could live entirely on the stack, avoiding a memory >> dereference, a cache miss, etc. >> >> s'marks >> >> On 11/24/15 7:52 PM, Rezaei, Mohammad A. wrote: >>> Value based things make a lot of sense for types that don't belong to >>> well established reference hierarchies. I can even see great uses for >>> a value based List implementation, so long as it's preferentially >>> referenced as the exact type (e.g. private ValueBasedList someList = >>> ...) and rarely cast to the interface type (List). >>> >>> But I've been scratching my head about the empty collections (of()) >>> and I can't figure out why value based would be a good idea. >>> Currently, there is only one instance in the entire VM, so it's >>> unlikely to get any memory benefits. The most likely use for the >>> return value is either a variable/member of type List or something >>> that can hold a List (like a Map), which will likely cause >>> an immediate boxing. In some cases this can be elided (lots of >>> inlining and optimization), but that's the less likely case. >>> >>> What's the rationale for the value based spec for the empty >>> implementations? >>> >>> Thanks >>> Moh >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>>> On Behalf >>>> Of John Rose >>>> Sent: Tuesday, November 24, 2015 9:08 PM >>>> To: Stuart Marks >>>> Cc: core-libs-dev >>>> Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation >>>> (JDK- >>>> 8139232) >>>> >>>> On Nov 23, 2015, at 10:26 PM, Stuart Marks >>>> wrote: >>>>> >>>>> Please review these API and implementation changes that comprise >>>>> the first >>>> integration of JEP 269. I intend to push this under the "initial API >>>> and >>>> skeleton implementation" subtask, JDK-8139232. >>>> >>>> Please strengthen the specification to assert that the new >>>> immutables are in >>>> fact value-based. >>>> >>>> http://docs.oracle.com/javase/8/docs/api/java/lang/doc- >files/ValueBased.html >>>> >>>> files/ValueBased.html> >>>> >>>> >>>> This will prevent people from relying on their identity (acmp) and >>>> synchronization (monitorenter). >>>> It will allow optimizations more freedom to use flatter storage >>>> formats and to >>>> reuse list values. >>>> >>>> If we don't do this now, then we will not be able to retroactively >>>> make or >>>> enforce the claim, >>>> and the optimizations will be impossible. >>>> >>>> ? John From joe.darcy at oracle.com Wed Dec 2 03:25:00 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 01 Dec 2015 19:25:00 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> Message-ID: <565E648C.9040304@oracle.com> Hi Brian, On 11/30/2015 3:24 PM, Brian Burkhalter wrote: > Hi Joe, > > On Nov 29, 2015, at 10:01 AM, joe darcy > wrote: > >> The "if (...) " logic that is repeated a few times in this method >> could be pulled out into its own method, possibly one structured a >> bit differently to return the number of errors. >> >> I think it would be acceptable to push the tests in their current >> state, but I would prefer to see a little more refactoring. >> >> I would have expected some tests to directly work off of the >> definition of integer square root, namely that k^2 is less or or >> equal to the argument but (k+1)^2 is larger. > > I have updated the patch per your comments above. The new version is here: > > http://cr.openjdk.java.net/~bpb/8032027/webrev.03/ > > > Thanks, > > Brian Current version looks okay. One more request, before pushing please add explicit test cases for the for the largest number having 63 bits and the smallest number having 64 bits. No need for another round of webrevs for that. Thanks, -Joe From martinrb at google.com Wed Dec 2 05:48:54 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 1 Dec 2015 21:48:54 -0800 Subject: RFE Pre-review: Support for cloning exceptions In-Reply-To: <565D830A.10508@gmail.com> References: <565D830A.10508@gmail.com> Message-ID: I very much want object copying to be simple and easy, but Cloneable has been under a cloud for a very long time and Effective Java Item 11 advises to stay away from it. Josh writes: """Given all of the problems associated with Cloneable, it?s safe to say that other interfaces should not extend it, and that classes designed for inheritance (Item 17) should not implement it. Because of its many shortcomings, some expert programmers simply choose never to override the clone method and never to invoke it except, perhaps, to copy arrays.""" I don't think we have any history of introducing Cloneable into an inheritance hierarchy where it was not present before. Most Throwable subclasses are "mostly" immutable, but there is no rule that they cannot have mutable state, which may be corrupted by cloning+mutating, as explained in Item 11. Technically, I think you'll need to provide a synchronized clone method on Throwable to prevent a data race, although an actual bug may be impossible to reproduce. We'd like to have Throwable.clone declared to return Throwable, but that would break subclasses that implemented Cloneable where clone returned Object. On Tue, Dec 1, 2015 at 3:22 AM, Peter Levart wrote: > Hi, > > There are at least two places in java.util.concurrent where it would be > beneficial if java.lang.Throwable was Cloneable: > > - ForkJoinTask::getException() returns original exception thrown by the > computation of the task when the task is completed exceptionally. The same > exception is re-thrown in ForkJoinTask::join() or ForkJoinTask::invoke(). > In order for the re-thrown exception to contain meaningful and > non-misleading stack-trace, the original exception is attempted to be > replaced with the exception of the same type, with original exception > attached as the cause, so both stack-traces are visible - the original > stack trace and the stack-trace of the thread executing join() or invoke(). > In order to do that, ForkJoinTask resorts to using reflection and trying to > construct new exception by invoking a constructor on the j.l.Class of the > original exception. It 1st tries the constructor taking j.l.Throwable > parameter (assumes it will be the cause) and if that doesn't work, it tries > the no-arg constructor followed by calling initCause() on the result. > > This usually works for public exceptions with suitable public > constructors, but is not guaranteed. So in case it doesn't work, it simply > re-throws the original exception with the original stack-trace, which hides > the point at which it was re-thrown (at join() or invoke()). I assume this > will become more problematic with jigsaw where constructors of non-exported > exceptions will become inaccessible. > > - CompletableFuture::whenComplete[Async]() are methods that return: "...a > new CompletionStage with the same result or exception as this stage, that > executes the given action when this stage completes...". Given 'action' is > a BiConsumer receiving the result or exception from 'this' stage, so it can > act as a clean-up action. If this cleanup throws an exception, it becomes > the result of the returned stage unless 'this' stage also completes with > exception. Like in try-with-resources, the exception thrown in the body of > try-with-resources statement has precedence over clean-up exception. > Clean-up exception is added as suppressed exception. In CompletableFuture > this presents a problem, because adding a suppressed exception to the > exception of previous stage effectively modifies the result of the previous > stage that has already completed. This is undesirable. > > So I would like to ask for feedback on a proposal to add cloning support > to java.lang.Throwable and also how to proceed if this turns out to be > acceptable (perhaps a CCC request?). > > The proposal is as follows: > > - add "implements Cloneable" to the j.l.Throwable > > - add the following public static method to j.l.Throwable: > > > /** > * Returns a {@link Object#clone() clone} of given {@code exception} > * which shares all state with original exception (shallow clone) and > is > * augmented in the following way: > *

> * If {@code resetCause} parameter is {@code true}, then clone's > * {@link #getCause() cause} is reset to an uninitialized state so it > can be > * {@link #initCause(Throwable) initialized} again. If {@code > resetCause} > * parameter is {@code false}, then clone's cause is inherited from > original > * exception (either initialized or uninitialized). > *

> * If {@code resetSuppressed} parameter is {@code true} and original > exception > * has suppression enabled, then clone's suppressed exceptions are > cleared. > * If {@code resetSuppressed} parameter is {@code false} > * (or original exception has suppression disabled) then clone's > * suppressed exceptions are inherited from original exception (or > clone's > * suppression is disabled too). In either case, clone's suppressed > * exceptions are independent of original exception's suppressed > * exceptions. Any further {@link #addSuppressed(Throwable) additions} > to > * the clone's suppressed exceptions do not affect original exception's > * suppressed exceptions and vice versa. > * > * @param exception the exception to clone. > * @param the type of exception > * @param resetCause if {@code true}, clone's cause is reset to an > * uninitialized state. > * @param resetSuppressed if {@code true} and original exception has > suppression > * enabled, clone's suppressed exceptions are > cleared. > * @return shallow clone of given exception augmented according to > passed-in > * flags. > * @since 1.9 > */ > @SuppressWarnings("unchecked") > public static T clone(T exception, > boolean resetCause, > boolean resetSuppressed) { > try { > synchronized (exception) { > Throwable clone = (Throwable) exception.clone(); > if (resetCause) { > // reset to uninitialized state > clone.cause = clone; > } > if (clone.suppressedExceptions != null && > clone.suppressedExceptions != SUPPRESSED_SENTINEL) { > // suppressedExceptions has already been added to > // and suppression is enabled > clone.suppressedExceptions = resetSuppressed > ? new ArrayList<>() > : new ArrayList<>(clone.suppressedExceptions); > } > return (T) clone; > } > } catch (CloneNotSupportedException e) { > throw new InternalError(e); > } > } > > > > In ForkJoinTask the code to construct the re-thrown exception could be > reduce to: > > Throwable original = ...; > > Throwable rethrown = Throwable.clone(original, true, > true).fillInStackTrace().initCause(original); > > > In CompletableFuture::whenComplete[Async] the exceptional result of the > new stage in case of both original and cleanup exceptions could be computed > as: > > Throwable original = ...; > Throwable cleanup = ...; > > Throwable result = Throwable.clone(original, false, false); > result.addSuppressed(cleanup); > > > > So what do you think of adding such feature and do you see any problems > with it? > > > Regards, Peter > > > From stuart.marks at oracle.com Wed Dec 2 06:25:01 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 1 Dec 2015 22:25:01 -0800 Subject: RFR(xxs): 8143858: typo in Timer.purge() doc Message-ID: <565E8EBD.4060708@oracle.com> Hi all, Please review this tiny fix for a typo in the the documentation of the Timer.purge() method. Diff appended below. Thanks! s'marks # HG changeset patch # User smarks # Date 1449025313 28800 # Tue Dec 01 19:01:53 2015 -0800 # Node ID 01aa186248334bf669f075dd7913391b07387747 # Parent 8c9484fe1bb22b13e873ef8fcaeeff234e4dabca 8143858: typo in Timer.purge() doc Reviewed-by: XXX diff -r 8c9484fe1bb2 -r 01aa18624833 src/java.base/share/classes/java/util/Timer.java --- a/src/java.base/share/classes/java/util/Timer.java Tue Dec 01 09:22:01 2015 +0100 +++ b/src/java.base/share/classes/java/util/Timer.java Tue Dec 01 19:01:53 2015 -0800 @@ -447,7 +447,7 @@ * is the number of tasks in the queue and c is the number of cancelled * tasks. * - *

Note that it is permissible to call this method from within a + *

Note that it is permissible to call this method from within * a task scheduled on this timer. * * @return the number of tasks removed from the queue. From joe.darcy at oracle.com Wed Dec 2 06:26:39 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 1 Dec 2015 22:26:39 -0800 Subject: RFR(xxs): 8143858: typo in Timer.purge() doc In-Reply-To: <565E8EBD.4060708@oracle.com> References: <565E8EBD.4060708@oracle.com> Message-ID: <565E8F1F.1060207@oracle.com> Look good, -Joe On 12/1/2015 10:25 PM, Stuart Marks wrote: > Hi all, > > Please review this tiny fix for a typo in the > the documentation of the Timer.purge() method. > > Diff appended below. > > Thanks! > > s'marks > > # HG changeset patch > # User smarks > # Date 1449025313 28800 > # Tue Dec 01 19:01:53 2015 -0800 > # Node ID 01aa186248334bf669f075dd7913391b07387747 > # Parent 8c9484fe1bb22b13e873ef8fcaeeff234e4dabca > 8143858: typo in Timer.purge() doc > Reviewed-by: XXX > > diff -r 8c9484fe1bb2 -r 01aa18624833 > src/java.base/share/classes/java/util/Timer.java > --- a/src/java.base/share/classes/java/util/Timer.java Tue Dec 01 > 09:22:01 2015 +0100 > +++ b/src/java.base/share/classes/java/util/Timer.java Tue Dec 01 > 19:01:53 2015 -0800 > @@ -447,7 +447,7 @@ > * is the number of tasks in the queue and c is the number of > cancelled > * tasks. > * > - *

Note that it is permissible to call this method from within a > + *

Note that it is permissible to call this method from within > * a task scheduled on this timer. > * > * @return the number of tasks removed from the queue. From huaming.li at oracle.com Wed Dec 2 07:14:48 2015 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 2 Dec 2015 15:14:48 +0800 Subject: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service In-Reply-To: <565D7934.8080201@oracle.com> References: <565D1604.3000508@oracle.com> <565D7934.8080201@oracle.com> Message-ID: <565E9A67.4000608@oracle.com> Hi Daniel, Thanks for the review, I follow you suggestion to create a new RFE https://bugs.openjdk.java.net/browse/JDK-8144460 to track the pushing for this new test. webrev : http://cr.openjdk.java.net/~mli/8144460/webrev.01/ old one is moved to http://cr.openjdk.java.net/~mli/8144460/webrev.00/ Thank you -Hamlin On 2015/12/1 18:40, Daniel Fuchs wrote: > Hi Hamlin, > > You should probably create a new open RFE for pushing this new > test. > I'm not sure we can use internal task ids in commit/push comments. > > From looking at the test, it would be preferable to create > the loggers after setting up the stub that pretend that the > VM is not yet booted. In other words - in BootstrapLoggerAPIsTest > lines 53-56 should preferably be moved after line 74. > > best regards, > > -- daniel > > On 01/12/15 04:37, Hamlin Li wrote: >> Hi all, >> >> Would you please help to review the test development of JDK-8144215 >> : Test development >> task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and >> Service. >> webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ >> >> Thank you >> -Hamlin > From paul.sandoz at oracle.com Wed Dec 2 08:52:12 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 09:52:12 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> Message-ID: <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> Hi Christian, > On 1 Dec 2015, at 20:19, Christian Tornqvist wrote: > > Hi Paul, > > Tests in hotspot/test/runtime needs to be jtreg tests. They are jtreg tests. They are require to be run (re: ?launched") with jtreg see: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html 24 /* 25 * @test 26 * @bug 8143628 27 * @summary Test unsafe access for boolean 28 * @modules java.base/jdk.internal.misc 29 * @run testng/othervm -Diters=100 -Xint JdkInternalMiscUnsafeAccessTestBoolean 30 * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 JdkInternalMiscUnsafeAccessTestBoolean 31 * @run testng/othervm -Diters=20000 -XX:-TieredCompilation JdkInternalMiscUnsafeAccessTestBoolean 32 * @run testng/othervm -Diters=20000 JdkInternalMiscUnsafeAccessTestBoolean 33 */ That?s the point i was making with: jtreg is to testng as launcher is to library Note the use of the "@modules java.base/jdk.internal.misc?. That?s gonna be important later on. > Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? That?s not the point. There is a principle here about what test libraries one can or cannot use with the test in a particular area of a particular repo. At the moment i am not hearing any consistent and solid technical argument as to why testng cannot be used for HotSpot runtime tests. Paul. From daniel.fuchs at oracle.com Wed Dec 2 08:53:55 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Dec 2015 09:53:55 +0100 Subject: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service In-Reply-To: <565E9A67.4000608@oracle.com> References: <565D1604.3000508@oracle.com> <565D7934.8080201@oracle.com> <565E9A67.4000608@oracle.com> Message-ID: <565EB1A3.80904@oracle.com> Hi Hamlin, This looks good to me. I can sponsor this change. best regards, -- daniel On 12/2/15 8:14 AM, Hamlin Li wrote: > Hi Daniel, > > Thanks for the review, I follow you suggestion to create a new RFE > https://bugs.openjdk.java.net/browse/JDK-8144460 to track the pushing > for this new test. > webrev : http://cr.openjdk.java.net/~mli/8144460/webrev.01/ > old one is moved to http://cr.openjdk.java.net/~mli/8144460/webrev.00/ > > Thank you > -Hamlin > > On 2015/12/1 18:40, Daniel Fuchs wrote: >> Hi Hamlin, >> >> You should probably create a new open RFE for pushing this new >> test. >> I'm not sure we can use internal task ids in commit/push comments. >> >> From looking at the test, it would be preferable to create >> the loggers after setting up the stub that pretend that the >> VM is not yet booted. In other words - in BootstrapLoggerAPIsTest >> lines 53-56 should preferably be moved after line 74. >> >> best regards, >> >> -- daniel >> >> On 01/12/15 04:37, Hamlin Li wrote: >>> Hi all, >>> >>> Would you please help to review the test development of JDK-8144215 >>> : Test development >>> task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and >>> Service. >>> webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ >>> >>> Thank you >>> -Hamlin >> > From paul.sandoz at oracle.com Wed Dec 2 09:10:37 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 10:10:37 +0100 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <565E4F7A.2050607@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> <565E4F7A.2050607@oracle.com> Message-ID: <938E28F6-2FB9-46E5-B13F-D4535112F81E@oracle.com> > On 2 Dec 2015, at 02:55, Vladimir Kozlov wrote: > > I reviewed 8143355 today and my main question is where are range checks? > In this case the range checks are performed by the methods in Arrays, which call non-checking type-specific methods in ArraysSupport that in turn call vectorizedMismatch e.g: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/Arrays.java.sdiff.html 2861 @HotSpotIntrinsicCandidate 2862 public static boolean equals(byte[] a, byte[] a2) { 2863 if (a==a2) 2864 return true; 2865 if (a==null || a2==null) 2866 return false; 2867 2868 int length = a.length; 2869 if (a2.length != length) 2870 return false; 2871 2872 return ArraysSupport.mismatch(a, a2, length) < 0; 2873 } 2907 public static boolean equals(byte[] a, int aFromIndex, int aToIndex, 2908 byte[] b, int bFromIndex, int bToIndex) { 2909 rangeCheck(a.length, aFromIndex, aToIndex); 2910 rangeCheck(b.length, bFromIndex, bToIndex); 2911 2912 int aLength = aToIndex - aFromIndex; 2913 int bLength = bToIndex - bFromIndex; 2914 if (aLength != bLength) 2915 return false; 2916 2917 return ArraysSupport.mismatch(a, aFromIndex, 2918 b, bFromIndex, 2919 aLength) < 0; 2920 } 5875 public static int compare(byte[] a, byte[] b) { 5876 if (a == b) 5877 return 0; 5878 if (a == null || b == null) 5879 return a == null ? -1 : 1; 5880 5881 int i = ArraysSupport.mismatch(a, b, 5882 Math.min(a.length, b.length)); 5883 if (i >= 0) { 5884 return Byte.compare(a[i], b[i]); 5885 } 5886 5887 return a.length - b.length; 5888 } 5950 public static int compare(byte[] a, int aFromIndex, int aToIndex, 5951 byte[] b, int bFromIndex, int bToIndex) { 5952 rangeCheck(a.length, aFromIndex, aToIndex); 5953 rangeCheck(b.length, bFromIndex, bToIndex); 5954 5955 int aLength = aToIndex - aFromIndex; 5956 int bLength = bToIndex - bFromIndex; 5957 int i = ArraysSupport.mismatch(a, aFromIndex, 5958 b, bFromIndex, 5959 Math.min(aLength, bLength)); 5960 if (i >= 0) { 5961 return Byte.compare(a[aFromIndex + i], b[bFromIndex + i]); 5962 } 5963 5964 return aLength - bLength; 5965 } There are existing tests in place verifying that exceptions are thrown for out of bounds conditions. Paul. From daniel.fuchs at oracle.com Wed Dec 2 09:20:34 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Dec 2015 10:20:34 +0100 Subject: RFR 6856817: Poor performance of Writer#append with CharBuffer In-Reply-To: <5655C5B0.2050305@oracle.com> References: <5655C5B0.2050305@oracle.com> Message-ID: <565EB7E2.9060708@oracle.com> Hi Vyom, Looks good to me too. If you don't get more comments from reviewers, send me the exported changeset and I'll push it for you. best regards, -- daniel On 11/25/15 3:29 PM, vyom wrote: > Hi All, > > Please review my changes for below bug. > > Bug: JDK-6856817 : Poor performance of Writer#append with > CharBuffer > Webrev: http://cr.openjdk.java.net/~vtewari/6856817/webrev0.4/ > > > This change will avoid the redundant toString/CharBuffer.wrap in case > of OutputStreamWriter.append(CharBuffer). > > In case of OutputStreamWriter.append(CharBuffer) we are doing > CharBuffer->String->char[]->CharBuffer conversion this change will > avoid redundant conversion. > > Thanks, > Vyom > From peter.levart at gmail.com Wed Dec 2 09:32:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 2 Dec 2015 10:32:22 +0100 Subject: RFE Pre-review: Support for cloning exceptions In-Reply-To: References: <565D830A.10508@gmail.com> Message-ID: <565EBAA6.7080402@gmail.com> Hi Martin, On 12/02/2015 06:48 AM, Martin Buchholz wrote: > I very much want object copying to be simple and easy, but Cloneable > has been under a cloud for a very long time and Effective Java Item 11 > advises to stay away from it. I'm aware of potential problems with clone() method in general. But given that exceptions are a special kind of hierarchy which is typically kept very simple (they even have a constraint that they can't be generic types) and in which most of the times, Throwable subclasses are not adding state, and if they do, it is mostly immutable, and given that this proposal is about solving the problem some parallelizing/asynchronous execution frameworks have or might have with propagating exceptions from other threads where the mutable state that must be copied or replaced consists solely from the state declared in Throwable, I think that in practice this would not pose real problems. In the two examples given, the alternative or status quo is to propagate original exception, which is in both cases worse than using a clone constructed with this proposal. > > Josh writes: """Given all of the problems associated with Cloneable, > it?s safe to say that other interfaces should not extend it, and that > classes designed for inheritance (Item 17) should not implement it. > Because of its many shortcomings, some expert programmers simply > choose never to override the clone method and never to invoke it > except, perhaps, to copy arrays.""" > > I don't think we have any history of introducing Cloneable into an > inheritance hierarchy where it was not present before. Most Throwable > subclasses are "mostly" immutable, but there is no rule that they > cannot have mutable state, which may be corrupted by cloning+mutating, > as explained in Item 11. If code mutates some state in a Throwable subclass, it must be aware of whether this state is shared with another instance or not. If it expects it is safe to mutate that state, but is given an instance that shares that state with another instance, we can get unpredictable behavior. Exceptions are generally constructed and mutated in one place and then treated as objects that don't change state. This particular usage pattern minimizes the risks - the code that mutates the state of an exception would usually be aware of where it comes from and whether it is safe to do that. > > Technically, I think you'll need to provide a synchronized clone > method on Throwable to prevent a data race, although an actual bug may > be impossible to reproduce. We'd like to have Throwable.clone > declared to return Throwable, but that would break subclasses that > implemented Cloneable where clone returned Object. The proposal is adding a static method and not overriding Object.clone(). This is to keep behavior of possible Throwable subclasses that already implement Cloneable. The static method is just invoking clone() and is synchronizing on the original exception. This is to make sure, Throwable part of original exception's state is not mutated while it is being cloned. That state consists only of the list of suppressed exceptions. Subclasses that wanted to copy their mutable subclass state when cloned, would have to do their own synchronization. There's nothing a synchronized instance Throwable.clone() could do to help them. It would be tempting to override Object.clone() in Throwable and make it final, but that would break any possible existing subclasses that override clone(). The only thing I would change in the proposal is the handling of CloneNotSupportedException. I would not handle it. If a Throwable subclass wishes to prevent cloning of it's instances, it could override clone() and throw CloneNotSupportedException. This would give subclasses a possibility to opt-out. For example, some exceptions might be designed to be immutable singletons for some reason. Users of static Throwable.clone() would have to respect that (probably by passing the unchanged original exception on). In short, I think exceptions are a special hierarchy with special use pattern in which clone() would not present a practical problem that generally arises in other objects that are meant to change state independently from their creation. Regards, Peter > > > On Tue, Dec 1, 2015 at 3:22 AM, Peter Levart > wrote: > > Hi, > > There are at least two places in java.util.concurrent where it > would be beneficial if java.lang.Throwable was Cloneable: > > - ForkJoinTask::getException() returns original exception thrown > by the computation of the task when the task is completed > exceptionally. The same exception is re-thrown in > ForkJoinTask::join() or ForkJoinTask::invoke(). In order for the > re-thrown exception to contain meaningful and non-misleading > stack-trace, the original exception is attempted to be replaced > with the exception of the same type, with original exception > attached as the cause, so both stack-traces are visible - the > original stack trace and the stack-trace of the thread executing > join() or invoke(). In order to do that, ForkJoinTask resorts to > using reflection and trying to construct new exception by invoking > a constructor on the j.l.Class of the original exception. It 1st > tries the constructor taking j.l.Throwable parameter (assumes it > will be the cause) and if that doesn't work, it tries the no-arg > constructor followed by calling initCause() on the result. > > This usually works for public exceptions with suitable public > constructors, but is not guaranteed. So in case it doesn't work, > it simply re-throws the original exception with the original > stack-trace, which hides the point at which it was re-thrown (at > join() or invoke()). I assume this will become more problematic > with jigsaw where constructors of non-exported exceptions will > become inaccessible. > > - CompletableFuture::whenComplete[Async]() are methods that > return: "...a new CompletionStage with the same result or > exception as this stage, that executes the given action when this > stage completes...". Given 'action' is a BiConsumer receiving the > result or exception from 'this' stage, so it can act as a clean-up > action. If this cleanup throws an exception, it becomes the result > of the returned stage unless 'this' stage also completes with > exception. Like in try-with-resources, the exception thrown in the > body of try-with-resources statement has precedence over clean-up > exception. Clean-up exception is added as suppressed exception. In > CompletableFuture this presents a problem, because adding a > suppressed exception to the exception of previous stage > effectively modifies the result of the previous stage that has > already completed. This is undesirable. > > So I would like to ask for feedback on a proposal to add cloning > support to java.lang.Throwable and also how to proceed if this > turns out to be acceptable (perhaps a CCC request?). > > The proposal is as follows: > > - add "implements Cloneable" to the j.l.Throwable > > - add the following public static method to j.l.Throwable: > > > /** > * Returns a {@link Object#clone() clone} of given {@code > exception} > * which shares all state with original exception (shallow > clone) and is > * augmented in the following way: > *

> * If {@code resetCause} parameter is {@code true}, then clone's > * {@link #getCause() cause} is reset to an uninitialized > state so it can be > * {@link #initCause(Throwable) initialized} again. If {@code > resetCause} > * parameter is {@code false}, then clone's cause is inherited > from original > * exception (either initialized or uninitialized). > *

> * If {@code resetSuppressed} parameter is {@code true} and > original exception > * has suppression enabled, then clone's suppressed exceptions > are cleared. > * If {@code resetSuppressed} parameter is {@code false} > * (or original exception has suppression disabled) then clone's > * suppressed exceptions are inherited from original exception > (or clone's > * suppression is disabled too). In either case, clone's > suppressed > * exceptions are independent of original exception's suppressed > * exceptions. Any further {@link #addSuppressed(Throwable) > additions} to > * the clone's suppressed exceptions do not affect original > exception's > * suppressed exceptions and vice versa. > * > * @param exception the exception to clone. > * @param the type of exception > * @param resetCause if {@code true}, clone's cause is > reset to an > * uninitialized state. > * @param resetSuppressed if {@code true} and original > exception has suppression > * enabled, clone's suppressed > exceptions are cleared. > * @return shallow clone of given exception augmented > according to passed-in > * flags. > * @since 1.9 > */ > @SuppressWarnings("unchecked") > public static T clone(T exception, > boolean resetCause, > boolean > resetSuppressed) { > try { > synchronized (exception) { > Throwable clone = (Throwable) exception.clone(); > if (resetCause) { > // reset to uninitialized state > clone.cause = clone; > } > if (clone.suppressedExceptions != null && > clone.suppressedExceptions != > SUPPRESSED_SENTINEL) { > // suppressedExceptions has already been added to > // and suppression is enabled > clone.suppressedExceptions = resetSuppressed > ? new ArrayList<>() > : new ArrayList<>(clone.suppressedExceptions); > } > return (T) clone; > } > } catch (CloneNotSupportedException e) { > throw new InternalError(e); > } > } > > > > In ForkJoinTask the code to construct the re-thrown exception > could be reduce to: > > Throwable original = ...; > > Throwable rethrown = Throwable.clone(original, true, > true).fillInStackTrace().initCause(original); > > > In CompletableFuture::whenComplete[Async] the exceptional result > of the new stage in case of both original and cleanup exceptions > could be computed as: > > Throwable original = ...; > Throwable cleanup = ...; > > Throwable result = Throwable.clone(original, false, false); > result.addSuppressed(cleanup); > > > > So what do you think of adding such feature and do you see any > problems with it? > > > Regards, Peter > > > From michael.haupt at oracle.com Wed Dec 2 09:34:11 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 2 Dec 2015 10:34:11 +0100 Subject: RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping Message-ID: Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ The bug was actually fixed by the fix to https://bugs.openjdk.java.net/browse/JDK-8136893; the proposed change adds a test for the original bug. It is not reproducible in current 9-dev and jake builds. Thanks, Michael -- 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 is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Wed Dec 2 09:47:18 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 2 Dec 2015 15:17:18 +0530 Subject: RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping In-Reply-To: References: Message-ID: <565EBE26.9010005@oracle.com> +1 -Sundar On 12/2/2015 3:04 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 > Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ > > The bug was actually fixed by the fix to https://bugs.openjdk.java.net/browse/JDK-8136893; the proposed change adds a test for the original bug. It is not reproducible in current 9-dev and jake builds. > > Thanks, > > Michael > From vladimir.x.ivanov at oracle.com Wed Dec 2 10:13:42 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2015 13:13:42 +0300 Subject: RFR: 8143131: Remove unused code from java.lang.invoke In-Reply-To: <565DC57F.4010308@oracle.com> References: <565DC57F.4010308@oracle.com> Message-ID: <565EC456.3000701@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 12/1/15 7:06 PM, Claes Redestad wrote: > Hi, > > please review this patch to cleanup various things in and around > java.lang.invoke: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 > Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ > > /Claes From vladimir.x.ivanov at oracle.com Wed Dec 2 10:22:29 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2015 13:22:29 +0300 Subject: RFR: 8143131: Remove unused code from java.lang.invoke In-Reply-To: <565DC57F.4010308@oracle.com> References: <565DC57F.4010308@oracle.com> Message-ID: <565EC665.70509@oracle.com> FTR IBG.localTypes was used for LambdaForm inlining [1] during MethodHandle customization prototype I did while working on LambdaForm caching. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/lfc/enhancements/lf.inline On 12/1/15 7:06 PM, Claes Redestad wrote: > Hi, > > please review this patch to cleanup various things in and around > java.lang.invoke: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 > Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ > > /Claes From vladimir.x.ivanov at oracle.com Wed Dec 2 10:39:07 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2015 13:39:07 +0300 Subject: RFR(XS): 8076596: BytecodeDescriptor.parseMethod doesn't work during bootstrapping In-Reply-To: References: Message-ID: <565ECA4B.6020005@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/2/15 12:34 PM, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8076596 > Webrev: http://cr.openjdk.java.net/~mhaupt/8076596/webrev.00/ > > The bug was actually fixed by the fix to https://bugs.openjdk.java.net/browse/JDK-8136893; the proposed change adds a test for the original bug. It is not reproducible in current 9-dev and jake builds. > > Thanks, > > Michael > From chris.hegarty at oracle.com Wed Dec 2 12:08:38 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 12:08:38 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder Message-ID: <565EDF46.2080602@oracle.com> The regression tests in the jdk should be updated, where possible, to use java.util.Base64. http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ -Chris. From claes.redestad at oracle.com Wed Dec 2 13:24:39 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 02 Dec 2015 14:24:39 +0100 Subject: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character In-Reply-To: <564CFB05.8080901@oracle.com> References: <564B532E.6000906@oracle.com> <142916502.1330400.1447794836696.JavaMail.zimbra@u-pem.fr> <564BA577.1030701@oracle.com> <564CFB05.8080901@oracle.com> Message-ID: <565EF117.5090804@oracle.com> On 2015-11-18 23:26, Aleksey Shipilev wrote: > By the way, I see there is a cleaner way to implement emitIconstInsn, > see java.lang.invoke.TypeConvertingMethodAdapter.iconst: > > void iconst(final int cst) { > if (cst >= -1 && cst <= 5) { > mv.visitInsn(Opcodes.ICONST_0 + cst); > } else if (cst >= Byte.MIN_VALUE && cst <= Byte.MAX_VALUE) { > mv.visitIntInsn(Opcodes.BIPUSH, cst); > } else if (cst >= Short.MIN_VALUE && cst <= Short.MAX_VALUE) { > mv.visitIntInsn(Opcodes.SIPUSH, cst); > } else { > mv.visitLdcInsn(cst); > } > } > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/aa9e8b3916ae/src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java#l285 > Nice catch. Picking up this tiny improvement again, I realized there are a few other bytecode minifying tricks we could consider while we're at it: http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ It would probably make sense to move emitConst to TypeConvertingMethodAdapter and use that in place a raw MethodVisitor - removing some code - but there might be some reasons not to (bootstrapping?). For this improvement I opt to keep the changes contained inside InvokerBytecodeGenerator. unless someone insists. /Claes From miroslav.kos at oracle.com Wed Dec 2 13:39:37 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 2 Dec 2015 14:39:37 +0100 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: Message-ID: <565EF499.6040709@oracle.com> 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 > +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > Tue Oct 27 19:48:35 2015 +0900 > @@ -38,6 +38,7 @@ > import java.util.concurrent.ExecutorService; > import java.util.concurrent.Executors; > import java.util.logging.Logger; > +import java.util.Optional; > > /** > * Manages all the WebService HTTP servers created by JAXWS runtime. > @@ -81,24 +82,38 @@ > synchronized(servers) { > state = servers.get(inetAddress); > if (state == null) { > - logger.fine("Creating new HTTP Server at "+inetAddress); > - // Creates server with default socket backlog > - server = HttpServer.create(inetAddress, 0); > - server.setExecutor(Executors.newCachedThreadPool()); > - String path = url.toURI().getPath(); > - logger.fine("Creating HTTP Context at = "+path); > - HttpContext context = server.createContext(path); > - server.start(); > + final int finalPortNum = port; > + Optional stateOpt = > + servers.values() > + .stream() > + .filter(s -> s.getServer() > + .getAddress() > + .getPort() == > finalPortNum) > + .findAny(); > > - // we have to get actual inetAddress from server, > which can differ from the original in some cases. > - // e.g. A port number of zero will let the system > pick up an ephemeral port in a bind operation, > - // or IP: 0.0.0.0 - which is used to monitor > network traffic from any valid IP address > - inetAddress = server.getAddress(); > + if (inetAddress.getAddress().isAnyLocalAddress() && > + stateOpt.isPresent()) { > + state = stateOpt.get(); > + } else { > + logger.fine("Creating new HTTP Server at > "+inetAddress); > + // Creates server with default socket backlog > + server = HttpServer.create(inetAddress, 0); > + server.setExecutor(Executors.newCachedThreadPool()); > + String path = url.toURI().getPath(); > + logger.fine("Creating HTTP Context at = "+path); > + HttpContext context = server.createContext(path); > + server.start(); > > - logger.fine("HTTP server started = "+inetAddress); > - state = new ServerState(server, path); > - servers.put(inetAddress, state); > - return context; > + // we have to get actual inetAddress from > server, which can differ from the original in some cases. > + // e.g. A port number of zero will let the > system pick up an ephemeral port in a bind operation, > + // or IP: 0.0.0.0 - which is used to monitor > network traffic from any valid IP address > + inetAddress = server.getAddress(); > + > + logger.fine("HTTP server started = "+inetAddress); > + state = new ServerState(server, path); > + servers.put(inetAddress, state); > + return context; > + } > } > } > server = state.getServer(); > --- > > Thanks, > Yuji From paul.sandoz at oracle.com Wed Dec 2 13:42:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 14:42:14 +0100 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EDF46.2080602@oracle.com> References: <565EDF46.2080602@oracle.com> Message-ID: > On 2 Dec 2015, at 13:08, Chris Hegarty wrote: > > The regression tests in the jdk should be updated, where possible, to use java.util.Base64. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ > +1 Paul. From Alan.Bateman at oracle.com Wed Dec 2 14:03:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Dec 2015 14:03:01 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EDF46.2080602@oracle.com> References: <565EDF46.2080602@oracle.com> Message-ID: <565EFA15.3050504@oracle.com> On 02/12/2015 12:08, Chris Hegarty wrote: > The regression tests in the jdk should be updated, where possible, to > use java.util.Base64. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ Should S11N be updated to serialize with JDK 8 so that the core reflection code isn't needed? -Alan From chris.hegarty at oracle.com Wed Dec 2 14:15:10 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 14:15:10 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFA15.3050504@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> Message-ID: <565EFCEE.6010501@oracle.com> On 02/12/15 14:03, Alan Bateman wrote: > > On 02/12/2015 12:08, Chris Hegarty wrote: >> The regression tests in the jdk should be updated, where possible, to >> use java.util.Base64. >> >> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ > Should S11N be updated to serialize with JDK 8 so that the core > reflection code isn't needed? This is certainly possible and would make the test simpler, but I followed the comments in the test ( it needs to be runnable on older JDKs ). I think this is a reasonable requirement since the test contains bytes array that were generated on older JDKs. Of course, the test could contain the older JDK code commented out. If someone really wants to run it with 1.6, then they just make the simple edits. I'm ok with any of these solutions, or just removing the possibility of running on older JDKs. -Chris. From michael.haupt at oracle.com Wed Dec 2 14:28:40 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 2 Dec 2015 15:28:40 +0100 Subject: RFR(S): 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest Message-ID: Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8143343 Webrev: http://cr.openjdk.java.net/~mhaupt/8143343/webrev.00 The change adds the JEP 274 Javadoc tests to JavaDocExamplesTest and fixes three glitches in the pertaining Javadoc. Thanks, Michael -- 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 is committed to developing practices and products that help protect the environment From weijun.wang at oracle.com Wed Dec 2 14:52:32 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 22:52:32 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFCEE.6010501@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. Thanks Max > On Dec 2, 2015, at 10:15 PM, Chris Hegarty wrote: > > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris Hegarty wrote: >>> The regression tests in the jdk should be updated, where possible, to >>> use java.util.Base64. >>> >>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >> Should S11N be updated to serialize with JDK 8 so that the core >> reflection code isn't needed? > > This is certainly possible and would make the test simpler, but > I followed the comments in the test ( it needs to be runnable on > older JDKs ). I think this is a reasonable requirement since the > test contains bytes array that were generated on older JDKs. Of > course, the test could contain the older JDK code commented out. > If someone really wants to run it with 1.6, then they just make > the simple edits. > > I'm ok with any of these solutions, or just removing the possibility > of running on older JDKs. > > -Chris. From dl at cs.oswego.edu Wed Dec 2 14:56:24 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 2 Dec 2015 09:56:24 -0500 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56572F4E.8050603@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> Message-ID: <565F0698.7080600@cs.oswego.edu> Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936) to the lists: Approximately 100% of the cases of StackOverflowError (SOE) we hear about lately on concurrency-interest are due to long chains of CompletableFutures that exist because of the lack of tail-recursion loopification by compilers. I don't think any of these have involved ReentrantLocks, but some hit problems due to lack of finally { ... } cleanup inside Executors upon SOE. In the absence of any of: tail-recursion support, reliable cleanup, or growable stacks, it seems reasonable to choose larger default stack sizes so that these long but finite chains of completions are far less likely to hit SOE. On 32bit systems the 1MB limit is completely defensible. But expanding to say 64MB on 64bit systems would reduce practical encounters with SOE in these kinds of constructions by a factor of 64 or so. Is there any reason not to do this? -Doug From chris.hegarty at oracle.com Wed Dec 2 15:03:42 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 15:03:42 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565EFCEE.6010501@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: <565F084E.505@oracle.com> Updated to remove all use of reflection. If someone really wants to run S11N on an older JDK, then it is a simple edit to uncomment/comment 3 lines. http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ -Chris. On 02/12/15 14:15, Chris Hegarty wrote: > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris Hegarty wrote: >>> The regression tests in the jdk should be updated, where possible, to >>> use java.util.Base64. >>> >>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >> Should S11N be updated to serialize with JDK 8 so that the core >> reflection code isn't needed? > > This is certainly possible and would make the test simpler, but > I followed the comments in the test ( it needs to be runnable on > older JDKs ). I think this is a reasonable requirement since the > test contains bytes array that were generated on older JDKs. Of > course, the test could contain the older JDK code commented out. > If someone really wants to run it with 1.6, then they just make > the simple edits. > > I'm ok with any of these solutions, or just removing the possibility > of running on older JDKs. > > -Chris. From aph at redhat.com Wed Dec 2 15:07:26 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Dec 2015 15:07:26 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F0698.7080600@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> Message-ID: <565F092E.2060807@redhat.com> On 12/02/2015 02:56 PM, Doug Lea wrote: > On 32bit systems the 1MB limit is completely defensible. But expanding > to say 64MB on 64bit systems would reduce practical encounters with > SOE in these kinds of constructions by a factor of 64 or so. > Is there any reason not to do this? Some cloud VMs do not over-commit memory. This means they make sure that all of the memory which is allocated really is available. On such systems, pre-allocating 64M would be a Bad Thing. Andrew. From weijun.wang at oracle.com Wed Dec 2 15:13:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 23:13:47 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> Message-ID: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> > On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: > > My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. > > Thanks > Max From chris.hegarty at oracle.com Wed Dec 2 15:26:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 2 Dec 2015 15:26:07 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> Message-ID: <565F0D8F.2070103@oracle.com> Thanks Max, I'm ok with this version, if you are. I'll include it in the final push. -Chris. On 02/12/15 15:13, Wang Weijun wrote: > >> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: >> >> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. >> >> Thanks >> Max From weijun.wang at oracle.com Wed Dec 2 15:34:02 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 2 Dec 2015 23:34:02 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F0D8F.2070103@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> <565F0D8F.2070103@oracle.com> Message-ID: > On Dec 2, 2015, at 11:26 PM, Chris Hegarty wrote: > > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. Please. --Max > > -Chris. > > On 02/12/15 15:13, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote: >>> >>> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. >>> >>> Thanks >>> Max From jason_mehrens at hotmail.com Wed Dec 2 15:52:11 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 2 Dec 2015 15:52:11 +0000 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: <565E459C.9070702@oracle.com> References: <565DEB92.6040502@oracle.com>,<565E459C.9070702@oracle.com> Message-ID: My original thinking was that it not so much that 3rd party code doesn't care about nanoseconds it just that the code was built before the concept of nano time was added to LogRecords. The use cases for LogRecord.getMillis are: 1.g - Formatters for rendering the event time. 2.g - Filters for throttling bursts of events. 3.g - Comparators for ordering events along with getting the sequence for tie breaking. 4.g - Consumer bridges of the java.util.logging framework. The use cases for LogRecord.setMillis are: 1.s - Unit tests. 2.s - Logging framework bridges. 3.s - Type conversions of LogRecords to another subclass of LogRecord (GlassFish) Note that even the logging framework itself doesn't call setMillis because the time is set in the LogRecord constructor. All of the uses of setMillis are closer to the producer of a log record and the uses of getMillis are closer to the consumer of a log record. Ideally if we are choose to lose precision it shouldn't impact other consumers down stream. The reason to keep setMillis deprecated is that calling this method makes the choice to lose precision ahead of other code that was interested in that extra precision. Out of the list of getMillis callers, 4.g is about the only reason to deprecate getMillis (assuming the bridge has support for nanos). Everyone else is choosing their fate without choosing the fate of others. Under the current proposal, I would have to suppress or add "some fine hackery" to unit tests which seems like a fair trade off since that keeps the code smell out of the released production code. Jason ________________________________________ From: Stuart Marks Sent: Tuesday, December 1, 2015 7:13 PM To: Daniel Fuchs Cc: Jason Mehrens; Core-Libs-Dev Subject: Re: Deprecation of LogRecord.getMillis in JDK9 I think #3 or a variation is best. Clearly, #1 is inconsistent and simply documenting it (#2) isn't much better. I'd recommend making setInstant() be more explicit about the range of Instant values that are allowed, namely those created from Instant.ofEpochMilli(long), which allows +/- 292 million years from the epoch. Otherwise the reader is forced to try to understand when Instant.toEpochMilli() throws the exception. Now that we've constrained the range of instants that a LogRecord can contain, is it still necessary for setMillis(long) to be deprecated? Every value is valid. It can set (almost) the full range of Instant values, just not with nanosecond resolution. If you don't care about nanosecond resolution, this seems like a perfectly fine method to use. s'marks On 12/1/15 10:48 AM, Daniel Fuchs wrote: > Hi Jason, Stuart, > > Here is a potential fix for the issue: > > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html > > > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html > > > > As Stuart noted, java.time.Instant has a greater range than what can > be constructed from a long milliseconds-since-epoch + a nano-time > adjustment. This does not apply to instants returned by the system > clock, since those are constructed precisely from such long > milliseconds-since-epoch + nano-time adjustment. > > However - someone could conceivably construct such an Instant > and pass it to a LogRecord. If that happens, then LogRecord.getMillis() > could potentially throw an undocumented ArithmeticException. > > So we have at least 3 possibilities: > > 1. do nothing > 2. document that getMillis() can throw ArithmeticException, with the > additional consequence that serializing a LogRecord thus constructed > would also throw an ArithmeticException. > 3. modify setInstant() to validate that the instant will fit in a > long milliseconds-since-epoch. > > > The above patch implements option 3 (which currently has my > preference). Is that the best solution? > > I would very much like to hear your opinion. > If it seems like the best then I'll add a unit test, send an RFR, and > do the paper work for the spec change... > > best regards, and thanks for all the valuable feedback! > > -- daniel > > > > On 30/11/15 18:04, Jason Mehrens wrote: >> Hi Daniel, >> >> >> When JDK-8072645 - java.util.logging should use java.time to get more precise >> time stamps was commited the LogRecord.getMillis() method was marked as >> deprecated with the reason "To get the full nanosecond resolution event time, >> use getInstant". I can see marking LogRecord.setMillis as deprecated since >> using that would be an untended loss of precision. However, it seems >> excessive to deprecate LogRecord.getMillis when it could be treated as a >> convenience method that could simply note that if the caller wants nanosecond >> resolution use getInstant. It would be extremely helpful compatibility wise >> to have this undeprecated for libs that have support pre-Java 9. If it can't >> be undeprecated what is the proper way to target support as low as JDK7 but >> might end up executing on JDK9? >> >> >> Thanks, >> >> >> Jason >> > From vladimir.kozlov at oracle.com Wed Dec 2 16:02:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Dec 2015 08:02:14 -0800 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <938E28F6-2FB9-46E5-B13F-D4535112F81E@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> <565E4F7A.2050607@oracle.com> <938E28F6-2FB9-46E5-B13F-D4535112F81E@oracle.com> Message-ID: <565F1606.70606@oracle.com> Thank you, Paul. This looks good. Vladimir On 12/2/15 1:10 AM, Paul Sandoz wrote: > >> On 2 Dec 2015, at 02:55, Vladimir Kozlov wrote: >> >> I reviewed 8143355 today and my main question is where are range checks? >> > > In this case the range checks are performed by the methods in Arrays, which call non-checking type-specific methods in ArraysSupport that in turn call vectorizedMismatch e.g: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/Arrays.java.sdiff.html > > 2861 @HotSpotIntrinsicCandidate > 2862 public static boolean equals(byte[] a, byte[] a2) { > 2863 if (a==a2) > 2864 return true; > 2865 if (a==null || a2==null) > 2866 return false; > 2867 > 2868 int length = a.length; > 2869 if (a2.length != length) > 2870 return false; > 2871 > 2872 return ArraysSupport.mismatch(a, a2, length) < 0; > 2873 } > > > 2907 public static boolean equals(byte[] a, int aFromIndex, int aToIndex, > 2908 byte[] b, int bFromIndex, int bToIndex) { > 2909 rangeCheck(a.length, aFromIndex, aToIndex); > 2910 rangeCheck(b.length, bFromIndex, bToIndex); > 2911 > 2912 int aLength = aToIndex - aFromIndex; > 2913 int bLength = bToIndex - bFromIndex; > 2914 if (aLength != bLength) > 2915 return false; > 2916 > 2917 return ArraysSupport.mismatch(a, aFromIndex, > 2918 b, bFromIndex, > 2919 aLength) < 0; > 2920 } > > > 5875 public static int compare(byte[] a, byte[] b) { > 5876 if (a == b) > 5877 return 0; > 5878 if (a == null || b == null) > 5879 return a == null ? -1 : 1; > 5880 > 5881 int i = ArraysSupport.mismatch(a, b, > 5882 Math.min(a.length, b.length)); > 5883 if (i >= 0) { > 5884 return Byte.compare(a[i], b[i]); > 5885 } > 5886 > 5887 return a.length - b.length; > 5888 } > > > 5950 public static int compare(byte[] a, int aFromIndex, int aToIndex, > 5951 byte[] b, int bFromIndex, int bToIndex) { > 5952 rangeCheck(a.length, aFromIndex, aToIndex); > 5953 rangeCheck(b.length, bFromIndex, bToIndex); > 5954 > 5955 int aLength = aToIndex - aFromIndex; > 5956 int bLength = bToIndex - bFromIndex; > 5957 int i = ArraysSupport.mismatch(a, aFromIndex, > 5958 b, bFromIndex, > 5959 Math.min(aLength, bLength)); > 5960 if (i >= 0) { > 5961 return Byte.compare(a[aFromIndex + i], b[bFromIndex + i]); > 5962 } > 5963 > 5964 return aLength - bLength; > 5965 } > > > There are existing tests in place verifying that exceptions are thrown for out of bounds conditions. > > Paul. > From brian.burkhalter at oracle.com Wed Dec 2 16:12:54 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Dec 2015 08:12:54 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <565E648C.9040304@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> Message-ID: <34E8FC1C-606C-4776-97B6-F68D2FB36A2E@oracle.com> Hi Joe, On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy wrote: > Current version looks okay. One more request, before pushing please add explicit test cases for the for the largest number having 63 bits and the smallest number having 64 bits. No need for another round of webrevs for that. OK, will do. Thanks, Brian From peter.levart at gmail.com Wed Dec 2 16:16:41 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 2 Dec 2015 17:16:41 +0100 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <3F081061-A73D-43D3-B8BC-EB7DD4891D4F@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> <3F081061-A73D-43D3-B8BC-EB7DD4891D4F@oracle.com> Message-ID: <565F1969.5060004@gmail.com> Hi Paul, Just a nit more: 120 int valuesPerWidth = LOG2_ARRAY_LONG_INDEX_SCALE - log2ArrayIndexScale; Would it be more correct to call that variable log2ValuesPerWidth? Regards, Peter On 11/30/2015 04:21 PM, Paul Sandoz wrote: >> On 25 Nov 2015, at 10:53, Paul Sandoz wrote: >> >> Hi, >> >> And this is the review for the Java part: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ >> >> Which will be updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is pushed. [1] >> >> The plan is all reviewed changes will be pushed to hs-comp and then we follow up: >> >> 1) adding the intrinsic to other platforms >> >> 2) improving C1 (perhaps even the interpreter?) since the intrinsic is a stub which IIUC makes it easier to plug in. >> >> 3) take a swing at consolidating other equal/compare intrinsics, such as those for char[]/String-based equal/compare >> >> 4) adding methods to String such as mismatch method. >> >> I can help by pushing all reviewed patches. I will kick off a JPRT run with all patches applied. >> > JPRT runs for both core and hotspot tests report no issues. > > Paul. > >> I did evaluate/test the HotSpot patch (stared at the patch and generated code for UseAVX < 2, and measured) and reviewed with my limited knowledge of HotSpot. >> >> Paul. >> From stefan.sarne at oracle.com Wed Dec 2 16:20:42 2015 From: stefan.sarne at oracle.com (=?UTF-8?Q?Stefan_S=c3=a4rne?=) Date: Wed, 2 Dec 2015 17:20:42 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> Message-ID: <565F1A5A.4040509@oracle.com> Hi Paul, The reason we stick on standard jtreg tests is because it is simpler. For us, a java test is not a unit test, it is an application. :) I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. Cheers, Stefan Den 2015-12-02 kl. 09:52, skrev Paul Sandoz: > Hi Christian, > >> On 1 Dec 2015, at 20:19, Christian Tornqvist >> > > wrote: >> >> Hi Paul, >> >> Tests in hotspot/test/runtime needs to be jtreg tests. > > They are jtreg tests. They are require to be run (re: ?launched") with > jtreg see: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/JdkInternalMiscUnsafeAccessTestBoolean.java.html > > 24 /* > 25 * @test > 26 * @bug 8143628 > 27 * @summary Test unsafe access for boolean > 28 * @modules java.base/jdk.internal.misc > 29 * @run testng/othervm -Diters=100 -Xint JdkInternalMiscUnsafeAccessTestBoolean > 30 * @run testng/othervm -Diters=20000 -XX:TieredStopAtLevel=1 JdkInternalMiscUnsafeAccessTestBoolean > 31 * @run testng/othervm -Diters=20000 -XX:-TieredCompilation JdkInternalMiscUnsafeAccessTestBoolean > 32 * @run testng/othervm -Diters=20000 JdkInternalMiscUnsafeAccessTestBoolean > 33 */ > > That?s the point i was making with: > > jtreg is to testng as launcher is to library > > Note the use of the "@modules java.base/jdk.internal.misc?. That?s > gonna be important later on. > > >> Looking at your tests, I can't see a reason why they can't easily be >> modified to be jtreg tests instead? > > That?s not the point. There is a principle here about what test > libraries one can or cannot use with the test in a particular area of > a particular repo. At the moment i am not hearing any consistent and > solid technical argument as to why testng cannot be used for HotSpot > runtime tests. > > Paul. From paul.sandoz at oracle.com Wed Dec 2 16:59:04 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 17:59:04 +0100 Subject: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <565F1969.5060004@gmail.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568F16C1@ORSMSX106.amr.corp.intel.com> <7F18EFC4-0E53-4FD2-BF56-2219CFEC597E@oracle.com> <3F081061-A73D-43D3-B8BC-EB7DD4891D4F@oracle.com> <565F1969.5060004@gmail.com> Message-ID: > On 2 Dec 2015, at 17:16, Peter Levart wrote: > > Hi Paul, > > Just a nit more: > > 120 int valuesPerWidth = LOG2_ARRAY_LONG_INDEX_SCALE - log2ArrayIndexScale; > > Would it be more correct to call that variable log2ValuesPerWidth? > Yes, good point. Updated. I also used the constant LOG2_ARRAY_INT_INDEX_SCALE instead of 2, here: 138 if (log2ArrayIndexScale < LOG2_ARRAY_INT_INDEX_SCALE) { Thanks, Paul. > Regards, Peter > From Alan.Bateman at oracle.com Wed Dec 2 17:04:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Dec 2015 17:04:58 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F0D8F.2070103@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com> <565F0D8F.2070103@oracle.com> Message-ID: <565F24BA.3000905@oracle.com> On 02/12/2015 15:26, Chris Hegarty wrote: > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. > This version looks okay to me too. -Alan. From daniel.daugherty at oracle.com Wed Dec 2 18:22:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 2 Dec 2015 11:22:18 -0700 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565DC91B.9060206@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> <565DC91B.9060206@oracle.com> Message-ID: <565F36DA.4060004@oracle.com> On 12/1/15 9:21 AM, Frederic Parain wrote: > Hi Dan, > > Thank you for your detailed review. > My answers are in-lined below. > > New webrev: > > http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... Just a couple of nits: src/os/windows/vm/os_windows.cpp L2365: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; should be 6 spaces instead of 8; actually I think this one is a tab. src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp L381: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/linux_x86/vm/os_linux_x86.cpp L194: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp L267: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp L255: assert(fr->safe_for_sender(thread), "Safety check"); Wrong indent; this one also might be a tab Thumbs up! I do not need to see a webrev for the above nits. Dan > > > On 24/11/2015 17:26, Daniel D. Daugherty wrote: >> >> src/cpu/sparc/vm/frame_sparc.cpp >> (old) L635: if (fp() - sp() > 1024 + >> m->max_stack()*Interpreter::stackElementSize) { >> (new) L635: if (fp() - unextended_sp() > 1024 + >> m->max_stack()*Interpreter::stackElementSize) { >> This looks like a bug fix independent of this fix. > > Correct, this is the SPARC version of JDK-8068655. > >> src/share/vm/runtime/thread.hpp >> L953: intptr_t* _reserved_stack_activation; >> L1382: intptr_t* reserved_stack_activation() const { return >> _reserved_stack_activation; } >> L1383: void set_reserved_stack_activation(intptr_t* addr) { >> >> I was expecting this type to be 'address' instead of >> 'intptr_t*'. >> >> Update: I've gone back through the changes and I still don't >> see a reason that this is 'intptr_t*'. > > The _reserved_stack_activation has been declared as an 'intptr_t*' > just to be consistent with the _sp and _fp fields of the frame class. > However, this is not really a requirement, the content stored at the > _reserved_stack_activation address is never read. This address is just > a "marker" on the stack to quickly check if the thread has exited the > annotated code section or not. I've change the type to address, there's > slightly less casts, and it doesn't impact the ReservedStackArea logic. > > Note: I've removed all further comments about _reserved_stack_activation > type in order to improve the e-mail readability. > >> L1341: { return stack_yellow_zone_base();} >> '{' should be at the end of the previous line. >> Missing space after ';'. > > Fixed > >> L1343: { return StackReservedPages * os::vm_page_size(); } >> '{' should be at the end of the previous line. > > Fixed > >> src/share/vm/runtime/thread.cpp >> L2543: // The base notation is from the stacks point of view, >> growing downward. >> L2565: // The base notation is from the stacks point of view, >> growing downward. >> Typo: "stacks point of view" -> "stack's point of view" > > Fixed > >> L2552: } else { >> L2553: warning("Attempt to guard stack reserved zone failed."); >> L2554: } >> L2555: enable_register_stack_guard(); >> >> Should enable_register_stack_guard() be called when we issued >> the warning on L2553? >> >> L2571: } else { >> L2572: warning("Attempt to unguard stack reserved zone >> failed."); >> L2573: } >> L2574: disable_register_stack_guard(); >> >> Should disable_register_stack_guard() be called when we issued >> the warning on L2572? > > enable_register_stack_guard() and disable_register_stack_guard() are > relics of the Itanium code (Itanium had a very different stack > management). These methods are currently empty on all OpenJDK and > Oracle platforms. May be another clean up opportunity here. > Regarding the placement of the calls, I followed the same pattern > as the other red/yellow pages management functions. > >> src/share/vm/runtime/sharedRuntime.cpp >> >> L784: java_lang_Throwable::set_message(exception_oop, >> L785: Universe::delayed_stack_overflow_error_message()); >> Wrong indent; this should line up under the 'e' after the '('. > > Fixed > >> L2976: if (fr.is_interpreted_frame()) { >> L2978: prv_fr = fr; >> L2982: prv_fr = fr; >> This line is in both branches of the if-statement on L2976. >> Is there a reason not to save prv_fr before L2976? > > No particular reason, fixed. > >> L2996 continue; >> Wrong indent; needs one more space. > > Fixed > >> L2958: frame activation; >> L3013: return activation; >> The return on L3013 can return a default constructed 'frame'. >> Is that default safe to return here? > > Yes, the caller performs a check before using the returned > frame: > if (activation.sp() != NULL) { ... > >> >> src/os/bsd/vm/os_bsd.hpp >> L109: static bool get_frame_at_stack_banging_point(JavaThread* >> thread, ucontext_t* uc, frame* fr); >> Wrong indent; needs one less space. > > Fixed > >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> L322: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L323: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L379: assert(fr->safe_for_sender(thread), "Safety check"); >> L380: if (!fr->is_first_java_frame()) { >> L381: *fr = fr->java_sender(); >> The assert() on L379 should be before the java_sender() >> call on L381. > > Fixed > >> src/os/linux/vm/os_linux.cpp >> L1902: jt->stack_guards_enabled()) { // No pending >> stack overflow exceptions >> This line's comment used to align with the previous line's >> comment. >> Can you move the previous line's comment to align with this >> one? > > Done. > >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> L135: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L136: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L192: assert(fr->safe_for_sender(thread), "Safety check"); >> L193: if (!fr->is_first_java_frame()) { >> L194: *fr = fr->java_sender(); >> The assert() on L192 should be before the java_sender() >> call on L194. > > Fixed > >> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >> L209: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L210: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L265: assert(fr->safe_for_sender(thread), "Safety check"); >> L266: if (!fr->is_first_java_frame()) { >> L267: *fr = fr->java_sender(); >> The assert() on L265 should be before the java_sender() >> call on L267. > > Fixed > >> L279: //assert(fr->safe_for_sender(thread), "Safety check"); >> Delete this line; you copied it to L282. > > Done > >> L287 return true; >> Should this assert be added above this line? >> assert(fr->is_java_frame(), "Safety check"); > > Yes, this assert exists on other platforms, and there's no > reason to omit it on Solaris/SPARC > >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> L195: // For Forte Analyzer AsyncGetCallTrace profiling support - >> thread >> L196: // is currently interrupted by SIGPROF. >> Now fetch_frame_from_ucontext() is also used for stack overflow >> signal handling. > > Fixed > >> L253: assert(fr->safe_for_sender(thread), "Safety check"); >> L254: if (!fr->is_first_java_frame()) { >> L255: *fr = fr->java_sender(); >> The assert() on L253 should be before the java_sender() >> call on L255. > > Fixed > >> L273: *fr = fr->java_sender(); >> Wrong indent; one too many spaces. > > Fixed > > >> src/os/windows/vm/os_windows.cpp >> L2364: assert(fr->safe_for_sender(thread), "Safety check"); >> L2365: if (!fr->is_first_java_frame()) { >> L2366: *fr = fr->java_sender(); >> The assert() on L2364 should be before the java_sender() >> call on L2366. > > Fixed > >> L2387: return true; >> Should this assert be added above this line? >> assert(fr->is_java_frame(), "Safety check"); > > Certainly, fixed. > >> src/share/vm/oops/method.hpp >> (old) L87: u1 _flags; >> (new) L88: u2 _flags; >> Ouch - just needed one more bit... > > The initial implementation of the reserved stack area used the last > bit, but unfortunately, someone else steal it before I could push > my code :-( So I had to extend the flags field > >> L834: return (_flags & _reserved_stack_access) != 0; >> Wrong indent; two fewer spaces. > > Fixed > >> src/share/vm/runtime/globals.hpp >> L3549: range(MIN_STACK_RESERVED_PAGES, >> (DEFAULT_STACK_RESERVED_PAGES+10))\ >> Wrong indent; should line up below the double quote in >> the previous line. > > Fixed > >> src/share/vm/interpreter/interpreterRuntime.cpp >> L328 IRT_ENTRY(void, >> InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* >> thread)) >> >> The regular throw_StackOverflowError() increments >> a counter: >> >> L313: Atomic::inc(&Exceptions::_stack_overflow_errors); >> >> Should this function increment the same counter or >> a different counter? > > Good catch! I've added the counter increment to the method > throw_delayed_StackOverflowError(). I don't see a strong > rational to create a new counter for delayed stack overflows, > so it increments the same counter as throw_StackOverflowError(). > >> >> src/cpu/sparc/vm/macroAssembler_sparc.hpp >> L1423: // Check for reserved stack access in method being exited >> (for the compilers) >> The X86 version says "for JIT compilers". I prefer "JIT". > > Fixed > >> src/cpu/x86/vm/macroAssembler_x86.hpp >> L643: // Check for reserved stack access in method being exited >> (for JIT compilers) >> The SPARC version says "for the compilers". > > Fixed > >> src/share/vm/ci/ciMethod.cpp >> L95: _has_reserved_stack_access = >> h_m()->has_reserved_stack_access(); >> Wrong indent; should be only one space before '='. > > Fixed > >> src/share/vm/c1/c1_GraphBuilder.cpp >> L3323: if(callee->has_reserved_stack_access()) { >> L3336: if(callee->has_reserved_stack_access()) { >> L3356: if(callee->has_reserved_stack_access()) { >> Missing space between 'if' and '('. > > All fixed. > >> src/cpu/x86/vm/x86_32.ad >> L737: size += 64; // added to support ReservedStackAccess >> Usually I hate literals like this, but this function has >> them in spades. :-( > > I agree but I didn't find a better solution. > >> src/cpu/x86/vm/x86_64.ad >> L960: MacroAssembler _masm(&cbuf); >> L965: MacroAssembler _masm(&cbuf); >> >> I think you can delete the _masm on L965. > > Right, removed. > >> src/share/vm/opto/compile.cpp >> L675: >> _has_reserved_stack_access(target->has_reserved_stack_access()) { >> Wrong indent; should be a single space between ')' and '{'. > > Fixed > >> test/runtime/ReservedStack/ReservedStackTest.java >> L26: * @run main/othervm -XX:-Inline >> -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread >> >> ReservedStackTest >> >> Should the comma before 'setExclusiveOwnerThread' be a period? >> Perhaps both formats work... > > Both formats work, but I changed it to be a period, it's cleaner. > >> L47: * else >> Wrong indent; needs one more space before 'else'. >> >> L52: * successfully update the status of the lock but he method >> Typo: 'update the' -> 'updates the' >> Typo: 'he method' -> 'the method' >> >> L60: * first StackOverflowError is thrown, the Error is catched >> Typo: 'is catched' -> 'is caught' >> >> L61: * and a few dozens frames are exited. Now the thread has >> Typo: 'a few dozens frames' -> 'a few dozen frames' >> >> L66: * of its invocation, tries to acquire the next lock >> Typo: 'its invocation' -> 'its invocations' >> >> L81: * stack to prevent false sharing. The test is using this >> Perhaps 'The test is using this' >> -> 'The test relies on this' >> >> to better match wording on L225-6. >> >> L82: * to have different stack alignments and hit the targeted >> Grammar: 'and hit' -> 'when it hits' >> >> L102: * exploit the property that interpreter frames are (much) >> Typo: 'exploit' -> 'exploits' >> Delete extra space after 'the'. >> >> L123: //LOCK_ARRAY_SIZE value >> Add a space after '//'. >> >> L188: @jdk.internal.vm.annotation.ReservedStackAccess >> This isn't privileged code and -XX:-RestrictReservedStack >> isn't specified so what does this do? > > It checks that by default the annotation is ignored for non-privileged > code, in case it is not ignored, the test would fail. > >> >> L201: System.exit(-1); >> Wrong indent; needs two more spaces. > > All fixed. > > Thank you very much! > > Fred > >>> >>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>> Frederic, >>>> >>>> Code review for web revs you sent out. >>>> Code looks good. I am not as familiar with the compiler code. >>>> >>>> I realize you need to check in at least a subset of the >>>> java.util.concurrent changes for >>>> the test to work, so maybe I should not have asked Doug about his >>>> preference there. >>>> Sorry. >>>> >>>> I am impressed you found a way to make a reproducible test! >>>> >>>> Comments/questions: >>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>> >>> Fixed >>> >>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>> this >>>> is disabled for Windows. Would it be worth putting a comment in the >>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>> windows >>>> will need testing before enabling? >>> >>> More than testing, the implementation would have to be completed on >>> Windows. I've added a comment to JDK-8067946. >>> >>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >>>> solaris_x86 if >>>> this is in interpreter code, you explicitly return the Java sender >>>> of the current frame. I was expecting to see that on Solaris_sparc >>>> and Windows >>>> as well? I do see the assertion in caller that you do have a java >>>> frame. >>> >>> It doesn't make sense to check the current frame (no bytecode has been >>> executed yet, so risk of partially executed critical section). I did >>> the >>> change but not for all platforms. This is now fixed for Solaris_SPARC >>> and Windows too. >>> >>>> 4. test line 83 ?writtent? -> ?written? >>> >>> Fixed >>> >>>> 5. I like the way you set up the preallocated exception and then set >>>> the message - we may >>>> try that for default methods in future. >>>> >>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>> you already check that in? >>> >>> I've fixed x86 platforms in JDK-8068655. >>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>> I had hoped it would have been silently accepted :-) >>> >>> >>>> 7. I see the change in trace.xml, and I see an include added to >>>> SharedRuntime.cpp, >>>> but I didn?t see where it was used - did I just miss it? >>> >>> trace.xml changes define a new event. >>> This event is created at sharedRuntime.cpp::3006 and it is used >>> in the next 3 lines. >>> >>> Thanks, >>> >>> Fred >>> >> > From kim.barrett at oracle.com Wed Dec 2 18:37:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 13:37:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do Message-ID: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the work involved in keeping the otherwise inaccessible referent objects alive, as required by the existing specification. This not only immediately removes some work, but may enable further performance improvements. It also allows the referent objects to be immediately reclaimed in the GC cycle in which they were determined to be inaccessible, rather than lingering as a form of floating garbage until the application deals with the notified reference. This change results in a behavioral change to application code, as demonstrated by the associated test. Under the old specification, a reference R with referent X may be kept alive because it is referenced by an otherwise inaccessible referent Y of phantom reference P. This will result in X being treated as strongly referenced and prevent R from being notified, even if R is a phantom reference and X has become inaccessible to the application. With this change, Y is reclaimed when it becomes inaccessible and P is notified, and no longer prevents X from itself becoming a candidate for reclaimation once it is no longer accessible to the application. While this is a change in behavior, it seems unlikely to affect applications negatively. CR: https://bugs.openjdk.java.net/browse/JDK-8071507 Webrevs: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ Testing: jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) From martinrb at google.com Wed Dec 2 18:39:58 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Dec 2015 10:39:58 -0800 Subject: RFE Pre-review: Support for cloning exceptions In-Reply-To: <565EBAA6.7080402@gmail.com> References: <565D830A.10508@gmail.com> <565EBAA6.7080402@gmail.com> Message-ID: On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart wrote: > > In short, I think exceptions are a special hierarchy with special use > pattern in which clone() would not present a practical problem that > generally arises in other objects that are meant to change state > independently from their creation. > Java is supposed to be a high reliability platform and introducing new exotic failure modes isn't something we should be doing. My work at Google prejudices me - it seems half the work we do is trying to track down rare bugs we can't reproduce, or happen once every cpu-year. If you add "implements Cloneable" then people will call protected nullary clone(). You haven't made it public, but it can (and will!) be called from subclasses and their packages. I see you were careful to copy the suppressedExceptions field in your static clone, but callers of the "real" clone will produce two Throwables that share a single ArrayList, which is not thread safe. I'm sure there's code out there that reasonably assumes that if something is Cloneable, then it has a public clone() method, and will try to invoke that via reflection. I see that if an existing subclass of Throwable implemented Cloneable, there would be no way (short of Unsafe) for its clone method to do a proper copy of suppressedExceptions. In the future, if Throwable were to implement Cloneable, then more subclasses are likely to add a public clone() method (to "support" cloning) and that will only do a proper copy of suppressedExceptions if you do the copying in nullary Throwable.clone() instead of in static clone. Sadly, making Throwable Cloneable is exceedingly subtle and I think we will regret it (as we do the design of Cloneable itself). From mandy.chung at oracle.com Wed Dec 2 18:58:46 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Dec 2015 10:58:46 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <97DB8CEB-69E0-4A97-BF03-10E984AD6F13@oracle.com> Kim, Thanks for sending this out. I like the 1-line fix in hotspot - simple and sweet. Mandy > On Dec 2, 2015, at 10:37 AM, Kim Barrett wrote: > > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From daniel.fuchs at oracle.com Wed Dec 2 19:25:05 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Dec 2015 20:25:05 +0100 Subject: Deprecation of LogRecord.getMillis in JDK9 In-Reply-To: <565E459C.9070702@oracle.com> References: <565DEB92.6040502@oracle.com> <565E459C.9070702@oracle.com> Message-ID: <565F4591.8040207@oracle.com> On 02/12/15 02:13, Stuart Marks wrote: > I'd recommend making setInstant() be more explicit about the range of > Instant values that are allowed, namely those created from > Instant.ofEpochMilli(long), which allows ? 292 million years from the > epoch. Otherwise the reader is forced to try to understand when > Instant.toEpochMilli() throws the exception. Hi Stuart, That would not be completely exact - since it excludes all the Instant values that have a nano second adjustment - and could give the impression that only instants truncated at milliseconds resolution are valid. So I think I prefer to refer to Instant.toEpochMilli() - though I may try to word the @throws differently: * Sets the instant that the event occurred. *

* If the given {@code instant} represents a point on the time-line too * far in the future or past to fit in a {@code long} milliseconds and * nanoseconds adjustment, then an {@code ArithmeticException} will be * thrown. * * @param instant the instant that the event occurred. * * @throws NullPointerException if {@code instant} is null. * @throws ArithmeticException if numeric overflow would occur while * calling {@link Instant#toEpochMilli() instant.toEpochMilli()}. I will send a RFR on core-libs-dev shortly - so if you have other suggestion/feedback maybe you could reply on the RFR :-) best regards, -- daniel From daniel.fuchs at oracle.com Wed Dec 2 20:10:32 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Dec 2015 21:10:32 +0100 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated Message-ID: <565F5038.4010205@oracle.com> Hi, Please find below a fix for 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated https://bugs.openjdk.java.net/browse/JDK-8144262 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 specdiff: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html When 8072645:java.util.logging should use java.time to get more precise time stamps was implemented we decided to deprecate LogRecord.getMillis() and LogRecord.setMillis() in favor of the new LogRecord.getInstant() and LogRecord.setInstant(). This may have been a bit hasty as LogRecord.getMillis() can in fact be seen as a convenience method - a shortcut to LogRecord.getInstant().toEpochMillis(). The only method we really wanted to deprecate was LogRecord.setMillis() as that would truncate the instant to milliseconds: in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer idempotent. This changes proposes to restore LogRecord.getMillis() to its previous status, and also fixes LogRecord.setInstant to reject instant values which would not fit in a long milliseconds-since-epoch - which would have caused serialization to fail and LogRecord.getMillis() to throw an undocumented ArithmeticException. Rationale about this proposed change have also been discussed in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html best regards, -- daniel From Roger.Riggs at Oracle.com Wed Dec 2 20:23:49 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 2 Dec 2015 15:23:49 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151123143205.51363@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> Message-ID: <565F5355.6040209@Oracle.com> Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public interface to support only phantom cleanup. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Javadoc: http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger On 11/23/2015 5:32 PM, mark.reinhold at oracle.com wrote: > ( Finally getting back to this, after too many weeks of travel ... ) > > 2015/10/20 11:28 -0700, roger.riggs at oracle.com: >> Sorry for the silence, JavaOne preparations and the availability of >> folks who wanted to review have stretched things out. >> >> The Cleaner API was very simple and saw feature creep as the ideas for >> how it might be used were explored. There are concerns about >> committing to supporting subclassable CleanableReferences in all >> future JDK versions before there had been a chance to see how if they >> would be useful and necessary to address the need to reduce the use of >> finalization within the OpenJDK and beyond. >> >> ... >> >> Updated Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> >> Updated Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > I'm very happy to see this API return to something like its original > simple form, but I think it can be simplified even further. > > We have a very strong need for phantom-ref-based cleaners, so as to > discourage people from relying upon flaky finalization. The arguments in > support of the weak and soft forms have, by contrast, been rather weak > (and soft?). I don't think it's right to bake methods into a core API > based on just a couple of hypothetical use cases. I'd much rather see > the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single > register method, > > Cleaner.Cleanable register(Object, Runnable); > > which would create the phantom form only. If strong justification for > the other forms arise then we can generalize this later, either to > distinct register{Soft,Weak} methods or, perhaps, to a method that takes > a type token. > > - Mark From Roger.Riggs at oracle.com Wed Dec 2 20:28:32 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 2 Dec 2015 15:28:32 -0500 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F5038.4010205@oracle.com> References: <565F5038.4010205@oracle.com> Message-ID: <565F546F.2060906@oracle.com> Looks good, Roger On 12/02/2015 03:10 PM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for > 8144262: LogRecord.getMillis() method is a convenience API that > should not have been deprecated > https://bugs.openjdk.java.net/browse/JDK-8144262 > > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 > > specdiff: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html > > > > When 8072645:java.util.logging should use java.time to get more > precise time stamps > was implemented we decided to deprecate LogRecord.getMillis() > and LogRecord.setMillis() in favor of the new LogRecord.getInstant() > and LogRecord.setInstant(). > > This may have been a bit hasty as LogRecord.getMillis() can in fact > be seen as a convenience method - a shortcut to > LogRecord.getInstant().toEpochMillis(). > The only method we really wanted to deprecate was LogRecord.setMillis() > as that would truncate the instant to milliseconds: > in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer > idempotent. > > This changes proposes to restore LogRecord.getMillis() to its previous > status, and also fixes LogRecord.setInstant to reject instant values > which would not fit in a long milliseconds-since-epoch - which would > have caused serialization to fail and LogRecord.getMillis() to throw > an undocumented ArithmeticException. > > Rationale about this proposed change have also been discussed in this > thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html > > > best regards, > > -- daniel > From lance.andersen at oracle.com Wed Dec 2 20:33:49 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Dec 2015 15:33:49 -0500 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F5038.4010205@oracle.com> References: <565F5038.4010205@oracle.com> Message-ID: <70049442-2C71-4A9D-9CCC-53149525F32F@oracle.com> +1 On Dec 2, 2015, at 3:10 PM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for > 8144262: LogRecord.getMillis() method is a convenience API that > should not have been deprecated > https://bugs.openjdk.java.net/browse/JDK-8144262 > > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 > > specdiff: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html > > > When 8072645:java.util.logging should use java.time to get more > precise time stamps > was implemented we decided to deprecate LogRecord.getMillis() > and LogRecord.setMillis() in favor of the new LogRecord.getInstant() > and LogRecord.setInstant(). > > This may have been a bit hasty as LogRecord.getMillis() can in fact > be seen as a convenience method - a shortcut to > LogRecord.getInstant().toEpochMillis(). > The only method we really wanted to deprecate was LogRecord.setMillis() > as that would truncate the instant to milliseconds: > in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer > idempotent. > > This changes proposes to restore LogRecord.getMillis() to its previous > status, and also fixes LogRecord.setInstant to reject instant values > which would not fit in a long milliseconds-since-epoch - which would > have caused serialization to fail and LogRecord.getMillis() to throw > an undocumented ArithmeticException. > > Rationale about this proposed change have also been discussed in this > thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html > > best regards, > > -- daniel > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Wed Dec 2 20:36:49 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 2 Dec 2015 12:36:49 -0800 Subject: RFE Pre-review: Support for cloning exceptions In-Reply-To: References: <565D830A.10508@gmail.com> <565EBAA6.7080402@gmail.com> Message-ID: <565F5661.70606@oracle.com> Hello, On 12/2/2015 10:39 AM, Martin Buchholz wrote: > On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart wrote: > >> In short, I think exceptions are a special hierarchy with special use >> pattern in which clone() would not present a practical problem that >> generally arises in other objects that are meant to change state >> independently from their creation. >> > Java is supposed to be a high reliability platform and introducing new > exotic failure modes isn't something we should be doing. My work at Google > prejudices me - it seems half the work we do is trying to track down rare > bugs we can't reproduce, or happen once every cpu-year. > > If you add "implements Cloneable" then people will call protected nullary > clone(). You haven't made it public, but it can (and will!) be called from > subclasses and their packages. I see you were careful to copy the > suppressedExceptions field in your static clone, but callers of the "real" > clone will produce two Throwables that share a single ArrayList, which is > not thread safe. > > I'm sure there's code out there that reasonably assumes that if something > is Cloneable, then it has a public clone() method, and will try to invoke > that via reflection. > > I see that if an existing subclass of Throwable implemented Cloneable, > there would be no way (short of Unsafe) for its clone method to do a proper > copy of suppressedExceptions. In the future, if Throwable were to > implement Cloneable, then more subclasses are likely to add a public > clone() method (to "support" cloning) and that will only do a proper copy > of suppressedExceptions if you do the copying in nullary Throwable.clone() > instead of in static clone. > > Sadly, making Throwable Cloneable is exceedingly subtle and I think we will > regret it (as we do the design of Cloneable itself). An anecdote about previous changes to Throwable to help justify a cautious approach, over many years working on the JDK I've fixed over 900 bugs, some big, many small. Usually if one of my changes isn't acceptable to push initially, it is ready to go after one or two iterations. As part of Project Coin in JDK 7, I added suppressed exception support to Throwable as part of the try-with-resources feature. How difficult could it be? After the first version of the support was pushed, it became clear that it was necessary for the suppressed exceptions to be immutable in some circumstances, JDK-6991528, Support making Throwable.suppressedExceptions immutable. I eventually pushed iteration number 12 of the changes. I don't recall a bug I worked on where more iterations were needed. I have concerns that despite the care taken in developing this sort of feature, there would be a complicated, subtle bug tail to work out, especially given the larger number of subclasses of Throwable. -Joe From jason_mehrens at hotmail.com Wed Dec 2 21:00:45 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 2 Dec 2015 21:00:45 +0000 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F5038.4010205@oracle.com> References: <565F5038.4010205@oracle.com> Message-ID: +1 ________________________________________ From: Daniel Fuchs Sent: Wednesday, December 2, 2015 2:10 PM To: core-libs-dev Cc: Stuart Marks; Jason Mehrens Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated Hi, Please find below a fix for 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated https://bugs.openjdk.java.net/browse/JDK-8144262 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 specdiff: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html When 8072645:java.util.logging should use java.time to get more precise time stamps was implemented we decided to deprecate LogRecord.getMillis() and LogRecord.setMillis() in favor of the new LogRecord.getInstant() and LogRecord.setInstant(). This may have been a bit hasty as LogRecord.getMillis() can in fact be seen as a convenience method - a shortcut to LogRecord.getInstant().toEpochMillis(). The only method we really wanted to deprecate was LogRecord.setMillis() as that would truncate the instant to milliseconds: in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer idempotent. This changes proposes to restore LogRecord.getMillis() to its previous status, and also fixes LogRecord.setInstant to reject instant values which would not fit in a long milliseconds-since-epoch - which would have caused serialization to fail and LogRecord.getMillis() to throw an undocumented ArithmeticException. Rationale about this proposed change have also been discussed in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html best regards, -- daniel From lance.andersen at oracle.com Wed Dec 2 21:09:04 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 2 Dec 2015 16:09:04 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <565F5355.6040209@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> Message-ID: <4F9324C1-30BD-4609-8042-B73414D95BDF@oracle.com> Hi Roger, Should the javadocs in the Cleaner methods include NPE given they use Objects.requireNonNull? Best Lance On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Thanks, Roger > > > On 11/23/2015 5:32 PM, mark.reinhold at oracle.com wrote: >> ( Finally getting back to this, after too many weeks of travel ... ) >> >> 2015/10/20 11:28 -0700, roger.riggs at oracle.com: >>> Sorry for the silence, JavaOne preparations and the availability of >>> folks who wanted to review have stretched things out. >>> >>> The Cleaner API was very simple and saw feature creep as the ideas for >>> how it might be used were explored. There are concerns about >>> committing to supporting subclassable CleanableReferences in all >>> future JDK versions before there had been a chance to see how if they >>> would be useful and necessary to address the need to reduce the use of >>> finalization within the OpenJDK and beyond. >>> >>> ... >>> >>> Updated Javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>> >>> Updated Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> I'm very happy to see this API return to something like its original >> simple form, but I think it can be simplified even further. >> >> We have a very strong need for phantom-ref-based cleaners, so as to >> discourage people from relying upon flaky finalization. The arguments in >> support of the weak and soft forms have, by contrast, been rather weak >> (and soft?). I don't think it's right to bake methods into a core API >> based on just a couple of hypothetical use cases. I'd much rather see >> the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single >> register method, >> >> Cleaner.Cleanable register(Object, Runnable); >> >> which would create the phantom form only. If strong justification for >> the other forms arise then we can generalize this later, either to >> distinct register{Soft,Weak} methods or, perhaps, to a method that takes >> a type token. >> >> - Mark > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Dec 2 21:24:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Dec 2015 13:24:22 -0800 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: References: Message-ID: <28639752-BD0A-4B91-BE3F-61DEA4B997FA@oracle.com> > On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: > > Hi, > > This is a request for an optimistic review to fork the sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables so that we can evolve the latter e.g. for VarHandles unsafe work > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ Looks good. About the tests, would it be better for these tests be placed in the jdk repo? Nit: extra lines in the testAccess method in several new tests can be removed. 144 static void testAccess(Object base, long offset) { 145 // Plain 146 { 147 UNSAFE.putDouble(base, offset, 1.0d); 148 double x = UNSAFE.getDouble(base, offset); 149 assertEquals(x, 1.0d, "set double value"); 150 } 151 152 // Volatile 153 { 154 UNSAFE.putDoubleVolatile(base, offset, 2.0d); 155 double x = UNSAFE.getDoubleVolatile(base, offset); 156 assertEquals(x, 2.0d, "putVolatile double value"); 157 } 158 159 160 161 162 } From Roger.Riggs at oracle.com Wed Dec 2 21:30:45 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 2 Dec 2015 16:30:45 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <4F9324C1-30BD-4609-8042-B73414D95BDF@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <4F9324C1-30BD-4609-8042-B73414D95BDF@oracle.com> Message-ID: <565F6305.5090104@oracle.com> Hi Lance, Cleaner class level javadoc defines the behavior: "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." Roger On 12/02/2015 04:09 PM, Lance Andersen wrote: > Hi Roger, > > Should the javadocs in the Cleaner methods include NPE given they use > Objects.requireNonNull? > > Best > Lance > On Dec 2, 2015, at 3:23 PM, Roger Riggs > wrote: > >> Please review the java.lang.ref.Cleaner and tests following the >> recommendation to simplify the public >> interface to support only phantom cleanup. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> >> Thanks, Roger >> >> >> On 11/23/2015 5:32 PM, mark.reinhold at oracle.com >> wrote: >>> ( Finally getting back to this, after too many weeks of travel ... ) >>> >>> 2015/10/20 11:28 -0700, roger.riggs at oracle.com >>> : >>>> Sorry for the silence, JavaOne preparations and the availability of >>>> folks who wanted to review have stretched things out. >>>> >>>> The Cleaner API was very simple and saw feature creep as the ideas for >>>> how it might be used were explored. There are concerns about >>>> committing to supporting subclassable CleanableReferences in all >>>> future JDK versions before there had been a chance to see how if they >>>> would be useful and necessary to address the need to reduce the use of >>>> finalization within the OpenJDK and beyond. >>>> >>>> ... >>>> >>>> Updated Javadoc: >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>>> >>>> >>>> Updated Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> >>> I'm very happy to see this API return to something like its original >>> simple form, but I think it can be simplified even further. >>> >>> We have a very strong need for phantom-ref-based cleaners, so as to >>> discourage people from relying upon flaky finalization. The arguments in >>> support of the weak and soft forms have, by contrast, been rather weak >>> (and soft?). I don't think it's right to bake methods into a core API >>> based on just a couple of hypothetical use cases. I'd much rather see >>> the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single >>> register method, >>> >>> Cleaner.Cleanable register(Object, Runnable); >>> >>> which would create the phantom form only. If strong justification for >>> the other forms arise then we can generalize this later, either to >>> distinct register{Soft,Weak} methods or, perhaps, to a method that takes >>> a type token. >>> >>> - Mark >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From kumar.x.srinivasan at oracle.com Wed Dec 2 22:16:12 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 02 Dec 2015 14:16:12 -0800 Subject: RFR: 8144533: VersionCheck.java failing after Verona changes in dev Message-ID: <565F6DAC.5070306@oracle.com> Please review fix: diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -187,7 +187,7 @@ static boolean compareInternalStrings() { int failcount = 0; - String bStr = refVersion.substring(refVersion.lastIndexOf("build") + + String bStr = refVersion.substring(refVersion.indexOf("build") + "build".length() + 1, refVersion.lastIndexOf(")")); Thanks Kumar From joe.darcy at oracle.com Wed Dec 2 22:23:25 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 2 Dec 2015 14:23:25 -0800 Subject: RFR: 8144533: VersionCheck.java failing after Verona changes in dev In-Reply-To: <565F6DAC.5070306@oracle.com> References: <565F6DAC.5070306@oracle.com> Message-ID: <565F6F5D.8040406@oracle.com> Look good Kumar; thanks, -Joe On 12/2/2015 2:16 PM, Kumar Srinivasan wrote: > Please review fix: > diff --git a/test/tools/launcher/VersionCheck.java > b/test/tools/launcher/VersionCheck.java > --- a/test/tools/launcher/VersionCheck.java > +++ b/test/tools/launcher/VersionCheck.java > @@ -187,7 +187,7 @@ > > static boolean compareInternalStrings() { > int failcount = 0; > - String bStr = > refVersion.substring(refVersion.lastIndexOf("build") + > + String bStr = refVersion.substring(refVersion.indexOf("build") + > "build".length() + 1, > refVersion.lastIndexOf(")")); > > > Thanks > Kumar > From iris.clark at oracle.com Wed Dec 2 22:28:35 2015 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 2 Dec 2015 14:28:35 -0800 (PST) Subject: RFR: 8144533: VersionCheck.java failing after Verona changes in dev In-Reply-To: <565F6DAC.5070306@oracle.com> References: <565F6DAC.5070306@oracle.com> Message-ID: <21f84b20-a0a2-4fc8-9e42-01032ce591a8@default> Hi, Kumar. Looks good. iris -----Original Message----- From: Kumar Srinivasan Sent: Wednesday, December 02, 2015 2:16 PM To: Joe Darcy; IRIS,CLARK Cc: core-libs-dev Subject: RFR: 8144533: VersionCheck.java failing after Verona changes in dev Please review fix: diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -187,7 +187,7 @@ static boolean compareInternalStrings() { int failcount = 0; - String bStr = refVersion.substring(refVersion.lastIndexOf("build") + + String bStr = refVersion.substring(refVersion.indexOf("build") + "build".length() + 1, refVersion.lastIndexOf(")")); Thanks Kumar From paul.sandoz at oracle.com Wed Dec 2 22:36:05 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Dec 2015 23:36:05 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <28639752-BD0A-4B91-BE3F-61DEA4B997FA@oracle.com> References: <28639752-BD0A-4B91-BE3F-61DEA4B997FA@oracle.com> Message-ID: <2EDB2846-96A2-4C36-A44F-DC3FAD48BF94@oracle.com> > On 2 Dec 2015, at 22:24, Mandy Chung wrote: > > >> On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: >> >> Hi, >> >> This is a request for an optimistic review to fork the sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables so that we can evolve the latter e.g. for VarHandles unsafe work >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ > > Looks good. About the tests, would it be better for these tests be placed in the jdk repo? > That?s my preferred back up plan :-) Something to ponder while waiting for 8143930 (C1 LinearScan...) to be integrated. > Nit: extra lines in the testAccess method in several new tests can be removed. > > 144 static void testAccess(Object base, long offset) { > 145 // Plain > 146 { > 147 UNSAFE.putDouble(base, offset, 1.0d); > 148 double x = UNSAFE.getDouble(base, offset); > 149 assertEquals(x, 1.0d, "set double value"); > 150 } > 151 > 152 // Volatile > 153 { > 154 UNSAFE.putDoubleVolatile(base, offset, 2.0d); > 155 double x = UNSAFE.getDoubleVolatile(base, offset); > 156 assertEquals(x, 2.0d, "putVolatile double value"); > 157 } > 158 > 159 > 160 > 161 > 162 } I could remove empty lines in the template between #if/#end blocks but i find it harder to read. So i would prefer to leave this as is. Thanks, Paul. From stuart.marks at oracle.com Wed Dec 2 22:49:33 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 2 Dec 2015 14:49:33 -0800 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F5038.4010205@oracle.com> References: <565F5038.4010205@oracle.com> Message-ID: <565F757D.8020106@oracle.com> Hi Daniel, I'm ok with setMillis() remaining deprecated, but there should be an explanation of why it's deprecated. What's there now says To set event time with nanosecond resolution, use {@link #setInstant(java.time.Instant)}. A better explanation might be along the lines of: LogRecord maintains timestamps with nanosecond resolution, using Instant values. For this reason, setInstant() should be used in preference to setMillis(). Wordsmith to taste. The explanation of exceptions in setInstant() is good. In the LogRecordWithNanosAPI.java test, I was confused by the Instant calculations. I think the last Instant value for which toEpochMilli() won't throw is Instant max = Instant.ofEpochMilli(Long.MAX_VALUE).plusNanos(999_999L); and the earliest Instant value for which toEpochMilli() will throw is Instant toobig = max.plusNanos(1L); s'marks On 12/2/15 12:10 PM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for > 8144262: LogRecord.getMillis() method is a convenience API that > should not have been deprecated > https://bugs.openjdk.java.net/browse/JDK-8144262 > > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 > > specdiff: > http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html > > > > When 8072645:java.util.logging should use java.time to get more > precise time stamps > was implemented we decided to deprecate LogRecord.getMillis() > and LogRecord.setMillis() in favor of the new LogRecord.getInstant() > and LogRecord.setInstant(). > > This may have been a bit hasty as LogRecord.getMillis() can in fact > be seen as a convenience method - a shortcut to > LogRecord.getInstant().toEpochMillis(). > The only method we really wanted to deprecate was LogRecord.setMillis() > as that would truncate the instant to milliseconds: > in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer > idempotent. > > This changes proposes to restore LogRecord.getMillis() to its previous > status, and also fixes LogRecord.setInstant to reject instant values > which would not fit in a long milliseconds-since-epoch - which would > have caused serialization to fail and LogRecord.getMillis() to throw > an undocumented ArithmeticException. > > Rationale about this proposed change have also been discussed in this > thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html > > best regards, > > -- daniel > From stuart.marks at oracle.com Wed Dec 2 22:51:29 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 2 Dec 2015 14:51:29 -0800 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F757D.8020106@oracle.com> References: <565F5038.4010205@oracle.com> <565F757D.8020106@oracle.com> Message-ID: <565F75F1.6010404@oracle.com> BTW Daniel, if you're ok with my suggestions, go ahead and push them. I don't need to see another webrev. Thanks, s'marks On 12/2/15 2:49 PM, Stuart Marks wrote: > Hi Daniel, > > I'm ok with setMillis() remaining deprecated, but there should be an explanation > of why it's deprecated. What's there now says > > To set event time with nanosecond resolution, > use {@link #setInstant(java.time.Instant)}. > > A better explanation might be along the lines of: > > LogRecord maintains timestamps with nanosecond resolution, using > Instant values. For this reason, setInstant() should be used in > preference to setMillis(). > > Wordsmith to taste. > > The explanation of exceptions in setInstant() is good. > > In the LogRecordWithNanosAPI.java test, I was confused by the Instant > calculations. I think the last Instant value for which toEpochMilli() won't > throw is > > Instant max = Instant.ofEpochMilli(Long.MAX_VALUE).plusNanos(999_999L); > > and the earliest Instant value for which toEpochMilli() will throw is > > Instant toobig = max.plusNanos(1L); > > s'marks > > > > On 12/2/15 12:10 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for >> 8144262: LogRecord.getMillis() method is a convenience API that >> should not have been deprecated >> https://bugs.openjdk.java.net/browse/JDK-8144262 >> >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 >> >> specdiff: >> http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html >> >> >> >> >> When 8072645:java.util.logging should use java.time to get more >> precise time stamps >> was implemented we decided to deprecate LogRecord.getMillis() >> and LogRecord.setMillis() in favor of the new LogRecord.getInstant() >> and LogRecord.setInstant(). >> >> This may have been a bit hasty as LogRecord.getMillis() can in fact >> be seen as a convenience method - a shortcut to >> LogRecord.getInstant().toEpochMillis(). >> The only method we really wanted to deprecate was LogRecord.setMillis() >> as that would truncate the instant to milliseconds: >> in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer >> idempotent. >> >> This changes proposes to restore LogRecord.getMillis() to its previous >> status, and also fixes LogRecord.setInstant to reject instant values >> which would not fit in a long milliseconds-since-epoch - which would >> have caused serialization to fail and LogRecord.getMillis() to throw >> an undocumented ArithmeticException. >> >> Rationale about this proposed change have also been discussed in this >> thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html >> >> best regards, >> >> -- daniel >> From daniel.fuchs at oracle.com Wed Dec 2 22:54:42 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Dec 2015 23:54:42 +0100 Subject: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated In-Reply-To: <565F757D.8020106@oracle.com> References: <565F5038.4010205@oracle.com> <565F757D.8020106@oracle.com> Message-ID: <565F76B2.7090409@oracle.com> Hi Stuart, On 12/2/15 11:49 PM, Stuart Marks wrote: > Hi Daniel, > > I'm ok with setMillis() remaining deprecated, but there should be an > explanation of why it's deprecated. What's there now says > > To set event time with nanosecond resolution, > use {@link #setInstant(java.time.Instant)}. > > A better explanation might be along the lines of: > > LogRecord maintains timestamps with nanosecond resolution, using > Instant values. For this reason, setInstant() should be used in > preference to setMillis(). > > Wordsmith to taste. Thanks for this suggestion. It does read better indeed. > > The explanation of exceptions in setInstant() is good. > > In the LogRecordWithNanosAPI.java test, I was confused by the Instant > calculations. I think the last Instant value for which toEpochMilli() > won't throw is > > Instant max = > Instant.ofEpochMilli(Long.MAX_VALUE).plusNanos(999_999L); > > and the earliest Instant value for which toEpochMilli() will throw is > > Instant toobig = max.plusNanos(1L); Oh - yes that's a much more readable way to create these instant values :-) I'll take that! Thanks for the feedback. -- daniel > > s'marks > > > > On 12/2/15 12:10 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for >> 8144262: LogRecord.getMillis() method is a convenience API that >> should not have been deprecated >> https://bugs.openjdk.java.net/browse/JDK-8144262 >> >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 >> >> specdiff: >> http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html >> >> >> >> >> When 8072645:java.util.logging should use java.time to get more >> precise time stamps >> was implemented we decided to deprecate LogRecord.getMillis() >> and LogRecord.setMillis() in favor of the new LogRecord.getInstant() >> and LogRecord.setInstant(). >> >> This may have been a bit hasty as LogRecord.getMillis() can in fact >> be seen as a convenience method - a shortcut to >> LogRecord.getInstant().toEpochMillis(). >> The only method we really wanted to deprecate was LogRecord.setMillis() >> as that would truncate the instant to milliseconds: >> in other words, LogRecord.setMillis(LogRecord.getMillis()) was no longer >> idempotent. >> >> This changes proposes to restore LogRecord.getMillis() to its previous >> status, and also fixes LogRecord.setInstant to reject instant values >> which would not fit in a long milliseconds-since-epoch - which would >> have caused serialization to fail and LogRecord.getMillis() to throw >> an undocumented ArithmeticException. >> >> Rationale about this proposed change have also been discussed in this >> thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037039.html >> >> >> best regards, >> >> -- daniel >> From paul.sandoz at oracle.com Wed Dec 2 23:00:22 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Dec 2015 00:00:22 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <565F1A5A.4040509@oracle.com> References: <7e5e2f21-a462-4fb8-8cb2-52f4c9e303fb@default> <17CDB8FA-3B1E-465A-8FB6-121113BE66CA@oracle.com> <701701d12c6d$2cfa8cd0$86efa670$@oracle.com> <9C417D00-F022-4CF6-87D3-0AF74CCD7441@oracle.com> <565F1A5A.4040509@oracle.com> Message-ID: <8D34B054-1832-428A-8A00-C7C5E1056061@oracle.com> Hi Stefan, > On 2 Dec 2015, at 17:20, Stefan S?rne wrote: > > > Hi Paul, > > The reason we stick on standard jtreg tests is because it is simpler. > For us, a java test is not a unit test, it is an application. :) > I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let?s call it duck unit testing, it looks and quacks like a unit test :-) > I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE. In the case of the JDK it's not jtreg over testng it is jtreg + testng. > But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred. > How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools? Paul. From kim.barrett at oracle.com Wed Dec 2 23:20:29 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2015 18:20:29 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <565F5355.6040209@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> Message-ID: <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: > > Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 109 * The Cleaner terminates when it is unreachable and all of the objects 110 * registered are unreachable and corresponding cleaning functions are complete. and 131 * The Cleaner terminates when it is unreachable and all of the objects 132 * registered are unreachable and corresponding Runnables are complete. Cleaner termination does not require registered objects to be unreachable, only that the registered cleaning functions are complete. A completed call to clean() on an associated Cleanable also counts as a cleaning function completion, irrespective of whether the associated object is unreachable. Also, there is the inconsistent terminology between "cleaning functions" and "Runnables". ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 134 * Typically, only a single thread is requested from the ThreadFactory. Is that an actual promise? If not, it might be better to not say anything at all. ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 140 public static Cleaner create(ThreadFactory threadFactory) { 141 Objects.requireNonNull(threadFactory, "threadFactory"); Is there a reason to require threadFactory to be non-null? This means that if a caller obtains a factory by some means that might return null, the caller needs to conditionally select which create call to make. ------------------------------------------------------------------------------ src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 117 * Process queued Cleanables as long as the cleanableList is not empty. There are multiple lists of cleanables; all must be empty. Similarly for "the list" here: 118 * A Cleanable is in the list for each Object and for the Cleaner 119 * itself. ------------------------------------------------------------------------------ src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 199 PhantomCleanable(CleanerImpl cleanerImpl) { 200 super(null, null); This feels mildly icky, passing a null referent to a Reference constructor. (Similarly for the other XxxCleanable classes.) Also, in this case, passing a null queue to the PhantomReference class. Both (presently) work, but still... ------------------------------------------------------------------------------ src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 223 private boolean remove() { 224 PhantomCleanable list = cleanerImpl.phantomCleanableList; 225 synchronized (list) { 226 if (next != this) { Shouldn't that be "if (prev != this) {" ? Insertion is always after the special sentinal, so "prev" should always be non-"this" when in the list, and "this" when out. But "this" could be the last element in the list, in which case "next == this", even though in the list. [Applies to all three of {Soft,Weak,Phantom}Cleanable.] ------------------------------------------------------------------------------ src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 237 /** 238 * Returns true if the list's next reference refers to itself. 239 * 240 * @return true if the list is empty 241 */ 242 boolean isListEmpty() { 243 PhantomCleanable list = cleanerImpl.phantomCleanableList; 244 synchronized (list) { 245 return next == list; 246 } 247 } Based on the description, one might expect some occurrence of "this" in the body. This function must only be applied to the special head sentinal, so a pre-condition is "list == this". Either an assert or some mention of this would make this easier to understand. [Applies to all three of {Soft,Weak,Phantom}Cleanable.] ------------------------------------------------------------------------------ From mandy.chung at oracle.com Thu Dec 3 00:06:30 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Dec 2015 16:06:30 -0800 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: <2EDB2846-96A2-4C36-A44F-DC3FAD48BF94@oracle.com> References: <28639752-BD0A-4B91-BE3F-61DEA4B997FA@oracle.com> <2EDB2846-96A2-4C36-A44F-DC3FAD48BF94@oracle.com> Message-ID: > On Dec 2, 2015, at 2:36 PM, Paul Sandoz wrote: > > >> On 2 Dec 2015, at 22:24, Mandy Chung wrote: >> >> >>> On Nov 26, 2015, at 1:55 AM, Paul Sandoz wrote: >>> >>> Hi, >>> >>> This is a request for an optimistic review to fork the sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables so that we can evolve the latter e.g. for VarHandles unsafe work >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ >> >> Looks good. About the tests, would it be better for these tests be placed in the jdk repo? >> > > That?s my preferred back up plan :-) Something to ponder while waiting for 8143930 (C1 LinearScan...) to be integrated. > My reason of suggesting that because they should be part of the core test group that are run by core-libs and SQE nightly and hs-rt nightly (majority of the core tests if not all). > >> Nit: extra lines in the testAccess method in several new tests can be removed. >> >> 144 static void testAccess(Object base, long offset) { >> 145 // Plain >> 146 { >> 147 UNSAFE.putDouble(base, offset, 1.0d); >> 148 double x = UNSAFE.getDouble(base, offset); >> 149 assertEquals(x, 1.0d, "set double value"); >> 150 } >> 151 >> 152 // Volatile >> 153 { >> 154 UNSAFE.putDoubleVolatile(base, offset, 2.0d); >> 155 double x = UNSAFE.getDoubleVolatile(base, offset); >> 156 assertEquals(x, 2.0d, "putVolatile double value"); >> 157 } >> 158 >> 159 >> 160 >> 161 >> 162 } > > I could remove empty lines in the template between #if/#end blocks but i find it harder to read. So i would prefer to leave this as is. That?s fine with me. Mandy From kubota.yuji at gmail.com Thu Dec 3 00:42:13 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 3 Dec 2015 09:42:13 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: <565EF499.6040709@oracle.com> References: <565EF499.6040709@oracle.com> Message-ID: Hi Miroslav, 2015-12-02 22:39 GMT+09:00 Miroslav Kos : > 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 for your quick response and push! I will get 2nd "Contributed-by" for becoming an author :) Thanks, Yuji From martinrb at google.com Thu Dec 3 00:51:10 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Dec 2015 16:51:10 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <5655CD53.7050206@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> Message-ID: We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of adding the dependent action as a suppressed exception of the source. I'm willing to accept the small incompatibility of throwing a different exception when everything fails; the existing spec doesn't promise what happens in this case. From kubota.yuji at gmail.com Thu Dec 3 02:48:23 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 3 Dec 2015 11:48:23 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries Message-ID: Hi all, We need reviewer(s) for this PoC. Could you please review this proposal and PoC ? Thanks, Yuji 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : > Hi all, > > * Sorry for my mistake. I re-post this mail because I sent before get > a response of subscription confirmation of core-libs-dev. > > Our customers have to handle password-protected zip files. However, > Java SE does not provide the APIs to handle it yet, so we must use > third party library so far. > > Recently, we found JDK-4347142: "Need method to set Password > protection to Zip entries", and we tried to implement it. > > The current zlib in JDK is completely unaffected by this proposal. The > traditional zip encryption encrypts a data after it is has been > compressed by zlib.[1] So we do NOT need to change existing zlib > implementation. > > We've created PoC and uploaded it as webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ > > Test code is as below. This code will let you know how this PoC works. > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java > > In NTT, a Japanese telecommunications company. We are providing many > enterprise systems to customers. Some of them, we need to implement to > handle password-protected zip file. I guess that this proposal is > desired for many developers and users. > > I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). > We want to implement it if this proposal accepted. > > [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT > (6.0 Traditional PKWARE Encryption) > > Thanks, > Yuji From xueming.shen at oracle.com Thu Dec 3 03:29:54 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 2 Dec 2015 19:29:54 -0800 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: References: Message-ID: <565FB732.4090401@oracle.com> Hi Yuji, I will take a look at your PoC. Might need some time and even bring in the security guy to evaluate the proposal. It seems like you are only interested in the "traditional PKWare decryption", which is, based on the wiki, "known to be seriously flawed, and in particular is vulnerable to known-plaintext attacks":-) Any request to support "stronger" encryption mechanism, such as the AES based? Regards, Sherman On 12/2/15 6:48 PM, KUBOTA Yuji wrote: > Hi all, > > We need reviewer(s) for this PoC. > Could you please review this proposal and PoC ? > > Thanks, > Yuji > > 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >> Hi all, >> >> * Sorry for my mistake. I re-post this mail because I sent before get >> a response of subscription confirmation of core-libs-dev. >> >> Our customers have to handle password-protected zip files. However, >> Java SE does not provide the APIs to handle it yet, so we must use >> third party library so far. >> >> Recently, we found JDK-4347142: "Need method to set Password >> protection to Zip entries", and we tried to implement it. >> >> The current zlib in JDK is completely unaffected by this proposal. The >> traditional zip encryption encrypts a data after it is has been >> compressed by zlib.[1] So we do NOT need to change existing zlib >> implementation. >> >> We've created PoC and uploaded it as webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >> >> Test code is as below. This code will let you know how this PoC works. >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >> >> In NTT, a Japanese telecommunications company. We are providing many >> enterprise systems to customers. Some of them, we need to implement to >> handle password-protected zip file. I guess that this proposal is >> desired for many developers and users. >> >> I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). >> We want to implement it if this proposal accepted. >> >> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >> (6.0 Traditional PKWARE Encryption) >> >> Thanks, >> Yuji From amy.lu at oracle.com Thu Dec 3 05:24:34 2015 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Dec 2015 13:24:34 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565F084E.505@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com> Message-ID: <565FD212.5070505@oracle.com> (I'm not a reviewer) Just a minor question. jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. Missed? or justbecause this test will be totally removed soon in a separate bugid? Thanks, Amy On 12/2/15 11:03 PM, Chris Hegarty wrote: > Updated to remove all use of reflection. If someone really > wants to run S11N on an older JDK, then it is a simple > edit to uncomment/comment 3 lines. > > http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ > > -Chris. > > On 02/12/15 14:15, Chris Hegarty wrote: >> On 02/12/15 14:03, Alan Bateman wrote: >>> >>> On 02/12/2015 12:08, Chris Hegarty wrote: >>>> The regression tests in the jdk should be updated, where possible, to >>>> use java.util.Base64. >>>> >>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >>> Should S11N be updated to serialize with JDK 8 so that the core >>> reflection code isn't needed? >> >> This is certainly possible and would make the test simpler, but >> I followed the comments in the test ( it needs to be runnable on >> older JDKs ). I think this is a reasonable requirement since the >> test contains bytes array that were generated on older JDKs. Of >> course, the test could contain the older JDK code commented out. >> If someone really wants to run it with 1.6, then they just make >> the simple edits. >> >> I'm ok with any of these solutions, or just removing the possibility >> of running on older JDKs. >> >> -Chris. From david.holmes at oracle.com Thu Dec 3 05:53:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2015 15:53:12 +1000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F0698.7080600@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> Message-ID: <565FD8C8.6020105@oracle.com> On 3/12/2015 12:56 AM, Doug Lea wrote: > > Bringing Martin's JEP comment > (https://bugs.openjdk.java.net/browse/JDK-8046936) > to the lists: > > Approximately 100% of the cases of StackOverflowError (SOE) we > hear about lately on concurrency-interest are due to long chains > of CompletableFutures that exist because of the lack of > tail-recursion loopification by compilers. I don't think > any of these have involved ReentrantLocks, but some hit problems > due to lack of finally { ... } cleanup inside Executors upon SOE. > > In the absence of any of: tail-recursion support, reliable cleanup, > or growable stacks, it seems reasonable to choose larger default > stack sizes so that these long but finite chains of completions > are far less likely to hit SOE. > > On 32bit systems the 1MB limit is completely defensible. But expanding > to say 64MB on 64bit systems would reduce practical encounters with > SOE in these kinds of constructions by a factor of 64 or so. > Is there any reason not to do this? The same discussion on the concurrency-interest mailing list seems to indicate that there are indeed reasons to not do this. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html David > -Doug > > > From kubota.yuji at gmail.com Thu Dec 3 07:51:18 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 3 Dec 2015 16:51:18 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <565FB732.4090401@oracle.com> References: <565FB732.4090401@oracle.com> Message-ID: Hi Sherman, Thanks for your quick response :) I aimed to implement the "traditional" at this proposal by the below reasons. * We want to prepare API for encrypted zip files at first. * Many people use the "traditional" in problem-free scope like a temporary file. * We do not know which implementation of the "stronger" is best for openjdk. * PKWare claims that they have patents about the "stronger" on Zip[1]. * OTOH, WinZip have the alternative implementation of the "stronger" [2][3]. * Instead, we prepared the extensibility by ZipCryption interface to implement other encrypt engine, such as the AES based. Thus, I think this PoC should support the "traditional" only. In the future, anyone who want to implement the "stronger" can easily add their code by virtue of this proposal. [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT (1.4 Permitted Use & 7.0 Strong Encryption Specification) [2] https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy [3] http://www.winzip.com/aes_info.htm Thanks, Yuji 2015-12-03 12:29 GMT+09:00 Xueming Shen : > > Hi Yuji, > > I will take a look at your PoC. Might need some time and even bring in the > security guy > to evaluate the proposal. It seems like you are only interested in the > "traditional PKWare > decryption", which is, based on the wiki, "known to be seriously flawed, and > in particular > is vulnerable to known-plaintext attacks":-) Any request to support > "stronger" encryption > mechanism, such as the AES based? > > Regards, > Sherman > > > On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >> >> Hi all, >> >> We need reviewer(s) for this PoC. >> Could you please review this proposal and PoC ? >> >> Thanks, >> Yuji >> >> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>> >>> Hi all, >>> >>> * Sorry for my mistake. I re-post this mail because I sent before get >>> a response of subscription confirmation of core-libs-dev. >>> >>> Our customers have to handle password-protected zip files. However, >>> Java SE does not provide the APIs to handle it yet, so we must use >>> third party library so far. >>> >>> Recently, we found JDK-4347142: "Need method to set Password >>> protection to Zip entries", and we tried to implement it. >>> >>> The current zlib in JDK is completely unaffected by this proposal. The >>> traditional zip encryption encrypts a data after it is has been >>> compressed by zlib.[1] So we do NOT need to change existing zlib >>> implementation. >>> >>> We've created PoC and uploaded it as webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>> >>> Test code is as below. This code will let you know how this PoC >>> works. >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>> >>> In NTT, a Japanese telecommunications company. We are providing many >>> enterprise systems to customers. Some of them, we need to implement to >>> handle password-protected zip file. I guess that this proposal is >>> desired for many developers and users. >>> >>> I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). >>> We want to implement it if this proposal accepted. >>> >>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>> (6.0 Traditional PKWARE Encryption) >>> >>> Thanks, >>> Yuji > > From peter.levart at gmail.com Thu Dec 3 08:12:40 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 09:12:40 +0100 Subject: RFE Pre-review: Support for cloning exceptions In-Reply-To: References: <565D830A.10508@gmail.com> <565EBAA6.7080402@gmail.com> Message-ID: <565FF978.304@gmail.com> Hi Martin, I see this is a controversial topic and I would really not like to delay changes to CompletableFuture because of that. Anyway I feel I should answer to some of your concerns... On 12/02/2015 07:39 PM, Martin Buchholz wrote: > > > On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart > wrote: > > > In short, I think exceptions are a special hierarchy with special > use pattern in which clone() would not present a practical problem > that generally arises in other objects that are meant to change > state independently from their creation. > > > Java is supposed to be a high reliability platform and introducing new > exotic failure modes isn't something we should be doing. My work at > Google prejudices me - it seems half the work we do is trying to track > down rare bugs we can't reproduce, or happen once every cpu-year. I agree. > > If you add "implements Cloneable" then people will call protected > nullary clone(). You haven't made it public, but it can (and will!) > be called from subclasses and their packages. I see you were careful > to copy the suppressedExceptions field in your static clone, but > callers of the "real" clone will produce two Throwables that share a > single ArrayList, which is not thread safe. Right. You can never trust users to do the recommended thing even if it is written all over the place in big friendly letters. Previous iteration had the code in virtual Throwable.clone(). I resorted to sole static method to keep behavior of possible Throwable subclasses that implement Cloneable themselves, but that behavior would actually be improved in that case. > > I'm sure there's code out there that reasonably assumes that if > something is Cloneable, then it has a public clone() method, and will > try to invoke that via reflection. This change is "observable" and of course there can be code that observes just that. If there's code that blindly calls clone() via reflection on objects that implement Cloneable, I would expect it to be prepared to handle the cases where the implementing class or the method is not accessible. > > I see that if an existing subclass of Throwable implemented Cloneable, > there would be no way (short of Unsafe) for its clone method to do a > proper copy of suppressedExceptions. In the future, if Throwable were > to implement Cloneable, then more subclasses are likely to add a > public clone() method (to "support" cloning) and that will only do a > proper copy of suppressedExceptions if you do the copying in nullary > Throwable.clone() instead of in static clone. This argument is not entirely correct. If cloning of Throwables was always invoked via the proposed static method which just delegates to vritual Object.clone(), then all overriding clone() methods in subclasses would be invoked and the code in static method would then copy the suppressed exceptions list. Of course, you have a legitimate concern that code could also invoke the virtual clone() directly, so this would be better: /** * Clones this exception by invoking {@link Object#clone()} and if this * exception has suppression enabled, also copies the list of * {@link #getSuppressed() suppressed} exceptions so that any further * {@link #addSuppressed(Throwable) additions} to * the clone's suppressed exceptions do not affect original exception's * suppressed exceptions and vice versa. If this exception has suppression * disabled, the returned clone will have suppression disabled too. * @implNote Subclasses that maintain mutable state are recommended to * override this method, call {@code super.clone()} and duplicate the mutable * state so that clone's mutable state is not shared * with this instance's. Immutable state need not be duplicated. * * @return the clone of this exception with copied list of suppressed * exceptions if suppression is enabled. * @throws CloneNotSupportedException this method does not throw it, but * if a subclass wishes to opt-out of * cloning, it should throw * CloneNotSupportedException from method * that overrides this method. It is * recommended that this is not performed * unless really needed (say a subclass * wishes to maintain a singleton instance * invariant for all costs). * @since 1.9 */ @Override protected synchronized Object clone() throws CloneNotSupportedException { Throwable clone = (Throwable) super.clone(); if (clone.suppressedExceptions != null && clone.suppressedExceptions != SUPPRESSED_SENTINEL) { // suppressedExceptions has already been added to and suppression is enabled clone.suppressedExceptions = new ArrayList<>(clone.suppressedExceptions); } return clone; } /** * Invokes {@link Throwable#clone()} and modifies the returned clone in * the following way before returning it: *

* If {@code resetCause} parameter is {@code true}, then clone's * {@link #getCause() cause} is reset to uninitialized state so it can be * {@link #initCause(Throwable) initialized} again. *

* If {@code resetSuppressed} parameter is {@code true} and original exception * has suppression enabled, then clone's suppressed exceptions are cleared, * but since clone maintains it's own list of suppressed exceptions, original * exception's suppressed exceptions are not affected. * * @param exception the exception to clone. * @param the type of exception * @param resetCause if {@code true}, clone's cause is reset to * uninitialized state. * @param resetSuppressed if {@code true} and original exception has suppression * enabled, clone's suppressed exceptions are cleared. * @return clone of given exception modified according to passed-in flags. * @throws CloneNotSupportedException if {@link Throwable#clone()} throws it. * @since 1.9 */ @SuppressWarnings("unchecked") public static T cloneException(T exception, boolean resetCause, boolean resetSuppressed) throws CloneNotSupportedException { Throwable clone = (Throwable) exception.clone(); if (resetCause) { // reset to uninitialized state clone.cause = clone; } if (resetSuppressed && clone.suppressedExceptions != null && clone.suppressedExceptions != SUPPRESSED_SENTINEL) { // clear suppressed exceptions if suppression is enabled // and there are already suppressed exceptions added to the // copied list clone.suppressedExceptions.clear(); } return (T) clone; } > > Sadly, making Throwable Cloneable is exceedingly subtle and I think we > will regret it (as we do the design of Cloneable itself). I tend to agree. In a perfect world, programmers code carefully and pay attention to details, but in real world they need hard constraints. Thanks for reading and discussing, Regards, Peter From bengt.rutisson at oracle.com Thu Dec 3 08:16:57 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 3 Dec 2015 09:16:57 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <565FFA79.4040600@oracle.com> Hi Kim, Thanks for pushing this through! Looks good. Bengt On 2015-12-02 19:37, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From peter.levart at gmail.com Thu Dec 3 09:22:02 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 10:22:02 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> Message-ID: <566009BA.50804@gmail.com> Hi Martin, On 12/03/2015 01:51 AM, Martin Buchholz wrote: > We're stuck. Peter wants to make Throwables cloneable, I want to > reverse the order of throwables and add the past Throwable as a > suppressed exception to the exception of a dependent action, and Doug > wants the current webrev behavior of adding the dependent action as a > suppressed exception of the source. > > I'm willing to accept the small incompatibility of throwing a > different exception when everything fails; the existing spec doesn't > promise what happens in this case. As said in the other thread, I don't want to delay the changes to CompletableFuture with the support for cloning of exception. If this ever gets accepted (and probably won't) the CompletableFuture and ForkJoinTask could be revisited. I see we have 3 options now for CompletableFuture: - do nothing (ignore whenComplete exception when previous stage completes exceptionally too) - add whenComplete exception to the exception from previous stage (as proposed currently in wave 2) which is thread-safe, but modifies the exceptional outcome of previous stage after it has already completed and thus could non-deterministically change the behavior of existing code (very unlikely, but possible). - add the exception from previous stage to whenComplete exception (as endorsed by Martin) which changes the behavior and bends the spec. a little What about the 4th option (keep current behavior, but try the best-effort with reflection to make new exception of the same type): ... } catch (Throwable ex) { if (x == null) { x = ex; } else { // try to create new exception with same: // type, cause, suppressed exceptions and stack-trace... Throwable nx; Class xClass = x.getClass(); try { Constructor xConstr = xClass.getConstructor(Throwable.class); nx = (Throwable) xConstr.newInstance(x.getCause()); } catch (Exception e1) { try { nx = (Throwable) xClass.newInstance(); nx.initCause(x.getCause()); } catch (Exception e2) { // no luck nx = null; } } if (nx != null) { // inherit stack-trace of original exception nx.setStackTrace(x.getStackTrace()); // inherit suppressed exceptions for (Throwable sx : x.getSuppressed()) { nx.addSuppressed(sx); } // add 'ex' as a final suppressed exception nx.addSuppressed(ex); x = nx; } } } completeThrowable(x, r); ... Note that such code and similar code in ForkJoinTask.getThrowableException will probably have to be modified for jigsaw to include dynamic addition of read-edge to the module of exception class... Regards, Peter From timo.kinnunen at gmail.com Thu Dec 3 09:40:22 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Thu, 3 Dec 2015 10:40:22 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> Message-ID: <56600e07.6adec20a.30cbb.2a33@mx.google.com> Hi, Following the single-threaded try-with-resources semantics very closely might not give the most useful result because there is at least one aspect that?s fundamentally different between these cases. That is, in the case where the ?try?-stage (or block) completes normally but the ?finally?-stage completes abruptly, in the CompletableFuture version ?completes normally? has an extralinguistic representation that continues to exists until it is garbage collected. It seems terribly wasteful to just throw that away and overwrite or ignore it if the ?finally?-stage completes abruptly. Given the previous, modeling ?completes normally? and ?completes abruptly? both as exceptional completions in CompletableFuture would match the reality more closely. In both cases a container for the result will be present, which can be viewed as analogous to a Throwable in the single-threaded case. Then, it is in the completion stage results container where the suppressing and cloning should happen, and not in the Throwables contained in it. Sent from Mail for Windows 10 From: Martin Buchholz Sent: Thursday, December 3, 2015 01:51 To: Peter Levart Cc: core-libs-dev Subject: Re: RFR: jsr166 jdk9 integration wave 2 We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of adding the dependent action as a suppressed exception of the source. I'm willing to accept the small incompatibility of throwing a different exception when everything fails; the existing spec doesn't promise what happens in this case. From michael.haupt at oracle.com Thu Dec 3 10:05:10 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 3 Dec 2015 11:05:10 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation Message-ID: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 Thanks, Michael -- 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 is committed to developing practices and products that help protect the environment From chris.hegarty at oracle.com Thu Dec 3 10:43:49 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Dec 2015 10:43:49 +0000 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: <565FD212.5070505@oracle.com> References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com> <565FD212.5070505@oracle.com> Message-ID: > On 3 Dec 2015, at 5:24 a.m., Amy Lu wrote: > > (I'm not a reviewer) Thanks for looking at this Amy, all eyes are welcome. > Just a minor question. > > jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. > Missed? or justbecause this test will be totally removed soon in a separate bugid? Since this test is specifically designed to test the coder functionality, then it will be proposed to be removed when the coders are. Thanks, -Chris. > Thanks, > Amy > >> On 12/2/15 11:03 PM, Chris Hegarty wrote: >> Updated to remove all use of reflection. If someone really >> wants to run S11N on an older JDK, then it is a simple >> edit to uncomment/comment 3 lines. >> >> http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/ >> >> -Chris. >> >>> On 02/12/15 14:15, Chris Hegarty wrote: >>>> On 02/12/15 14:03, Alan Bateman wrote: >>>> >>>>> On 02/12/2015 12:08, Chris Hegarty wrote: >>>>> The regression tests in the jdk should be updated, where possible, to >>>>> use java.util.Base64. >>>>> >>>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/ >>>> Should S11N be updated to serialize with JDK 8 so that the core >>>> reflection code isn't needed? >>> >>> This is certainly possible and would make the test simpler, but >>> I followed the comments in the test ( it needs to be runnable on >>> older JDKs ). I think this is a reasonable requirement since the >>> test contains bytes array that were generated on older JDKs. Of >>> course, the test could contain the older JDK code commented out. >>> If someone really wants to run it with 1.6, then they just make >>> the simple edits. >>> >>> I'm ok with any of these solutions, or just removing the possibility >>> of running on older JDKs. >>> >>> -Chris. > From claes.redestad at oracle.com Thu Dec 3 10:40:44 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 3 Dec 2015 11:40:44 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56601C2C.2040308@oracle.com> Looks good! There seem to be quite a bit more that could be fixed to avoid going through the signature string, either here or as follow-ups, e.g.: LambdaForm prep = getPreparedForm(basicTypeSignature()); private static LambdaForm getPreparedForm(String sig) { MethodType mtype = signatureType(sig); LambdaForm prep = mtype.form().cachedLambdaForm(MethodTypeForm.LF_INTERPRET); if (prep != null) return prep; assert(isValidSignature(sig)); prep = new LambdaForm(sig); prep.vmentry = InvokerBytecodeGenerator.generateLambdaFormInterpreterEntryPoint(sig); return mtype.form().setCachedLambdaForm(MethodTypeForm.LF_INTERPRET, prep); } ... could be inlined into prepare() (the only caller) as: MethodType mtype = methodType(); LambdaForm prep = mtype.form().cachedLambdaForm(MethodTypeForm.LF_INTERPRET); if (prep == null) { String sig = basicTypeSignature(); assert(isValidSignature(sig)); prep = new LambdaForm(sig); prep.vmentry = InvokerBytecodeGenerator.generateLambdaFormInterpreterEntryPoint(sig); prep = mtype.form().setCachedLambdaForm(MethodTypeForm.LF_INTERPRET, prep); } this.vmEntry = prep; All-in-all quite small micro-optimizations, but since there are startup-sensitive use-cases lining up this seems worthwhile to untangle. /Claes On 2015-12-03 11:05, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 > Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 > > Thanks, > > Michael > From ott at mirix.org Thu Dec 3 10:54:03 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 10:54:03 +0000 Subject: [bug] sun.nio.ch.WindowsSelectorImpl uses Pipe.open Message-ID: <56601F4B.2090405@mirix.org> Expected behaviour: sun.nio.ch.WindowsSelectorImpl#wakeup works if sun.nio.ch.WindowsSelectorProvider is not the provider for java.nio.channels.Pipe#open. Actual behaviour: sun.nio.ch.WindowsSelectorImpl#WindowsSelectorImpl uses java.nio.channels.Pipe#open to create a pipe for java.nio.Selector#wakeup and then casts the Pipe to sun.nio.ch.SelChImpl to get its file descriptor. If sun.nio.ch.WindowsSelectorProvider is not the provider that creates the pipe through Pipe#open the Pipe object might not be castable to SelChImpl and also the file descriptor is very likely meaningless to WindowsSelectorImpl. Suggested fix: WindowsSelectorImpl should call sun.nio.ch.PipeImpl directly. From amy.lu at oracle.com Thu Dec 3 11:23:59 2015 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 3 Dec 2015 19:23:59 +0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com> <565FD212.5070505@oracle.com> Message-ID: <5660264F.2040705@oracle.com> On 12/3/15 6:43 PM, Chris Hegarty wrote: >> >Just a minor question. >> > >> >jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. >> >Missed? or justbecause this test will be totally removed soon in a separate bugid? > Since this test is specifically designed to test the coder > functionality, then it will be proposed to be removed when the coders are. > > Thanks, > -Chris. > Thank you Chris for clarifying this. Thanks, Amy From ott at mirix.org Thu Dec 3 11:38:02 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 11:38:02 +0000 Subject: [bug] sun.nio.ch.PipeImpl uses IPv4 Message-ID: <5660299A.9050408@mirix.org> Expected behaviour: If you assume that sun.nio.ch.PipeImpl communicates over local TCP/IP sockets, PipeImpl should open a socket on and connect to over localhost. Actual behaviour: sun.nio.ch.PipeImpl open a socket on and connects to 127.0.0.1. Suggested fix: sun.nio.ch.PipeImpl should use localhost instead of 127.0.0.1. RFC 6761 states that "[users] may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address". This assumption is correct on all supported versions of Microsoft Windows (in non-broken configurations). From ott at mirix.org Thu Dec 3 11:56:50 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 11:56:50 +0000 Subject: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections Message-ID: <56602E02.4060904@mirix.org> Expected behaviour: sun.nio.ch.PipeImpl uses anonymous pipes, i.e. CreatePipe and related functions, to create pipes on Microsoft Windows. Actual behaviour: sun.nio.ch.PipeImpl loopback TCP/IP connections to create pipes. Therefore the number of pipes is less or equal to the size of the dynamic port range and due to RFC 6335 limited to a maximum of 8191 pipes (two ports per pipe) for the entire system (not accounting for any other uses of the ports). Modern computers can handle more threads than this limit if the threads use selectors or pipes, the limit of pipes is also the limit of threads and selectors of the entire system. Suggested fix: sun.nio.ch.PipeImpl should use anonymous pipe. It seems that supported versions of Microsoft Windows can create millions of handles and is not limited to the dynamic port range. From Alan.Bateman at oracle.com Thu Dec 3 12:35:20 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Dec 2015 12:35:20 +0000 Subject: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections In-Reply-To: <56602E02.4060904@mirix.org> References: <56602E02.4060904@mirix.org> Message-ID: <56603708.9080103@oracle.com> On 03/12/2015 11:56, Matthias-Christian Ott wrote: > : > > Suggested fix: > > sun.nio.ch.PipeImpl should use anonymous pipe. It seems that supported > versions of Microsoft Windows can create millions of handles and is not > limited to the dynamic port range. That was the original proposal back in JDK 1.4 when this API was being developed. There were several issues at the time, including I think security issues on the versions of Windows at the time, and I don't think anyone has got back to it. So best to create an issue for it and bring a patch to nio-dev to discuss. -Alan From ott at mirix.org Thu Dec 3 12:45:52 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 12:45:52 +0000 Subject: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections In-Reply-To: <56603708.9080103@oracle.com> References: <56602E02.4060904@mirix.org> <56603708.9080103@oracle.com> Message-ID: <56603980.2040709@mirix.org> On 03/12/15 12:35, Alan Bateman wrote: > On 03/12/2015 11:56, Matthias-Christian Ott wrote: >> : >> >> Suggested fix: >> >> sun.nio.ch.PipeImpl should use anonymous pipe. It seems that supported >> versions of Microsoft Windows can create millions of handles and is not >> limited to the dynamic port range. > That was the original proposal back in JDK 1.4 when this API was being > developed. There were several issues at the time, including I think > security issues on the versions of Windows at the time, and I don't > think anyone has got back to it. So best to create an issue for it and > bring a patch to nio-dev to discuss. Should I forward the bug reports to nio-dev@ then? - Matthias-Christian From sundararajan.athijegannathan at oracle.com Thu Dec 3 12:55:49 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 3 Dec 2015 18:25:49 +0530 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56603BD5.2060203@oracle.com> Looks good -Sundar On 12/3/2015 3:35 PM, Michael Haupt wrote: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 > Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 > > Thanks, > > Michael > From peter.levart at gmail.com Thu Dec 3 13:01:28 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 14:01:28 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <56603D28.6040206@gmail.com> Hi Kim, Kudos for finding an observable change in behavior. Although the specification could also be read in a way so that this would not be observable. Originally it states: "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. *An object that is reachable via phantom references will remain so* until all such references are cleared or themselves become unreachable." I read this as: "... An object that is reachable via phantom references will remain phantom reachable ..." If phantom-reachable objects have links among them, this doesn't make them strongly reachable. So I would argue that when both roots to O1 and O2 (in the test) are finally removed, O1 and O2 should be considered phantom-reachable, regardless of the link from O1 -> O2. When root to O2 is removed before the 2nd GC round, P2 should be notified as O2 transitions from reachable -> phantom reachable. This is no different from the situation when both roots to O1 and O2 are removed at the same time before a GC round: both P1 and P2 are notified. Anyway, this change is good. I would only rephrase this statement in package-info.java a bit: 96 * Soft and weak references are automatically cleared by the collector 97 * before being added to the queues with which they are registered, if any, 98 * hence they need not be registered with a queue in order to be useful. 99 * Phantom references, by contrast, do not allow their referents to be 100 * retrieved, so they must be registered with a queue. Perhaps to something like: Soft, weak and phantom references are automatically cleared by the collector before being added to the queues with which they are registered, if any. While Soft and weak references allow access to the referent before they are cleared, and hence need not be registered with a queue in order to be useful, Phantom references prevent access to the referent and are only useful when registered with a queue. Regards, Peter On 12/02/2015 07:37 PM, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From Ulf.Zibis at CoSoCo.de Thu Dec 3 13:40:17 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Thu, 3 Dec 2015 14:40:17 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56604641.7090603@CoSoCo.de> Hi Michael, since arity, result and names[] are final values, both - methodType() and basicTypeSignature() - values could be precomputed at instantiation or at least lazily cached. For the first, both values could be computed with the same for loop, for the latter, basicTypeSignature() could reuse pTypes (better than ptypes) from methodType(). -Ulf Am 03.12.2015 um 11:05 schrieb Michael Haupt: > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 > Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 > > Thanks, > > Michael > From chris.hegarty at oracle.com Thu Dec 3 13:55:50 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Dec 2015 13:55:50 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <565F5355.6040209@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> Message-ID: <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> On 2 Dec 2015, at 20:23, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Just a few minor inconsistencies, and subjective wording suggestions: 1) "Cleaner manages a set of ?? -> "A Cleaner manages a set of ?? 2) "related to"- > "relating to? ?? 3) "Return a new Cleaner? -> "ReturnS a new Cleaner? 4) " Cleanable is a registered cleaning function.? -> ?A Cleanable is a registered cleaning function." 5) "Unregister the Cleanable and invoke the ?? -> "UnregisterS the Cleanable and invokeS the ?? 6) Is a Cleanable a @FunctionalInterface ? -Chris. From michael.haupt at oracle.com Thu Dec 3 14:08:54 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 3 Dec 2015 15:08:54 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: Dear all, thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 The string signature is now only used in tracing and assertions, which is why caching it is not necessary. Caching the method type might be worthwhile, but this requires further analysis: it is used in LF bytecode generation and DMH creation only. I'll keep it out of this change but bear it in mind. Thanks, Michael > Am 03.12.2015 um 11:05 schrieb Michael Haupt : > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 > Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 > > Thanks, > > Michael -- 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 is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Thu Dec 3 14:12:27 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 3 Dec 2015 19:42:27 +0530 Subject: RFR(S): 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest Message-ID: <56604DCB.3020204@oracle.com> Looks good http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037130.html -Sundar From frederic.parain at oracle.com Thu Dec 3 14:15:39 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 3 Dec 2015 15:15:39 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565F36DA.4060004@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <56548F9B.1000507@oracle.com> <565DC91B.9060206@oracle.com> <565F36DA.4060004@oracle.com> Message-ID: <56604E8B.6010101@oracle.com> All fixed. Thank you Dan. Fred On 02/12/2015 19:22, Daniel D. Daugherty wrote: > > On 12/1/15 9:21 AM, Frederic Parain wrote: >> Hi Dan, >> >> Thank you for your detailed review. >> My answers are in-lined below. >> >> New webrev: >> >> http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ > > Re-reviewed by comparing 8046936.0[12].hotspot.patch in jfilemerge... > > Just a couple of nits: > > src/os/windows/vm/os_windows.cpp > L2365: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; should be 6 spaces instead of 8; actually I think > this one is a tab. > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > L381: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > L194: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > L267: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > L255: assert(fr->safe_for_sender(thread), "Safety check"); > Wrong indent; this one also might be a tab > > > Thumbs up! I do not need to see a webrev for the above nits. > > Dan > > >> >> >> On 24/11/2015 17:26, Daniel D. Daugherty wrote: >>> >>> src/cpu/sparc/vm/frame_sparc.cpp >>> (old) L635: if (fp() - sp() > 1024 + >>> m->max_stack()*Interpreter::stackElementSize) { >>> (new) L635: if (fp() - unextended_sp() > 1024 + >>> m->max_stack()*Interpreter::stackElementSize) { >>> This looks like a bug fix independent of this fix. >> >> Correct, this is the SPARC version of JDK-8068655. >> >>> src/share/vm/runtime/thread.hpp >>> L953: intptr_t* _reserved_stack_activation; >>> L1382: intptr_t* reserved_stack_activation() const { return >>> _reserved_stack_activation; } >>> L1383: void set_reserved_stack_activation(intptr_t* addr) { >>> >>> I was expecting this type to be 'address' instead of >>> 'intptr_t*'. >>> >>> Update: I've gone back through the changes and I still don't >>> see a reason that this is 'intptr_t*'. >> >> The _reserved_stack_activation has been declared as an 'intptr_t*' >> just to be consistent with the _sp and _fp fields of the frame class. >> However, this is not really a requirement, the content stored at the >> _reserved_stack_activation address is never read. This address is just >> a "marker" on the stack to quickly check if the thread has exited the >> annotated code section or not. I've change the type to address, there's >> slightly less casts, and it doesn't impact the ReservedStackArea logic. >> >> Note: I've removed all further comments about _reserved_stack_activation >> type in order to improve the e-mail readability. >> >>> L1341: { return stack_yellow_zone_base();} >>> '{' should be at the end of the previous line. >>> Missing space after ';'. >> >> Fixed >> >>> L1343: { return StackReservedPages * os::vm_page_size(); } >>> '{' should be at the end of the previous line. >> >> Fixed >> >>> src/share/vm/runtime/thread.cpp >>> L2543: // The base notation is from the stacks point of view, >>> growing downward. >>> L2565: // The base notation is from the stacks point of view, >>> growing downward. >>> Typo: "stacks point of view" -> "stack's point of view" >> >> Fixed >> >>> L2552: } else { >>> L2553: warning("Attempt to guard stack reserved zone failed."); >>> L2554: } >>> L2555: enable_register_stack_guard(); >>> >>> Should enable_register_stack_guard() be called when we issued >>> the warning on L2553? >>> >>> L2571: } else { >>> L2572: warning("Attempt to unguard stack reserved zone >>> failed."); >>> L2573: } >>> L2574: disable_register_stack_guard(); >>> >>> Should disable_register_stack_guard() be called when we issued >>> the warning on L2572? >> >> enable_register_stack_guard() and disable_register_stack_guard() are >> relics of the Itanium code (Itanium had a very different stack >> management). These methods are currently empty on all OpenJDK and >> Oracle platforms. May be another clean up opportunity here. >> Regarding the placement of the calls, I followed the same pattern >> as the other red/yellow pages management functions. >> >>> src/share/vm/runtime/sharedRuntime.cpp >>> >>> L784: java_lang_Throwable::set_message(exception_oop, >>> L785: Universe::delayed_stack_overflow_error_message()); >>> Wrong indent; this should line up under the 'e' after the '('. >> >> Fixed >> >>> L2976: if (fr.is_interpreted_frame()) { >>> L2978: prv_fr = fr; >>> L2982: prv_fr = fr; >>> This line is in both branches of the if-statement on L2976. >>> Is there a reason not to save prv_fr before L2976? >> >> No particular reason, fixed. >> >>> L2996 continue; >>> Wrong indent; needs one more space. >> >> Fixed >> >>> L2958: frame activation; >>> L3013: return activation; >>> The return on L3013 can return a default constructed 'frame'. >>> Is that default safe to return here? >> >> Yes, the caller performs a check before using the returned >> frame: >> if (activation.sp() != NULL) { ... >> >>> >>> src/os/bsd/vm/os_bsd.hpp >>> L109: static bool get_frame_at_stack_banging_point(JavaThread* >>> thread, ucontext_t* uc, frame* fr); >>> Wrong indent; needs one less space. >> >> Fixed >> >>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>> L322: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L323: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L379: assert(fr->safe_for_sender(thread), "Safety check"); >>> L380: if (!fr->is_first_java_frame()) { >>> L381: *fr = fr->java_sender(); >>> The assert() on L379 should be before the java_sender() >>> call on L381. >> >> Fixed >> >>> src/os/linux/vm/os_linux.cpp >>> L1902: jt->stack_guards_enabled()) { // No pending >>> stack overflow exceptions >>> This line's comment used to align with the previous line's >>> comment. >>> Can you move the previous line's comment to align with this >>> one? >> >> Done. >> >>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>> L135: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L136: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L192: assert(fr->safe_for_sender(thread), "Safety check"); >>> L193: if (!fr->is_first_java_frame()) { >>> L194: *fr = fr->java_sender(); >>> The assert() on L192 should be before the java_sender() >>> call on L194. >> >> Fixed >> >>> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp >>> L209: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L210: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L265: assert(fr->safe_for_sender(thread), "Safety check"); >>> L266: if (!fr->is_first_java_frame()) { >>> L267: *fr = fr->java_sender(); >>> The assert() on L265 should be before the java_sender() >>> call on L267. >> >> Fixed >> >>> L279: //assert(fr->safe_for_sender(thread), "Safety check"); >>> Delete this line; you copied it to L282. >> >> Done >> >>> L287 return true; >>> Should this assert be added above this line? >>> assert(fr->is_java_frame(), "Safety check"); >> >> Yes, this assert exists on other platforms, and there's no >> reason to omit it on Solaris/SPARC >> >>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>> L195: // For Forte Analyzer AsyncGetCallTrace profiling support - >>> thread >>> L196: // is currently interrupted by SIGPROF. >>> Now fetch_frame_from_ucontext() is also used for stack overflow >>> signal handling. >> >> Fixed >> >>> L253: assert(fr->safe_for_sender(thread), "Safety check"); >>> L254: if (!fr->is_first_java_frame()) { >>> L255: *fr = fr->java_sender(); >>> The assert() on L253 should be before the java_sender() >>> call on L255. >> >> Fixed >> >>> L273: *fr = fr->java_sender(); >>> Wrong indent; one too many spaces. >> >> Fixed >> >> >>> src/os/windows/vm/os_windows.cpp >>> L2364: assert(fr->safe_for_sender(thread), "Safety check"); >>> L2365: if (!fr->is_first_java_frame()) { >>> L2366: *fr = fr->java_sender(); >>> The assert() on L2364 should be before the java_sender() >>> call on L2366. >> >> Fixed >> >>> L2387: return true; >>> Should this assert be added above this line? >>> assert(fr->is_java_frame(), "Safety check"); >> >> Certainly, fixed. >> >>> src/share/vm/oops/method.hpp >>> (old) L87: u1 _flags; >>> (new) L88: u2 _flags; >>> Ouch - just needed one more bit... >> >> The initial implementation of the reserved stack area used the last >> bit, but unfortunately, someone else steal it before I could push >> my code :-( So I had to extend the flags field >> >>> L834: return (_flags & _reserved_stack_access) != 0; >>> Wrong indent; two fewer spaces. >> >> Fixed >> >>> src/share/vm/runtime/globals.hpp >>> L3549: range(MIN_STACK_RESERVED_PAGES, >>> (DEFAULT_STACK_RESERVED_PAGES+10))\ >>> Wrong indent; should line up below the double quote in >>> the previous line. >> >> Fixed >> >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> L328 IRT_ENTRY(void, >>> InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* >>> thread)) >>> >>> The regular throw_StackOverflowError() increments >>> a counter: >>> >>> L313: Atomic::inc(&Exceptions::_stack_overflow_errors); >>> >>> Should this function increment the same counter or >>> a different counter? >> >> Good catch! I've added the counter increment to the method >> throw_delayed_StackOverflowError(). I don't see a strong >> rational to create a new counter for delayed stack overflows, >> so it increments the same counter as throw_StackOverflowError(). >> >>> >>> src/cpu/sparc/vm/macroAssembler_sparc.hpp >>> L1423: // Check for reserved stack access in method being exited >>> (for the compilers) >>> The X86 version says "for JIT compilers". I prefer "JIT". >> >> Fixed >> >>> src/cpu/x86/vm/macroAssembler_x86.hpp >>> L643: // Check for reserved stack access in method being exited >>> (for JIT compilers) >>> The SPARC version says "for the compilers". >> >> Fixed >> >>> src/share/vm/ci/ciMethod.cpp >>> L95: _has_reserved_stack_access = >>> h_m()->has_reserved_stack_access(); >>> Wrong indent; should be only one space before '='. >> >> Fixed >> >>> src/share/vm/c1/c1_GraphBuilder.cpp >>> L3323: if(callee->has_reserved_stack_access()) { >>> L3336: if(callee->has_reserved_stack_access()) { >>> L3356: if(callee->has_reserved_stack_access()) { >>> Missing space between 'if' and '('. >> >> All fixed. >> >>> src/cpu/x86/vm/x86_32.ad >>> L737: size += 64; // added to support ReservedStackAccess >>> Usually I hate literals like this, but this function has >>> them in spades. :-( >> >> I agree but I didn't find a better solution. >> >>> src/cpu/x86/vm/x86_64.ad >>> L960: MacroAssembler _masm(&cbuf); >>> L965: MacroAssembler _masm(&cbuf); >>> >>> I think you can delete the _masm on L965. >> >> Right, removed. >> >>> src/share/vm/opto/compile.cpp >>> L675: >>> _has_reserved_stack_access(target->has_reserved_stack_access()) { >>> Wrong indent; should be a single space between ')' and '{'. >> >> Fixed >> >>> test/runtime/ReservedStack/ReservedStackTest.java >>> L26: * @run main/othervm -XX:-Inline >>> -XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread >>> >>> ReservedStackTest >>> >>> Should the comma before 'setExclusiveOwnerThread' be a period? >>> Perhaps both formats work... >> >> Both formats work, but I changed it to be a period, it's cleaner. >> >>> L47: * else >>> Wrong indent; needs one more space before 'else'. >>> >>> L52: * successfully update the status of the lock but he method >>> Typo: 'update the' -> 'updates the' >>> Typo: 'he method' -> 'the method' >>> >>> L60: * first StackOverflowError is thrown, the Error is catched >>> Typo: 'is catched' -> 'is caught' >>> >>> L61: * and a few dozens frames are exited. Now the thread has >>> Typo: 'a few dozens frames' -> 'a few dozen frames' >>> >>> L66: * of its invocation, tries to acquire the next lock >>> Typo: 'its invocation' -> 'its invocations' >>> >>> L81: * stack to prevent false sharing. The test is using this >>> Perhaps 'The test is using this' >>> -> 'The test relies on this' >>> >>> to better match wording on L225-6. >>> >>> L82: * to have different stack alignments and hit the targeted >>> Grammar: 'and hit' -> 'when it hits' >>> >>> L102: * exploit the property that interpreter frames are (much) >>> Typo: 'exploit' -> 'exploits' >>> Delete extra space after 'the'. >>> >>> L123: //LOCK_ARRAY_SIZE value >>> Add a space after '//'. >>> >>> L188: @jdk.internal.vm.annotation.ReservedStackAccess >>> This isn't privileged code and -XX:-RestrictReservedStack >>> isn't specified so what does this do? >> >> It checks that by default the annotation is ignored for non-privileged >> code, in case it is not ignored, the test would fail. >> >>> >>> L201: System.exit(-1); >>> Wrong indent; needs two more spaces. >> >> All fixed. >> >> Thank you very much! >> >> Fred >> >>>> >>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Code review for web revs you sent out. >>>>> Code looks good. I am not as familiar with the compiler code. >>>>> >>>>> I realize you need to check in at least a subset of the >>>>> java.util.concurrent changes for >>>>> the test to work, so maybe I should not have asked Doug about his >>>>> preference there. >>>>> Sorry. >>>>> >>>>> I am impressed you found a way to make a reproducible test! >>>>> >>>>> Comments/questions: >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>> >>>> Fixed >>>> >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>> this >>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>> windows >>>>> will need testing before enabling? >>>> >>>> More than testing, the implementation would have to be completed on >>>> Windows. I've added a comment to JDK-8067946. >>>> >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >>>>> solaris_x86 if >>>>> this is in interpreter code, you explicitly return the Java sender >>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>> and Windows >>>>> as well? I do see the assertion in caller that you do have a java >>>>> frame. >>>> >>>> It doesn't make sense to check the current frame (no bytecode has been >>>> executed yet, so risk of partially executed critical section). I did >>>> the >>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>> and Windows too. >>>> >>>>> 4. test line 83 ?writtent? -> ?written? >>>> >>>> Fixed >>>> >>>>> 5. I like the way you set up the preallocated exception and then set >>>>> the message - we may >>>>> try that for default methods in future. >>>>> >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>> you already check that in? >>>> >>>> I've fixed x86 platforms in JDK-8068655. >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>> I had hoped it would have been silently accepted :-) >>>> >>>> >>>>> 7. I see the change in trace.xml, and I see an include added to >>>>> SharedRuntime.cpp, >>>>> but I didn?t see where it was used - did I just miss it? >>>> >>>> trace.xml changes define a new event. >>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>> in the next 3 lines. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From claes.redestad at oracle.com Thu Dec 3 14:13:58 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 3 Dec 2015 15:13:58 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56604E26.8050400@oracle.com> On 2015-12-03 15:08, Michael Haupt wrote: > Dear all, > > thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 Excellent! > > The string signature is now only used in tracing and assertions, which is why caching it is not necessary. > > Caching the method type might be worthwhile, but this requires further analysis: it is used in LF bytecode generation and DMH creation only. I'll keep it out of this change but bear it in mind. Seems reasonable to examine this - and perhaps re-examine the weakly interned set inside MethodType - in isolation. /Claes From sundararajan.athijegannathan at oracle.com Thu Dec 3 14:30:29 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 3 Dec 2015 20:00:29 +0530 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56605205.8020101@oracle.com> Looks good -Sundar On 12/3/2015 7:38 PM, Michael Haupt wrote: > Dear all, > > thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 > > The string signature is now only used in tracing and assertions, which is why caching it is not necessary. > > Caching the method type might be worthwhile, but this requires further analysis: it is used in LF bytecode generation and DMH creation only. I'll keep it out of this change but bear it in mind. > > Thanks, > > Michael > >> Am 03.12.2015 um 11:05 schrieb Michael Haupt : >> >> Dear all, >> >> please review this change. >> RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 >> >> Thanks, >> >> Michael > From Ulf.Zibis at CoSoCo.de Thu Dec 3 14:40:07 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Thu, 3 Dec 2015 15:40:07 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> Message-ID: <56605447.9050900@CoSoCo.de> Hi again, why not simply? : 1282 MethodType type = mt.changeParameterType(0, MethodHandle.class); In any case, the state of the external mt becomes changed, so better clone mt. Additional suggestion to save the in and out packing with MethodType: 1279 static MemberName generateLambdaFormInterpreterEntryPoint(Type rType, Type[] pTypes) { -Ulf Am 03.12.2015 um 15:08 schrieb Michael Haupt: > Dear all, > > thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 > > The string signature is now only used in tracing and assertions, which is why caching it is not necessary. > > Caching the method type might be worthwhile, but this requires further analysis: it is used in LF bytecode generation and DMH creation only. I'll keep it out of this change but bear it in mind. > > Thanks, > > Michael > >> Am 03.12.2015 um 11:05 schrieb Michael Haupt : >> >> Dear all, >> >> please review this change. >> RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 >> >> Thanks, >> >> Michael > From sundararajan.athijegannathan at oracle.com Thu Dec 3 15:06:52 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 3 Dec 2015 20:36:52 +0530 Subject: RFR 8143404: Remove apple script engine code in jdk repository Message-ID: <56605A8C.9060300@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8143404 Webrev: http://cr.openjdk.java.net/~sundar/8143404/webrev.00/ Apple script engine implementing javax.script engine API is being removed. AppleScript engine has flip flopped between working and broken many times.The services configuration (META-INF/services) file was missing and only worked by accident when installing JDK 7 or JDK 8 on systems that had Apple's version of AppleScriptEngine.jar already on the system. So, it is removed for jdk 9. Thanks, -Sundar From michael.haupt at oracle.com Thu Dec 3 15:21:40 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 3 Dec 2015 16:21:40 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <56605447.9050900@CoSoCo.de> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> <56605447.9050900@CoSoCo.de> Message-ID: <505986EA-1C67-4D31-A7CC-4EBF984DD482@oracle.com> Hi Ulf, the change (as of webrev.01) is pushed. Nevertheless, thanks for your comments - responses below. > Am 03.12.2015 um 15:40 schrieb Ulf : > why not simply? : > 1282 MethodType type = mt.changeParameterType(0, MethodHandle.class); > > In any case, the state of the external mt becomes changed, so better clone mt. Cloning mt here is not necessary, as changeParameterType() will create a new MT instance. If that's what you mean. > Additional suggestion to save the in and out packing with MethodType: > 1279 static MemberName generateLambdaFormInterpreterEntryPoint(Type rType, Type[] pTypes) { A MethodType is an apt abstraction for what is needed here; I don't think breaking it up into its components would help much. Thanks, Michael -- 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 is committed to developing practices and products that help protect the environment From Ulf.Zibis at CoSoCo.de Thu Dec 3 15:35:26 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Thu, 3 Dec 2015 16:35:26 +0100 Subject: RFR(XS): 8072844: Use more efficient LambdaForm type representation In-Reply-To: <505986EA-1C67-4D31-A7CC-4EBF984DD482@oracle.com> References: <85301CC8-C0A7-4544-AF0B-B559E44117B8@oracle.com> <56605447.9050900@CoSoCo.de> <505986EA-1C67-4D31-A7CC-4EBF984DD482@oracle.com> Message-ID: <5660613E.3080909@CoSoCo.de> Hi Michael, Am 03.12.2015 um 16:21 schrieb Michael Haupt: > Cloning mt here is not necessary, as changeParameterType() will create a new MT instance. If that's what you mean. > > A MethodType is an apt abstraction for what is needed here; I don't think breaking it up into its components would help much. Hm, then maybe get the values directly from LambaForm with static MemberName generateLambdaFormInterpreterEntryPoint(LambaForm lf) { Thanks for your comments, -Ulf From Roger.Riggs at oracle.com Thu Dec 3 15:39:38 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Dec 2015 10:39:38 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56603D28.6040206@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> Message-ID: <5660623A.5020706@oracle.com> +1 on the change as a whole. Editorially, I agree that paragraph in the package-info obscures the point its trying to make. Your suggestion is clearer. Roger On 12/03/2015 08:01 AM, Peter Levart wrote: > Hi Kim, > > Kudos for finding an observable change in behavior. Although the > specification could also be read in a way so that this would not be > observable. Originally it states: > > "Unlike soft and weak references, phantom references are not > automatically cleared by the garbage collector as they are enqueued. > *An object that is reachable via phantom references will remain so* > until all such references are cleared or themselves become unreachable." > > I read this as: "... An object that is reachable via phantom > references will remain phantom reachable ..." > > If phantom-reachable objects have links among them, this doesn't make > them strongly reachable. > > So I would argue that when both roots to O1 and O2 (in the test) are > finally removed, O1 and O2 should be considered phantom-reachable, > regardless of the link from O1 -> O2. When root to O2 is removed > before the 2nd GC round, P2 should be notified as O2 transitions from > reachable -> phantom reachable. This is no different from the > situation when both roots to O1 and O2 are removed at the same time > before a GC round: both P1 and P2 are notified. > > Anyway, this change is good. I would only rephrase this statement in > package-info.java a bit: > > 96 * Soft and weak references are automatically cleared by the > collector > 97 * before being added to the queues with which they are > registered, if any, > 98 * hence they need not be registered with a queue in order to be > useful. > 99 * Phantom references, by contrast, do not allow their referents > to be > 100 * retrieved, so they must be registered with a queue. > > Perhaps to something like: > > Soft, weak and phantom references are automatically cleared by the > collector before being added to the queues with which they are > registered, if any. While Soft and weak references allow access to the > referent before they are cleared, and hence need not be registered > with a queue in order to be useful, Phantom references prevent access > to the referent and are only useful when registered with a queue. > > > > Regards, Peter > > On 12/02/2015 07:37 PM, Kim Barrett wrote: >> Please review this change to PhantomReference processing, changing the >> GC-based notification to automatically clear the referent. >> >> This change provides performance benefits by eliminating the work >> involved in keeping the otherwise inaccessible referent objects alive, >> as required by the existing specification. This not only immediately >> removes some work, but may enable further performance improvements. >> It also allows the referent objects to be immediately reclaimed in >> the GC cycle in which they were determined to be inaccessible, rather >> than lingering as a form of floating garbage until the application >> deals with the notified reference. >> >> This change results in a behavioral change to application code, as >> demonstrated by the associated test. Under the old specification, a >> reference R with referent X may be kept alive because it is referenced >> by an otherwise inaccessible referent Y of phantom reference P. This >> will result in X being treated as strongly referenced and prevent R >> from being notified, even if R is a phantom reference and X has become >> inaccessible to the application. With this change, Y is reclaimed >> when it becomes inaccessible and P is notified, and no longer prevents >> X from itself becoming a candidate for reclaimation once it is no >> longer accessible to the application. While this is a change in >> behavior, it seems unlikely to affect applications negatively. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8071507 >> >> Webrevs: >> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ >> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >> >> Testing: >> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >> > From Alan.Bateman at oracle.com Thu Dec 3 15:42:17 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Dec 2015 15:42:17 +0000 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <56605A8C.9060300@oracle.com> References: <56605A8C.9060300@oracle.com> Message-ID: <566062D9.4020907@oracle.com> On 03/12/2015 15:06, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143404 > Webrev: http://cr.openjdk.java.net/~sundar/8143404/webrev.00/ > > Apple script engine implementing javax.script engine API is being > removed. AppleScript engine has flip flopped between working and > broken many times.The services configuration (META-INF/services) file > was missing and only worked by accident when installing JDK 7 or JDK 8 > on systems that had Apple's version of AppleScriptEngine.jar already > on the system. So, it is removed for jdk 9. There are few references to these classes/directories that will need to be cleaned up too. I see on in the langtools repo, another in the top-level repo in the unshuffle_list.txt. -Alan. From Roger.Riggs at oracle.com Thu Dec 3 15:58:45 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Dec 2015 10:58:45 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> Message-ID: <566066B5.2010104@oracle.com> Hi Chris, Thanks for the review and comments: The webrev and javadoc have been updated. On 12/03/2015 08:55 AM, Chris Hegarty wrote: > On 2 Dec 2015, at 20:23, Roger Riggs wrote: > >> Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public >> interface to support only phantom cleanup. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > Just a few minor inconsistencies, and subjective wording suggestions: > > 1) "Cleaner manages a set of ?? -> "A Cleaner manages a set of ?? This is the first sentence looks better in the package summary without the article and matches the descriptions of other classes in the package. > > 2) "related to"- > "relating to? ?? ok > > 3) "Return a new Cleaner? -> "ReturnS a new Cleaner? right > > 4) " Cleanable is a registered cleaning function.? -> > ?A Cleanable is a registered cleaning function." ditto, first sentence form above. > > 5) "Unregister the Cleanable and invoke the ?? -> > "UnregisterS the Cleanable and invokeS the ?? ok > > 6) Is a Cleanable a @FunctionalInterface ? But marking it as @FunctionalInterface is not advisable. The interface is not implemented by clients of the Cleaner. The only implementation is inside the Cleaner implementation and there is no point in drawing attention to the interface in tools. Roger > > -Chris. From peter.levart at gmail.com Thu Dec 3 16:19:13 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 17:19:13 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <565F5355.6040209@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> Message-ID: <56606B81.6060906@gmail.com> Hi Roger, I now think that this is the right move. The simplified API is really only useful for PhantomReference(s). Since Cleaner.Cleanable interface does not provide access to the referent, it would be tempting for users to do two things at once for the same referent with Weak or Soft reachability: - register cleanup function with: Cleaner.registerWeak(referent, () -> ...); and - wrap the referent with: WeakReference wr = new WeakReference<>(referent); ...to get both features: obtainable referent and automatically managed cleanup. This would of course work, but would not be very efficient. In Phantom-only world, they will not be tempted to do such thing. Regards, Peter On 12/02/2015 09:23 PM, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Thanks, Roger > > > On 11/23/2015 5:32 PM, mark.reinhold at oracle.com wrote: >> ( Finally getting back to this, after too many weeks of travel ... ) >> >> 2015/10/20 11:28 -0700, roger.riggs at oracle.com: >>> Sorry for the silence, JavaOne preparations and the availability of >>> folks who wanted to review have stretched things out. >>> >>> The Cleaner API was very simple and saw feature creep as the ideas for >>> how it might be used were explored. There are concerns about >>> committing to supporting subclassable CleanableReferences in all >>> future JDK versions before there had been a chance to see how if they >>> would be useful and necessary to address the need to reduce the use of >>> finalization within the OpenJDK and beyond. >>> >>> ... >>> >>> Updated Javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>> >>> Updated Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> I'm very happy to see this API return to something like its original >> simple form, but I think it can be simplified even further. >> >> We have a very strong need for phantom-ref-based cleaners, so as to >> discourage people from relying upon flaky finalization. The arguments in >> support of the weak and soft forms have, by contrast, been rather weak >> (and soft?). I don't think it's right to bake methods into a core API >> based on just a couple of hypothetical use cases. I'd much rather see >> the Cleaner::{phantom,soft,weak}Cleanable methods reduced to a single >> register method, >> >> Cleaner.Cleanable register(Object, Runnable); >> >> which would create the phantom form only. If strong justification for >> the other forms arise then we can generalize this later, either to >> distinct register{Soft,Weak} methods or, perhaps, to a method that takes >> a type token. >> >> - Mark > From brian.burkhalter at oracle.com Thu Dec 3 16:31:58 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Dec 2015 08:31:58 -0800 Subject: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections In-Reply-To: <56603980.2040709@mirix.org> References: <56602E02.4060904@mirix.org> <56603708.9080103@oracle.com> <56603980.2040709@mirix.org> Message-ID: <3D5A5F32-A78D-4A8D-8F4D-7D4C528F87D8@oracle.com> On Dec 3, 2015, at 4:45 AM, Matthias-Christian Ott wrote: >> So best to create an issue for it and >> bring a patch to nio-dev to discuss. > > Should I forward the bug reports to nio-dev@ then? Bugs should be filed via [1]. Contributions including fixes may then be submitted according to [2]. Brian [1] http://bugs.java.com/ [2] http://openjdk.java.net/contribute/ From mandy.chung at oracle.com Thu Dec 3 17:01:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 09:01:02 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56603D28.6040206@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> Message-ID: <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> > On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: > > I would only rephrase this statement in package-info.java a bit: > > 96 * Soft and weak references are automatically cleared by the collector > 97 * before being added to the queues with which they are registered, if any, > 98 * hence they need not be registered with a queue in order to be useful. > 99 * Phantom references, by contrast, do not allow their referents to be > 100 * retrieved, so they must be registered with a queue. Kim brought up the potential confusion on the above wordings. To me this is clear when I read it as a fresh reader (not comparing the before and after). The confusion could be due to the section header ?Automatically-cleared references?. This paragraph talks about the need of registering references (soft/weak refs vs phantom refs). I thought about (1) changing the section header to ?Registering references?, or (2) a small rewording like this: *

Automatically-cleared references

* - * Soft and weak references are automatically cleared by the collector - * before being added to the queues with which they are registered, if - * any. Therefore soft and weak references need not be registered - * with a queue in order to be useful, while phantom references do. - * An object that is reachable via phantom references will remain so - * until all such references are cleared or themselves become - * unreachable. + * References are automatically cleared by the collector before being + * added to the queues with which they are registered, if any. + * Soft and weak references allow their referents to be retrieved, + * hence they need not be registered with a queue in order to be useful. + * Phantom references, by contrast, do not allow their referents to be + * retrieved, so they must be registered with a queue. Mandy From mandy.chung at oracle.com Thu Dec 3 17:26:42 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 09:26:42 -0800 Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder In-Reply-To: References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com> <565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com> <565FD212.5070505@oracle.com> Message-ID: > On Dec 3, 2015, at 2:43 AM, Chris Hegarty wrote: > >> Just a minor question. >> >> jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. >> Missed? or justbecause this test will be totally removed soon in a separate bugid? > > Since this test is specifically designed to test the coder > functionality, then it will be proposed to be removed when the coders are. > +1 That test was retained in JDK 8 to verify the behavior of sun.misc. Now it?s time to remove it. Mandy From nadeesh.tv at oracle.com Thu Dec 3 17:52:37 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 03 Dec 2015 23:22:37 +0530 Subject: RFR: JDK-8142936:Additional java.time.Duration methods In-Reply-To: References: <5656A9A5.6050409@oracle.com> <565C3252.4030800@oracle.com> <565C9D4D.4020800@oracle.com> Message-ID: <56608165.5020300@oracle.com> Hi all, Please see the updated webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.03/ - changes - Modified the dataprovider as suggested by Roger Thanks and regards, Nadeesh On 12/1/2015 2:39 AM, Stephen Colebourne wrote: > This is all about fixing a messy API that was created in 8. The > methods propose are all about consistency. The toSeconds() method > completes the set. For each unit there is a toXxx() and a toXxxPart(). > Missing one out makes everything worse. > > Stephen > > > On 30 November 2015 at 19:02, Roger Riggs wrote: >> Hi Stephen, Nadeesh, >> >> The toXXXPart methods look fine. >> >> I'm not entirely convinced that the toSeconds() method is worth it and may >> be >> deemed as confusing with the new toSecondsPart method. >> How many people have problems with getSeconds()? >> >> The toXXXPart tests could have used a single DataProvider with >> the values supplied for each unit to reduce the duplication. >> >> Thanks, Roger >> >> >> >> >> >> On 11/30/2015 09:29 AM, Stephen Colebourne wrote: >>> I think thats ready to be merged, thanks >>> Stephen >>> >>> On 30 November 2015 at 11:26, nadeesh tv wrote: >>>> Hi all, >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ >>>> Regards, >>>> Nadeesh TV >>>> >>>> On 11/27/2015 11:20 PM, Stephen Colebourne wrote: >>>>> "Overall, looks pretty good. >>>>> >>>>> There a a number of double spaces that should be single spaces in the >>>>> Javadoc. >>>>> >>>>> Change >>>>> "This is based on the standard definition of a day has 24 hours." >>>>> to >>>>> "This is based on the standard definition of a day as 24 hours." >>>>> ("has" to "as") >>>>> There are three places to fix this. >>>>> >>>>> The toMillisPart() docs could do with some rework. >>>>> change >>>>> "number of milliseconds part in the nanosecond part of the duration" >>>>> to >>>>> "number of milliseconds part of the duration" >>>>> >>>>> try this: >>>>> "This returns the milliseconds part by dividing the number of >>>>> nanoseconds by 1,000,000." >>>>> >>>>> On the tests. >>>>> >>>>> There is no test for toSeconds(). >>>>> >>>>> For the other tests, I have been bitten before by not testing edge >>>>> cases. >>>>> A test for zero, and for a negative round number would be good. >>>>> eg. for toHoursPart() the round number would be a duration of exactly >>>>> minus 2 hours. >>>>> >>>>> Duration.ofHours(2).toDaysPart() = 0 >>>>> Duration.ofHours(2).toHoursPart() = 2 >>>>> Duration.ofHours(2).toMinutesPart() = 0 >>>>> Duration.ofHours(2).toSecondsPart() = 0 >>>>> Duration.ofHours(2).toMillisPart() = 0 >>>>> Duration.ofHours(2).toNanosPart() = 0 >>>>> >>>>> thus really six tests are needed each time. The best way to achieve >>>>> this is using @DataProvider in TestNG, where you can setup a data grid >>>>> of inputs and 6 expected outputs. >>>>> >>>>> thanks >>>>> Stephen >>>>> >>>>> >>>>> >>>>> >>>>> On 26 November 2015 at 06:41, nadeesh tv wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a fix for >>>>>> >>>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8142936 >>>>>> >>>>>> -Enhance Duration by adding toNanosPart() , >>>>>> >>>>>> toMillisPart(),toSecondsPart(),toMinutesPart(),toHoursPart(),toDaysPart() >>>>>> methods . >>>>>> - Had to rename private BigDecimal toSeconds() -> private >>>>>> BigDecimal >>>>>> toBigDecimalSeconds() >>>>>> >>>>>> >>>>>> webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.01/ >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> -- Thanks and Regards, Nadeesh TV From jason_mehrens at hotmail.com Thu Dec 3 17:54:53 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 3 Dec 2015 17:54:53 +0000 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <566009BA.50804@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> , <566009BA.50804@gmail.com> Message-ID: Hi Peter, I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) 2. Walk the type of the cause and super types by calling getConstructor(type of cause, String) (I've seen this but, I can't seem to find an example) 3. getConstructor(String) + initCause (java.io.InvalidObjectException) 4. Walk the type of the cause and super types by calling getConstructor(type of cause). (java.awt.print.PrinterIOException) 5. getConstructor() + initCause. (java.nio.BufferOverflowException) 6. Look at the return type of methods declared in the cause type and assume there is a constructor matching the type or no repeating types. (java.nio.charset.MalformedInputException, java.lang.EnumConstantNotPresentException, java.util.regex.PatternSyntaxException) In the end all of that can still fail. Exceptions can be private subclasses of public classes so that gets interesting with reflection too. Jason =========== What about the 4th option (keep current behavior, but try the best-effort with reflection to make new exception of the same type): ... } catch (Throwable ex) { if (x == null) { x = ex; } else { // try to create new exception with same: // type, cause, suppressed exceptions and stack-trace... Throwable nx; Class xClass = x.getClass(); try { Constructor xConstr = xClass.getConstructor(Throwable.class); nx = (Throwable) xConstr.newInstance(x.getCause()); } catch (Exception e1) { try { nx = (Throwable) xClass.newInstance(); nx.initCause(x.getCause()); } catch (Exception e2) { // no luck nx = null; } } if (nx != null) { // inherit stack-trace of original exception nx.setStackTrace(x.getStackTrace()); // inherit suppressed exceptions for (Throwable sx : x.getSuppressed()) { nx.addSuppressed(sx); } // add 'ex' as a final suppressed exception nx.addSuppressed(ex); x = nx; } } } completeThrowable(x, r); ... Note that such code and similar code in ForkJoinTask.getThrowableException will probably have to be modified for jigsaw to include dynamic addition of read-edge to the module of exception class... Regards, Peter From chris.hegarty at oracle.com Thu Dec 3 18:08:33 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 3 Dec 2015 18:08:33 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566066B5.2010104@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> Message-ID: On 3 Dec 2015, at 15:58, Roger Riggs wrote: > Hi Chris, > > Thanks for the review and comments: > > The webrev and javadoc have been updated. > > On 12/03/2015 08:55 AM, Chris Hegarty wrote: >> On 2 Dec 2015, at 20:23, Roger Riggs wrote: >> >>> Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public >>> interface to support only phantom cleanup. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> >>> Javadoc: >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> Just a few minor inconsistencies, and subjective wording suggestions: >> >> 1) "Cleaner manages a set of ?? -> "A Cleaner manages a set of ?? > This is the first sentence looks better in the package summary without the article > and matches the descriptions of other classes in the package. Ah yes, I see that now. Good point. >> 2) "related to"- > "relating to? ?? > ok >> >> 3) "Return a new Cleaner? -> "ReturnS a new Cleaner? > right >> 4) " Cleanable is a registered cleaning function.? -> >> ?A Cleanable is a registered cleaning function." > ditto, first sentence form above. >> >> 5) "Unregister the Cleanable and invoke the ?? -> >> "UnregisterS the Cleanable and invokeS the ?? > ok >> >> 6) Is a Cleanable a @FunctionalInterface ? > But marking it as @FunctionalInterface is not advisable. > The interface is not implemented by clients of the Cleaner. > The only implementation is inside the Cleaner implementation > and there is no point in drawing attention to the interface in tools. Ok. -Chris. From peter.levart at gmail.com Thu Dec 3 18:14:36 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Dec 2015 19:14:36 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> Message-ID: <5660868C.3050509@gmail.com> On 12/03/2015 06:01 PM, Mandy Chung wrote: >> On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: >> >> I would only rephrase this statement in package-info.java a bit: >> >> 96 * Soft and weak references are automatically cleared by the collector >> 97 * before being added to the queues with which they are registered, if any, >> 98 * hence they need not be registered with a queue in order to be useful. >> 99 * Phantom references, by contrast, do not allow their referents to be >> 100 * retrieved, so they must be registered with a queue. > Kim brought up the potential confusion on the above wordings. To me this is clear when I read it as a fresh reader (not comparing the before and after). The confusion could be due to the section header ?Automatically-cleared references?. This paragraph talks about the need of registering references (soft/weak refs vs phantom refs). I thought about (1) changing the section header to ?Registering references?, or (2) a small rewording like this: > > *

Automatically-cleared references

> * > - * Soft and weak references are automatically cleared by the collector > - * before being added to the queues with which they are registered, if > - * any. Therefore soft and weak references need not be registered > - * with a queue in order to be useful, while phantom references do. > - * An object that is reachable via phantom references will remain so > - * until all such references are cleared or themselves become > - * unreachable. > + * References are automatically cleared by the collector before being > + * added to the queues with which they are registered, if any. > + * Soft and weak references allow their referents to be retrieved, > + * hence they need not be registered with a queue in order to be useful. > + * Phantom references, by contrast, do not allow their referents to be > + * retrieved, so they must be registered with a queue. Or: ..., so they are only useful if they are registered with a queue. Better, yes. Regards, Peter > Mandy From huizhe.wang at oracle.com Thu Dec 3 19:06:34 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 03 Dec 2015 11:06:34 -0800 Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string Message-ID: <566092BA.5070709@oracle.com> Hi, This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ Thanks, Joe From lance.andersen at oracle.com Thu Dec 3 19:16:21 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 3 Dec 2015 14:16:21 -0500 Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string In-Reply-To: <566092BA.5070709@oracle.com> References: <566092BA.5070709@oracle.com> Message-ID: <01BFA4F4-4BD7-45A1-80C6-3AB1FE05E929@oracle.com> Hi Joe, Looks OK? Best Lance On Dec 3, 2015, at 2:06 PM, huizhe wang wrote: > Hi, > > This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Thu Dec 3 19:39:46 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 03 Dec 2015 11:39:46 -0800 Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string In-Reply-To: <01BFA4F4-4BD7-45A1-80C6-3AB1FE05E929@oracle.com> References: <566092BA.5070709@oracle.com> <01BFA4F4-4BD7-45A1-80C6-3AB1FE05E929@oracle.com> Message-ID: <56609A82.2060300@oracle.com> Thanks Lance! Joe On 12/3/2015 11:16 AM, Lance Andersen wrote: > Hi Joe, > > Looks OK? > > Best > Lance > On Dec 3, 2015, at 2:06 PM, huizhe wang > wrote: > >> Hi, >> >> This is a clean-up of the code in jaxp that had depended on Java >> version string. This code came from JAXP standalone that no longer >> exists. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From mandy.chung at oracle.com Thu Dec 3 20:04:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 12:04:53 -0800 Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string In-Reply-To: <566092BA.5070709@oracle.com> References: <566092BA.5070709@oracle.com> Message-ID: <707F51C2-0747-4F6D-B7D7-CBA2E3C46404@oracle.com> > On Dec 3, 2015, at 11:06 AM, huizhe wang wrote: > > Hi, > > This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ Looks good. Mandy From iris.clark at oracle.com Thu Dec 3 20:55:44 2015 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 3 Dec 2015 12:55:44 -0800 (PST) Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string In-Reply-To: <566092BA.5070709@oracle.com> References: <566092BA.5070709@oracle.com> Message-ID: <4b8ab5a4-cfbf-4d33-bc61-54e43cb4bb0a@default> Hi, Joe. This looks great. Thanks for removing this Java version-dependent code. Regards, iris -----Original Message----- From: huizhe wang Sent: Thursday, December 03, 2015 11:07 AM To: core-libs-dev at openjdk.java.net Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string Hi, This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ Thanks, Joe From huizhe.wang at oracle.com Thu Dec 3 21:10:15 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 03 Dec 2015 13:10:15 -0800 Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string In-Reply-To: <4b8ab5a4-cfbf-4d33-bc61-54e43cb4bb0a@default> References: <566092BA.5070709@oracle.com> <4b8ab5a4-cfbf-4d33-bc61-54e43cb4bb0a@default> Message-ID: <5660AFB7.8090904@oracle.com> On 12/3/2015 12:55 PM, Iris Clark wrote: > Hi, Joe. > > This looks great. Thanks. > > Thanks for removing this Java version-dependent code. Yes, together with your previous change to those jaxp tests, we are clear of all dependency on java.version from jaxp related code. Regards, Joe > > Regards, > iris > > -----Original Message----- > From: huizhe wang > Sent: Thursday, December 03, 2015 11:07 AM > To: core-libs-dev at openjdk.java.net > Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string > > Hi, > > This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ > > Thanks, > Joe > From Roger.Riggs at oracle.com Thu Dec 3 21:19:53 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Dec 2015 16:19:53 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> Message-ID: <5660B1F9.6090305@oracle.com> Hi Kim, Thanks for the comments: I updated the webrev[2] and javadoc[1] with the editorial improvements. On 12/02/2015 06:20 PM, Kim Barrett wrote: > On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: >> Please review the java.lang.ref.Cleaner and tests following the recommendation to simplify the public >> interface to support only phantom cleanup. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > ------------------------------------------------------------------------------ > src/java.base/share/classes/java/lang/ref/Cleaner.java > 109 * The Cleaner terminates when it is unreachable and all of the objects > 110 * registered are unreachable and corresponding cleaning functions are complete. > and > 131 * The Cleaner terminates when it is unreachable and all of the objects > 132 * registered are unreachable and corresponding Runnables are complete. > > Cleaner termination does not require registered objects to be > unreachable, only that the registered cleaning functions are > complete. A completed call to clean() on an associated Cleanable also > counts as a cleaning function completion, irrespective of whether the > associated object is unreachable. Yes, the cleaning functions can be completed by calling clean. * The Cleaner terminates when it is unreachable and all of the * registered cleaning functions are complete. > > Also, there is the inconsistent terminology between "cleaning > functions" and "Runnables". Updated to use cleaning function as a generic; Runnable is retained as the type of the function. > > ------------------------------------------------------------------------------ > src/java.base/share/classes/java/lang/ref/Cleaner.java > 134 * Typically, only a single thread is requested from the ThreadFactory. > > Is that an actual promise? If not, it might be better to not say > anything at all. An @implNote clause it provides information about the implementation. 'Typically' reduces the statement to informative. So no, not a promise. > > ------------------------------------------------------------------------------ > src/java.base/share/classes/java/lang/ref/Cleaner.java > 140 public static Cleaner create(ThreadFactory threadFactory) { > 141 Objects.requireNonNull(threadFactory, "threadFactory"); > > Is there a reason to require threadFactory to be non-null? This means > that if a caller obtains a factory by some means that might return > null, the caller needs to conditionally select which create call to > make. Stylistically, nulls are not usually used as defaults and may obscure unintentional cases of the caller (a bug). > > ------------------------------------------------------------------------------ > src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > 117 * Process queued Cleanables as long as the cleanableList is not empty. > > There are multiple lists of cleanables; all must be empty. fixed > > Similarly for "the list" here: > > 118 * A Cleanable is in the list for each Object and for the Cleaner > 119 * itself. fixed > > ------------------------------------------------------------------------------ > src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > 199 PhantomCleanable(CleanerImpl cleanerImpl) { > 200 super(null, null); > > This feels mildly icky, passing a null referent to a Reference > constructor. (Similarly for the other XxxCleanable classes.) > > Also, in this case, passing a null queue to the PhantomReference > class. > > Both (presently) work, but still... A dummy object could be allocated for the referent but it would have not purpose. (and null is allowed). > > ------------------------------------------------------------------------------ > src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > 223 private boolean remove() { > 224 PhantomCleanable list = cleanerImpl.phantomCleanableList; > 225 synchronized (list) { > 226 if (next != this) { > > Shouldn't that be "if (prev != this) {" ? > > Insertion is always after the special sentinal, so "prev" should > always be non-"this" when in the list, and "this" when out. But > "this" could be the last element in the list, in which case > "next == this", even though in the list. Each list is a doubly linked circular list with the list head as a separate distinct ref and is never removed. When not in a list prev == next == this; (except in list root; the list is empty) When it is in a list, prev != this && next != this > > [Applies to all three of {Soft,Weak,Phantom}Cleanable.] > > ------------------------------------------------------------------------------ > src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > 237 /** > 238 * Returns true if the list's next reference refers to itself. > 239 * > 240 * @return true if the list is empty > 241 */ > 242 boolean isListEmpty() { > 243 PhantomCleanable list = cleanerImpl.phantomCleanableList; > 244 synchronized (list) { > 245 return next == list; > 246 } > 247 } > > Based on the description, one might expect some occurrence of "this" > in the body. This function must only be applied to the special head > sentinal, so a pre-condition is "list == this". Either an assert or > some mention of this would make this easier to understand. > > [Applies to all three of {Soft,Weak,Phantom}Cleanable.] The implicit reference to 'this' is in via cleanerImpl. All of the functions insert, remove, isListEmpty need to lock on the list root and explicitly referring to the list root (via the clearerImpl) in each method keeps them aligned. IsListEmpty could be recoded to operate only on the distinguished root entry but it would be harder to see that the same lock is being used consistently. Thanks, Roger [1] http://cr.openjdk.java.net/~rriggs/cleaner-doc/ [2] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > ------------------------------------------------------------------------------ > From mandy.chung at oracle.com Thu Dec 3 21:33:51 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 13:33:51 -0800 Subject: Reference.reachabilityFence In-Reply-To: References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> Message-ID: <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> > On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: > > Hi, > > I have updated the patches: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ > > There is now more documentation on Reference (copied and suitable rearranged from 166 Fences.java). The method name remains the same. > I think the addition to the Reference class specification should belong to the reachabilityFence method specification. Any reason why not? I suggest to change this (occurs in the class spec and the method spec): strongly reachable (as defined in the {@link java.lang.ref} package documentation), to strongly reachable Should the reachabilityFence method throw NPE if ref is null? Mandy From mark.reinhold at oracle.com Thu Dec 3 21:35:02 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 Dec 2015 13:35:02 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56559EA6.9020806@redhat.com> References: <560D3F61.6040607@Oracle.com>, <560E6FEB.60607@gmail.com>, <560EA3F2.7030108@Oracle.com>, <5612F582.4050909@Oracle.com>, <5613F19E.7010708@gmail.com>, <56141107.8000407@Oracle.com>, <5616D504.4000104@Oracle.com>, <20151012123016.566133@eggemoggin.niobe.net>, <561E55CE.3000400@oracle.com>, <561E5794.5050002@Oracle.com>, <561E5A06.3000802@oracle.com>, <561E5E88.7070302@Oracle.com>, <561E6030.4020403@oracle.com>, <561E60B8.2040900@Oracle.com>, <561E654E.6040106@oracle.com>, <561E9454.6030700@Oracle.com>, <561F5FF4.1080505@gmail.com>, <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com>, <561FA84D.5030502@oracle.com>, <561FAEDE.5040100@gmail.com>, <561FCDB9.5080306@Oracle.com>, <562687C8.1040106@Oracle.com>, <20151123143205.51363@eggemoggin.niobe.net>, <5654A2B0.7090007@Oracle.com>, <56559EA6.9020806@redhat.com> Message-ID: <20151203133502.741773@eggemoggin.niobe.net> 2015/11/25 3:42 -0800, aph at redhat.com: > On 11/24/2015 05:47 PM, Roger Riggs wrote: >> Memory is an increasingly critical resource, we should be giving >> developers more tools to manage their use of memory. The Weak and >> Soft reference forms of the cleaner make it easier to be aware of >> and respond to increased memory pressure. >> >> ... > > By "memory" here, do you mean native memory for buffers, etc? I'm > guessing so. If so, I'm not sure that it makes sense to think of this > as a cure for flaky finalization. We've got a cure for early > finalization now with keepAlive() (or whatever it gets called) but > late (or never) finalization is as far as I can see unfixable. IMVHO > it makes more sense to encourage developers to get away from lifecycle > maintenance based on reachability. I could not agree more strongly! > Unfortunately the current design for ByteBuffers does not allow > unmap(), so large mapped buffers may hang around for a long time. > 4724038 says > > "We ... have given this problem a lot of thought ... We have yet to > come up with a way to implement an unmap() method that's safe, > efficient, and plausibly portable across operating systems. We've > explored several other alternatives aside from the two described > above, but all of them were even more problematic. We'd be thrilled > if someone could come up with a workable solution, so we'll leave > this bug open in the hope that it will attract attention from someone > more clever than we are." > > I'm very tempted to take a bite at this, but the above text is rather > forbidding. I think I know how to do it. (Famous last words?) As the author of the above-quoted paragraph, I wish you luck. It's a tough problem. Random musing: I wrote those words in 2005. At this point in time I suspect that an unmap method that works on some operating system but not others might be more acceptable than it would have been back then. - Mark From Roger.Riggs at oracle.com Thu Dec 3 21:42:02 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Dec 2015 16:42:02 -0500 Subject: RFR: JDK-8142936:Additional java.time.Duration methods In-Reply-To: <56608165.5020300@oracle.com> References: <5656A9A5.6050409@oracle.com> <565C3252.4030800@oracle.com> <565C9D4D.4020800@oracle.com> <56608165.5020300@oracle.com> Message-ID: <5660B72A.1010805@oracle.com> Hi Nadeesh, Thanks for the update, sorry I missed some editorial comments last time. toSeconds method missing a final period '.' "* This returns the total number of seconds in the duration" toMinutesPart method: Extra text: + * @return the number of minutes parts in the duration, may be negative + * @since 9 *+ * may be negative* + */ + public int toMinutesPart(){ Missing space in multiple places: "(){" should have a space before "{" toMillisPart and toNanosPart methods: unneeded description: "+ * The total duration is defined by calling {@link #getNano()} and {@link #getSeconds()}." toMillisPart method: remove the final "."; it should be omitted on @return, @param "+ * @return the number of milliseconds part of the duration." Thanks for coalescing the data providers. Roger On 12/03/2015 12:52 PM, nadeesh tv wrote: > Hi all, > > Please see the updated webrev - > http://cr.openjdk.java.net/~ntv/8142936/webrev.03/ > - changes - Modified the dataprovider as suggested by Roger > > Thanks and regards, > Nadeesh > > > On 12/1/2015 2:39 AM, Stephen Colebourne wrote: >> This is all about fixing a messy API that was created in 8. The >> methods propose are all about consistency. The toSeconds() method >> completes the set. For each unit there is a toXxx() and a toXxxPart(). >> Missing one out makes everything worse. >> >> Stephen >> >> >> On 30 November 2015 at 19:02, Roger Riggs >> wrote: >>> Hi Stephen, Nadeesh, >>> >>> The toXXXPart methods look fine. >>> >>> I'm not entirely convinced that the toSeconds() method is worth it >>> and may >>> be >>> deemed as confusing with the new toSecondsPart method. >>> How many people have problems with getSeconds()? >>> >>> The toXXXPart tests could have used a single DataProvider with >>> the values supplied for each unit to reduce the duplication. >>> >>> Thanks, Roger >>> >>> >>> >>> >>> >>> On 11/30/2015 09:29 AM, Stephen Colebourne wrote: >>>> I think thats ready to be merged, thanks >>>> Stephen >>>> >>>> On 30 November 2015 at 11:26, nadeesh tv >>>> wrote: >>>>> Hi all, >>>>> Please see the updated webrev >>>>> http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ >>>>> Regards, >>>>> Nadeesh TV >>>>> >>>>> On 11/27/2015 11:20 PM, Stephen Colebourne wrote: >>>>>> "Overall, looks pretty good. >>>>>> >>>>>> There a a number of double spaces that should be single spaces in >>>>>> the >>>>>> Javadoc. >>>>>> >>>>>> Change >>>>>> "This is based on the standard definition of a day has 24 hours." >>>>>> to >>>>>> "This is based on the standard definition of a day as 24 hours." >>>>>> ("has" to "as") >>>>>> There are three places to fix this. >>>>>> >>>>>> The toMillisPart() docs could do with some rework. >>>>>> change >>>>>> "number of milliseconds part in the nanosecond part of the duration" >>>>>> to >>>>>> "number of milliseconds part of the duration" >>>>>> >>>>>> try this: >>>>>> "This returns the milliseconds part by dividing the number of >>>>>> nanoseconds by 1,000,000." >>>>>> >>>>>> On the tests. >>>>>> >>>>>> There is no test for toSeconds(). >>>>>> >>>>>> For the other tests, I have been bitten before by not testing edge >>>>>> cases. >>>>>> A test for zero, and for a negative round number would be good. >>>>>> eg. for toHoursPart() the round number would be a duration of >>>>>> exactly >>>>>> minus 2 hours. >>>>>> >>>>>> Duration.ofHours(2).toDaysPart() = 0 >>>>>> Duration.ofHours(2).toHoursPart() = 2 >>>>>> Duration.ofHours(2).toMinutesPart() = 0 >>>>>> Duration.ofHours(2).toSecondsPart() = 0 >>>>>> Duration.ofHours(2).toMillisPart() = 0 >>>>>> Duration.ofHours(2).toNanosPart() = 0 >>>>>> >>>>>> thus really six tests are needed each time. The best way to achieve >>>>>> this is using @DataProvider in TestNG, where you can setup a data >>>>>> grid >>>>>> of inputs and 6 expected outputs. >>>>>> >>>>>> thanks >>>>>> Stephen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 26 November 2015 at 06:41, nadeesh tv >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a fix for >>>>>>> >>>>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8142936 >>>>>>> >>>>>>> -Enhance Duration by adding toNanosPart() , >>>>>>> >>>>>>> toMillisPart(),toSecondsPart(),toMinutesPart(),toHoursPart(),toDaysPart() >>>>>>> >>>>>>> methods . >>>>>>> - Had to rename private BigDecimal toSeconds() -> >>>>>>> private >>>>>>> BigDecimal >>>>>>> toBigDecimalSeconds() >>>>>>> >>>>>>> >>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.01/ >>>>>>> >>>>>>> -- >>>>>>> Thanks and Regards, >>>>>>> Nadeesh TV >>>>>>> >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> > From john.r.rose at oracle.com Thu Dec 3 21:47:51 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Dec 2015 13:47:51 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151203133502.741773@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <5654A2B0.7090007@Oracle.com> <56559EA6.9020806@redhat.com> <20151203133502.741773@eggemoggin.niobe.net> Message-ID: <5A7F25D7-02BC-44DE-BAF3-4AD941439C3F@oracle.com> On Dec 3, 2015, at 1:35 PM, mark.reinhold at oracle.com wrote: > >> I'm very tempted to take a bite at this, but the above text is rather >> forbidding. I think I know how to do it. (Famous last words?) > > As the author of the above-quoted paragraph, I wish you luck. It's > a tough problem. > > Random musing: I wrote those words in 2005. At this point in time I > suspect that an unmap method that works on some operating system but > not others might be more acceptable than it would have been back then. We are takeing a crack at it with Panama, since using C APIs often requires timely deallocation of (non-Java) temps. The basic components are two: 1. A type called "Scope" which is bound to a Java stack frame using try-with-resources, and whose open, append, and close operations can do things like malloc and free. 2. A smart pointer type which is a tuple (value type some day) of , whose indirection operations always check for a dead scope. This requires tricky compiler optimizations to make the scope checks fold up and go away. But it seems doable. One hard part is race conditions, but if we have fast path for operations within the thread owning the Scope, we can win, I think. (This is one reason it's important for a Scope to be bound to a stack frame.) In the absence of value types there will be a little bit of garbage created to represent the scopes and smart pointers, but it's O(N) where N is the number of operations, not O(M) where M is the number of bytes being operated on. And moving stuff to value types will reduce GC overhead even more. Basically, the little dribble of GC activity is the cost of safety. ? John From mark.reinhold at oracle.com Thu Dec 3 21:50:22 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 Dec 2015 13:50:22 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566066B5.2010104@oracle.com> References: <560D3F61.6040607@Oracle.com>, <560E6FEB.60607@gmail.com>, <560EA3F2.7030108@Oracle.com>, <5612F582.4050909@Oracle.com>, <5613F19E.7010708@gmail.com>, <56141107.8000407@Oracle.com>, <5616D504.4000104@Oracle.com>, <20151012123016.566133@eggemoggin.niobe.net>, <561E55CE.3000400@oracle.com>, <561E5794.5050002@Oracle.com>, <561E5A06.3000802@oracle.com>, <561E5E88.7070302@Oracle.com>, <561E6030.4020403@oracle.com>, <561E60B8.2040900@Oracle.com>, <561E654E.6040106@oracle.com>, <561E9454.6030700@Oracle.com>, <561F5FF4.1080505@gmail.com>, <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com>, <561FA84D.5030502@oracle.com>, <561FAEDE.5040100@gmail.com>, <561FCDB9.5080306@Oracle.com>, <562687C8.1040106@Oracle.com>, <20151123143205.51363@eggemoggin.niobe.net>, <565F5355.6040209@Oracle.com>, <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com>, <566066B5.2010104@oracle.com> Message-ID: <20151203135022.165903@eggemoggin.niobe.net> Looks good -- thanks for the further simplification. Minor editorial comments, to add what Kim and Chris noted: - In many places you write, e.g., "Cleaner" rather than "{@code Cleaner}". For consistency with the rest of the package it'd be better in most cases just to write "cleaner" or, if its nature as a class is important, write "{@code Cleaner}". The same goes for Cleanable, Thread, ThreadFactory, and all other types. - The specification of Cleaner::create() mentions "ThreadContextClassLoader", but that's not actually a type anywhere in the JDK. Suggest "{@linkplain java.lang.Thread#getContextClassLoader context class loader}. - In the same method, it'd be helpful to provide links into the Thread class (or wherever) for the concepts of access-control context and thread locals. - Mark From Roger.Riggs at oracle.com Thu Dec 3 22:09:30 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 3 Dec 2015 17:09:30 -0500 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <565DDA04.7040802@oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> Message-ID: <5660BD9A.2030705@oracle.com> Hi Sherman, It makes sense to me to provide the missing time/date as an explicit parameter for toEpochSeconds instead of assuming some constant. localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); We'll have to add the LocalDate.EPOCHDAY constant. It makes it a bit heavier weight to use but can still be optimized and won't create garbage. Roger On 12/01/2015 12:33 PM, Xueming Shen wrote: > On 12/1/15 6:36 AM, Stephen Colebourne wrote: >> As Roger says, these new methods are about performance as well as >> conversion. >> >> While I fully acknowledge the time methods make an assumption, it is >> not a crazy one, after all 1970-01-01 is just zero. >> >> Key I think is it allows: >> long epochSecs = date.toEpochSeconds(offset) + >> time.toEpochSeconds(offset); >> to efficiently merge two objects without garbage. > > So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean > approach > > LocalDate date = ... > LocalDate time = ... > ZoneOffset offset = ... > > ==> long spochSecs = LocalDateTime.of(date, time).toEpochSeconds(offset); > > we are adding APIs to provide a "fastpath" with the special assumption > that the LocalDate "date" > here is actually a "LocalDateTime" object ("date" + > LocalTime.MIDNIGHT) and the LocalTime "time" > again actually means a "LocalDateTime" (the "time" of 1970-01-01), to > let the third party "libraries" > to fool the basic date/time abstract in java.time package, simply to > avoid creating the garbage > middle man, localDateTime? it really does not sound right to me. > > First, if someone needs to mix/link LocalDate, LocalTime and Offset to > epoch seconds in their > libraries, they really SHOULD think hard about the conversion and make > it right (it should not > be encouraged to use these classes LocalDate, LocalTime and Offset > without even understand > what these classes are). But if we really have to provide such > fastpath, personally I think it might > be better either to provide these "utility/convenient" methods in a > "utilities" class, or with an > explicit date/time parameters (instead of the false assumption) for > the missing date/time piece, > such as > > localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); > localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); > > Sherman > > >> >> It also means that no-one has to think hard about the conversion, as >> it is just there. It tends to be when people try to work this stuff >> out for themselves that they get it wrong. >> >> Stephen >> >> >> On 1 December 2015 at 14:21, Roger Riggs wrote: >>> Hi Sherman, >>> >>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>> largest number of votes on SO: >>>>> >>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>> >>>>> The proposed method is designed to make the conversion easier. It >>>>> also >>>>> plugs an obvious gap in the API. >>>>> >>>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>>> having them would result in inconsistency between the various >>>>> classes. >>>>> We've already added factory methods to LocalTime for Java 9, these >>>>> are >>>>> just the other half of the picture. >>>>> >>>> I'm not sure I understand the idea of "the proposed method is >>>> designed to >>>> make the conversion easier", as the SO is mainly about >>>> j.u.Date->LocalDate, >>>> not the other way around, from LocalDate -> j.u.Date. >>> >>> I think the issue is about *other* libraries that manipulate time via >>> epochSeconds >>> not about j.u.Date conversions. The concern was about performance and >>> creating garbage along the way. >>> >>> Roger >>> >>> >>> >>>> As I said in the previous email, it might be "common" to use the >>>> j.u.Date >>>> to >>>> abstract a "local date" and/or a "local time" (no other choice) before >>>> java.time, >>>> and now there is the need to provide a migration path from those >>>> "local >>>> date/ >>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>> date/time >>>> type to the "old" j.u.Date should not be encouraged (guess this is >>>> also >>>> the >>>> consensus we agreed on back to jsr203). >>>> >>>> What are the "factory methods" you are referring to here? >>>> JDK-8133079, The >>>> LocalDate/LocalTime.ofInstant()? >>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>> >>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>> "super-set" >>>> of >>>> date/time to a "sub-set", without any assumption of "default >>>> value", it is >>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>> "small" >>>> improvement >>>> >>>> from| >>>> Date input = new Date(); >>>> LocalDatedate >>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>> >>>> to >>>> >>>> |LocalDatedate >>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>> >>>> The proposed pair toEpochSecond() however is doing the other way >>>> around >>>> and >>>> with an unusual assumption of the missing date/time piece to a >>>> "default >>>> value" >>>> (midnight, the epoch day). >>>> >>>> personally I think >>>> >>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>> >>>> is clean and good enough to help this backward conversion (with the >>>> addition >>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>>> remove that LocalDateTime middle man, with some arrangement. >>>> >>>> -Sherman >>>> >>>>> Note that these methods are specifically not referencing >>>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>>> form here, and still widely used. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> On 30 November 2015 at 19:36, Xueming Shen >>>>> wrote: >>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>> These >>>>>>> methods aim to provide a simpler and faster approach, >>>>>>> particularly for >>>>>>> cases converting to/from java.util.Date. >>>>>> Can you be a little more specific on this one? We now have >>>>>> Instance<=> >>>>>> Date, >>>>>> and considerably we might add LocalDateTime<=> Date with an >>>>>> offset, if >>>>>> really >>>>>> really desired (for performance? to save a Instant object as the >>>>>> bridge?). >>>>>> But I'm >>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>> epoch >>>>>> seconds >>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>> >>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>> >>>>>> and uses the converted j.u.Date to represent a local date (date with >>>>>> time >>>>>> part to >>>>>> be 0) and/or the local time (with year/month/day to be epoch >>>>>> time) in >>>>>> the >>>>>> "old" >>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>> abstract >>>>>> the >>>>>> "local >>>>>> date" and "local time"? >>>>>> >>>>>> I think we agreed back to JSR310 that we don't try to add such >>>>>> kind of >>>>>> "bridge/ >>>>>> convenient/utility" methods into the new java.time package, but >>>>>> only in >>>>>> the >>>>>> old date/calendar classes, if really needed. So if these methods are >>>>>> only to >>>>>> help >>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>> java.time >>>>>> might not be the best place for them? >>>>>> >>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>> commonly used in many codebases. >>>>>>> >>>>>> I'm not sure about that, especially the "natural" part. It might be >>>>>> "common" >>>>>> in >>>>>> the old days if you only have j.u.Date", and might be forced to use >>>>>> 1970-01-01 >>>>>> to fill in the "date" part even when you are really only >>>>>> interested in >>>>>> "time" part >>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>>>>> now we >>>>>> have >>>>>> separate abstract for these different need, I don't see the >>>>>> common need >>>>>> of >>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>> misunderstood >>>>>> something here. >>>>>> >>>>>> -Sherman >>>>>> >>>>>> >>>>>> >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 30 November 2015 at 18:15, Xueming Shen >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> While it is kinda understandable to have >>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of >>>>>>>> the >>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>> Local/OffsetTime >>>>>>>> to have two public methods with the assumption of the "date" is at >>>>>>>> epoch >>>>>>>> year/month/day. What's the use case/scenario for these two >>>>>>>> proposed >>>>>>>> methods? >>>>>>>> >>>>>>>> -Sherman >>>>>>>> >>>>>>>> >>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>> The method Javadoc (specs) for each of the three new methods >>>>>>>>> needs to >>>>>>>>> be enhanced. >>>>>>>>> >>>>>>>>> For the date ones it needs to say >>>>>>>>> "The resulting date will have a time component of midnight at the >>>>>>>>> start of the day." >>>>>>>>> >>>>>>>>> For the time ones it needs to say >>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>> >>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>> indented >>>>>>>>> correctly. >>>>>>>>> >>>>>>>>> Otherwise looks fine, >>>>>>>>> thanks >>>>>>>>> Stephen >>>>>>>>> >>>>>>>>> >>>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>>> wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review a fix for >>>>>>>>>> >>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>> >>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>> >>>>>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>> >>>>>>>>>> -- Thanks and Regards, >>>>>>>>>> Nadeesh TV >>>>>>>> >>>>>>> >>>>>> > From scolebourne at joda.org Thu Dec 3 22:26:56 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 3 Dec 2015 22:26:56 +0000 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <5660BD9A.2030705@oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> Message-ID: In the interests of harmony and getting something in, I'll accept that. I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY Stephen On 3 December 2015 at 22:09, Roger Riggs wrote: > Hi Sherman, > > It makes sense to me to provide the missing time/date as an explicit > parameter > for toEpochSeconds instead of assuming some constant. > > localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); > localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); > offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); > > We'll have to add the LocalDate.EPOCHDAY constant. > > It makes it a bit heavier weight to use but can still be optimized and won't > create garbage. > > Roger > > > > On 12/01/2015 12:33 PM, Xueming Shen wrote: >> >> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>> >>> As Roger says, these new methods are about performance as well as >>> conversion. >>> >>> While I fully acknowledge the time methods make an assumption, it is >>> not a crazy one, after all 1970-01-01 is just zero. >>> >>> Key I think is it allows: >>> long epochSecs = date.toEpochSeconds(offset) + >>> time.toEpochSeconds(offset); >>> to efficiently merge two objects without garbage. >> >> >> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >> approach >> >> LocalDate date = ... >> LocalDate time = ... >> ZoneOffset offset = ... >> >> ==> long spochSecs = LocalDateTime.of(date, time).toEpochSeconds(offset); >> >> we are adding APIs to provide a "fastpath" with the special assumption >> that the LocalDate "date" >> here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) >> and the LocalTime "time" >> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to let >> the third party "libraries" >> to fool the basic date/time abstract in java.time package, simply to >> avoid creating the garbage >> middle man, localDateTime? it really does not sound right to me. >> >> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >> epoch seconds in their >> libraries, they really SHOULD think hard about the conversion and make it >> right (it should not >> be encouraged to use these classes LocalDate, LocalTime and Offset without >> even understand >> what these classes are). But if we really have to provide such fastpath, >> personally I think it might >> be better either to provide these "utility/convenient" methods in a >> "utilities" class, or with an >> explicit date/time parameters (instead of the false assumption) for the >> missing date/time piece, >> such as >> >> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >> >> Sherman >> >> >>> >>> It also means that no-one has to think hard about the conversion, as >>> it is just there. It tends to be when people try to work this stuff >>> out for themselves that they get it wrong. >>> >>> Stephen >>> >>> >>> On 1 December 2015 at 14:21, Roger Riggs wrote: >>>> >>>> Hi Sherman, >>>> >>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>> >>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>> >>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>> largest number of votes on SO: >>>>>> >>>>>> >>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>> The proposed method is designed to make the conversion easier. It also >>>>>> plugs an obvious gap in the API. >>>>>> >>>>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>>>> having them would result in inconsistency between the various classes. >>>>>> We've already added factory methods to LocalTime for Java 9, these are >>>>>> just the other half of the picture. >>>>>> >>>>> I'm not sure I understand the idea of "the proposed method is designed >>>>> to >>>>> make the conversion easier", as the SO is mainly about >>>>> j.u.Date->LocalDate, >>>>> not the other way around, from LocalDate -> j.u.Date. >>>> >>>> >>>> I think the issue is about *other* libraries that manipulate time via >>>> epochSeconds >>>> not about j.u.Date conversions. The concern was about performance and >>>> creating garbage along the way. >>>> >>>> Roger >>>> >>>> >>>> >>>>> As I said in the previous email, it might be "common" to use the >>>>> j.u.Date >>>>> to >>>>> abstract a "local date" and/or a "local time" (no other choice) before >>>>> java.time, >>>>> and now there is the need to provide a migration path from those "local >>>>> date/ >>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>> date/time >>>>> type to the "old" j.u.Date should not be encouraged (guess this is also >>>>> the >>>>> consensus we agreed on back to jsr203). >>>>> >>>>> What are the "factory methods" you are referring to here? JDK-8133079, >>>>> The >>>>> LocalDate/LocalTime.ofInstant()? >>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>> >>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>> "super-set" >>>>> of >>>>> date/time to a "sub-set", without any assumption of "default value", it >>>>> is >>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>> "small" >>>>> improvement >>>>> >>>>> from| >>>>> Date input = new Date(); >>>>> LocalDatedate >>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>> >>>>> to >>>>> >>>>> |LocalDatedate >>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>> >>>>> The proposed pair toEpochSecond() however is doing the other way around >>>>> and >>>>> with an unusual assumption of the missing date/time piece to a "default >>>>> value" >>>>> (midnight, the epoch day). >>>>> >>>>> personally I think >>>>> >>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>> >>>>> is clean and good enough to help this backward conversion (with the >>>>> addition >>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>>>> remove that LocalDateTime middle man, with some arrangement. >>>>> >>>>> -Sherman >>>>> >>>>>> Note that these methods are specifically not referencing >>>>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>>>> form here, and still widely used. >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> >>>>>> On 30 November 2015 at 19:36, Xueming Shen >>>>>> wrote: >>>>>>> >>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>> >>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>> These >>>>>>>> methods aim to provide a simpler and faster approach, particularly >>>>>>>> for >>>>>>>> cases converting to/from java.util.Date. >>>>>>> >>>>>>> Can you be a little more specific on this one? We now have >>>>>>> Instance<=> >>>>>>> Date, >>>>>>> and considerably we might add LocalDateTime<=> Date with an offset, >>>>>>> if >>>>>>> really >>>>>>> really desired (for performance? to save a Instant object as the >>>>>>> bridge?). >>>>>>> But I'm >>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>> epoch >>>>>>> seconds >>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>> >>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>> >>>>>>> and uses the converted j.u.Date to represent a local date (date with >>>>>>> time >>>>>>> part to >>>>>>> be 0) and/or the local time (with year/month/day to be epoch time) in >>>>>>> the >>>>>>> "old" >>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>> abstract >>>>>>> the >>>>>>> "local >>>>>>> date" and "local time"? >>>>>>> >>>>>>> I think we agreed back to JSR310 that we don't try to add such kind >>>>>>> of >>>>>>> "bridge/ >>>>>>> convenient/utility" methods into the new java.time package, but only >>>>>>> in >>>>>>> the >>>>>>> old date/calendar classes, if really needed. So if these methods are >>>>>>> only to >>>>>>> help >>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>> java.time >>>>>>> might not be the best place for them? >>>>>>> >>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>> commonly used in many codebases. >>>>>>>> >>>>>>> I'm not sure about that, especially the "natural" part. It might be >>>>>>> "common" >>>>>>> in >>>>>>> the old days if you only have j.u.Date", and might be forced to use >>>>>>> 1970-01-01 >>>>>>> to fill in the "date" part even when you are really only interested >>>>>>> in >>>>>>> "time" part >>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is now >>>>>>> we >>>>>>> have >>>>>>> separate abstract for these different need, I don't see the common >>>>>>> need >>>>>>> of >>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>> misunderstood >>>>>>> something here. >>>>>>> >>>>>>> -Sherman >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 30 November 2015 at 18:15, Xueming Shen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> While it is kinda understandable to have >>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of the >>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>> Local/OffsetTime >>>>>>>>> to have two public methods with the assumption of the "date" is at >>>>>>>>> epoch >>>>>>>>> year/month/day. What's the use case/scenario for these two proposed >>>>>>>>> methods? >>>>>>>>> >>>>>>>>> -Sherman >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>> >>>>>>>>>> The method Javadoc (specs) for each of the three new methods needs >>>>>>>>>> to >>>>>>>>>> be enhanced. >>>>>>>>>> >>>>>>>>>> For the date ones it needs to say >>>>>>>>>> "The resulting date will have a time component of midnight at the >>>>>>>>>> start of the day." >>>>>>>>>> >>>>>>>>>> For the time ones it needs to say >>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>> >>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>> indented >>>>>>>>>> correctly. >>>>>>>>>> >>>>>>>>>> Otherwise looks fine, >>>>>>>>>> thanks >>>>>>>>>> Stephen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for >>>>>>>>>>> >>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>> >>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>> >>>>>>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>> Nadeesh TV >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >> > From kim.barrett at oracle.com Thu Dec 3 22:29:20 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:29:20 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5660B1F9.6090305@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> Message-ID: <51B3A31E-ABBB-4E40-AE73-E5F7CD079014@oracle.com> On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote: > >> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >> 199 PhantomCleanable(CleanerImpl cleanerImpl) { >> 200 super(null, null); >> >> This feels mildly icky, passing a null referent to a Reference >> constructor. (Similarly for the other XxxCleanable classes.) >> >> Also, in this case, passing a null queue to the PhantomReference >> class. >> >> Both (presently) work, but still... >> > A dummy object could be allocated for the referent but it would have not purpose. > (and null is allowed). Yes, I know. It still feels icky to me. Oh well. >> >> ------------------------------------------------------------------------------ >> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >> 223 private boolean remove() { >> 224 PhantomCleanable list = cleanerImpl.phantomCleanableList; >> 225 synchronized (list) { >> 226 if (next != this) { >> >> Shouldn't that be "if (prev != this) {" ? >> >> Insertion is always after the special sentinal, so "prev" should >> always be non-"this" when in the list, and "this" when out. But >> "this" could be the last element in the list, in which case >> "next == this", even though in the list. >> > Each list is a doubly linked circular list with the list head as a separate distinct ref and is never removed. > When not in a list prev == next == this; (except in list root; the list is empty) > When it is in a list, prev != this && next != this Drat! I forgot or failed to notice the lists are circular. Yesterday seems to have been a particularly bad code understanding day for me. >> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >> 237 /** >> 238 * Returns true if the list's next reference refers to itself. >> 239 * >> 240 * @return true if the list is empty >> 241 */ >> 242 boolean isListEmpty() { >> 243 PhantomCleanable list = cleanerImpl.phantomCleanableList; >> 244 synchronized (list) { >> 245 return next == list; >> 246 } >> 247 } >> >> Based on the description, one might expect some occurrence of "this" >> in the body. This function must only be applied to the special head >> sentinal, so a pre-condition is "list == this". Either an assert or >> some mention of this would make this easier to understand. >> >> [Applies to all three of {Soft,Weak,Phantom}Cleanable.] >> > The implicit reference to 'this' is in via cleanerImpl. > > All of the functions insert, remove, isListEmpty need to lock on the list root > and explicitly referring to the list root (via the clearerImpl) in each method > keeps them aligned. > IsListEmpty could be recoded to operate only on the distinguished root entry > but it would be harder to see that the same lock is being used consistently. I think that, as written, it would return true if applied to the last element of a non-empty list. (That never happens at present.) If the test were "list == list.next? that (potential) failure mode would be eliminated. That would also make the code and the comment line up nicely, though the comment would then be kind of redundant, as it doesn?t provide any explanation for why that works. Your call. So looks good to me. From ecki at zusammenkunft.net Thu Dec 3 22:30:25 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 3 Dec 2015 23:30:25 +0100 Subject: [bug] sun.nio.ch.PipeImpl uses IPv4 In-Reply-To: <5660299A.9050408@mirix.org> References: <5660299A.9050408@mirix.org> Message-ID: <9432a135-dcbc-4f03-88e5-f9e0e11c0e8a.maildroid@localhost> I think this is somewhat intentional: potential broken localhost resolve or resolve of 127.0.0.1 vs. ::1 are just a bunch of causes for problems (and delays) which are all avoided by hardcoding the address family and address. However it causes now problems when systems are migrating to v6only. At least the v4 vs. V6 problem is quite real... the best would be of course to avoid AFINET completely ,) Having said that a stabel InetAddress for a (working!) Loopback which is v6 aware would be nice (for other purposes). Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Matthias-Christian Ott To: core-libs-dev at openjdk.java.net Sent: Do., 03 Dez. 2015 14:05 Subject: [bug] sun.nio.ch.PipeImpl uses IPv4 Expected behaviour: If you assume that sun.nio.ch.PipeImpl communicates over local TCP/IP sockets, PipeImpl should open a socket on and connect to over localhost. Actual behaviour: sun.nio.ch.PipeImpl open a socket on and connects to 127.0.0.1. Suggested fix: sun.nio.ch.PipeImpl should use localhost instead of 127.0.0.1. RFC 6761 states that "[users] may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address". This assumption is correct on all supported versions of Microsoft Windows (in non-broken configurations). From kim.barrett at oracle.com Thu Dec 3 22:33:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:33:10 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5660868C.3050509@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> Message-ID: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: > > On 12/03/2015 06:01 PM, Mandy Chung wrote: >>> On Dec 3, 2015, at 5:01 AM, Peter Levart >>> wrote: >>> >>> I would only rephrase this statement in package-info.java a bit: >>> >>> 96 * Soft and weak references are automatically cleared by the collector >>> 97 * before being added to the queues with which they are registered, if any, >>> 98 * hence they need not be registered with a queue in order to be useful. >>> 99 * Phantom references, by contrast, do not allow their referents to be >>> 100 * retrieved, so they must be registered with a queue. >>> >> Kim brought up the potential confusion on the above wordings. [?] >> >> *

Automatically-cleared references

>> * >> - * Soft and weak references are automatically cleared by the collector >> - * before being added to the queues with which they are registered, if >> - * any. Therefore soft and weak references need not be registered >> - * with a queue in order to be useful, while phantom references do. >> - * An object that is reachable via phantom references will remain so >> - * until all such references are cleared or themselves become >> - * unreachable. >> + * References are automatically cleared by the collector before being >> + * added to the queues with which they are registered, if any. >> + * Soft and weak references allow their referents to be retrieved, >> + * hence they need not be registered with a queue in order to be useful. >> + * Phantom references, by contrast, do not allow their referents to be >> + * retrieved, so they must be registered with a queue. >> > > Or: > > ..., so they are only useful if they are registered with a queue. Drawing on the various suggestions so far, how about this: ----- Soft, weak, and phantom references are automatically cleared by the collector before being added to the queues with which they are registered, if any. Soft and weak references allow access to the referent before they are cleared, and hence need not be registered with a queue in order to be useful. Phantom references, by contrast, prevent access to the referent, so they are only useful when registered with a queue. ----- I prefer the explicit list in the opening sentence, rather than collapsing that to just "References", to avoid any possible confusion that this might apply to (the internal and undocumented, but visible in the code) FinalReference. I included a serial comma in the list; I generally prefer that usage, and it's consistent with earlier usage on the same page. In the final sentence, I prefer to avoid the use of "must", especially without any "to be useful" qualification, as that sounds like it might be a formal requirement, and that would be inconsistent with the PhantomReference constructor documentation. The second sentence (about soft and weak references) could be deleted, along with the "by contrast" phrase in the third, without loss of information. It does save the reader a bit of inference though. [Indeed, this whole section isn't strictly necessary; all of it can be inferred from information in other places.] From kim.barrett at oracle.com Thu Dec 3 22:52:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Dec 2015 17:52:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56603D28.6040206@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> Message-ID: <074EE4DF-17FB-46D1-B2C7-33E868E8DEC7@oracle.com> On Dec 3, 2015, at 8:01 AM, Peter Levart wrote: > > Hi Kim, > > Kudos for finding an observable change in behavior. Although the specification could also be read in a way so that this would not be observable. Originally it states: > > "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable." > > I read this as: "... An object that is reachable via phantom references will remain phantom reachable ..." > > If phantom-reachable objects have links among them, this doesn't make them strongly reachable. > > So I would argue that when both roots to O1 and O2 (in the test) are finally removed, O1 and O2 should be considered phantom-reachable, regardless of the link from O1 -> O2. When root to O2 is removed before the 2nd GC round, P2 should be notified as O2 transitions from reachable -> phantom reachable. This is no different from the situation when both roots to O1 and O2 are removed at the same time before a GC round: both P1 and P2 are notified. I don't think that reading is correct. Consider the case of R being a weak (not phantom) reference. In that case, X can never be "phantom reachable", because the definition of that state includes "some phantom reference refers to it". If, in the scenario described, the reference from O to X did not prevent (the weak) R from being cleared and notified, the special rule for phantom references would have no visible impact. In which case we wouldn't need to change the specification; we could just change the implementation and claim there was no specified visible difference. From Peter.B.Kessler at Oracle.COM Thu Dec 3 22:59:04 2015 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 03 Dec 2015 14:59:04 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: <5660C938.7030309@Oracle.COM> On 12/ 3/15 02:33 PM, Kim Barrett wrote: > On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: >> >> On 12/03/2015 06:01 PM, Mandy Chung wrote: >>>> On Dec 3, 2015, at 5:01 AM, Peter Levart >>>> wrote: >>>> >>>> I would only rephrase this statement in package-info.java a bit: >>>> >>>> 96 * Soft and weak references are automatically cleared by the collector >>>> 97 * before being added to the queues with which they are registered, if any, >>>> 98 * hence they need not be registered with a queue in order to be useful. >>>> 99 * Phantom references, by contrast, do not allow their referents to be >>>> 100 * retrieved, so they must be registered with a queue. >>>> >>> Kim brought up the potential confusion on the above wordings. [?] >>> >>> *

Automatically-cleared references

>>> * >>> - * Soft and weak references are automatically cleared by the collector >>> - * before being added to the queues with which they are registered, if >>> - * any. Therefore soft and weak references need not be registered >>> - * with a queue in order to be useful, while phantom references do. >>> - * An object that is reachable via phantom references will remain so >>> - * until all such references are cleared or themselves become >>> - * unreachable. >>> + * References are automatically cleared by the collector before being >>> + * added to the queues with which they are registered, if any. >>> + * Soft and weak references allow their referents to be retrieved, >>> + * hence they need not be registered with a queue in order to be useful. >>> + * Phantom references, by contrast, do not allow their referents to be >>> + * retrieved, so they must be registered with a queue. >>> >> >> Or: >> >> ..., so they are only useful if they are registered with a queue. > > Drawing on the various suggestions so far, how about this: > > ----- > > Soft, weak, and phantom references are automatically cleared by the > collector before being added to the queues with which they are > registered, if any. Soft and weak references allow access to the > referent before they are cleared, and hence need not be registered > with a queue in order to be useful. Phantom references, by contrast, > prevent access to the referent, so they are only useful when > registered with a queue. > > ----- > > I prefer the explicit list in the opening sentence, rather than > collapsing that to just "References", to avoid any possible confusion > that this might apply to (the internal and undocumented, but visible > in the code) FinalReference. > > I included a serial comma in the list; I generally prefer that usage, > and it's consistent with earlier usage on the same page. > > In the final sentence, I prefer to avoid the use of "must", especially > without any "to be useful" qualification, as that sounds like it might > be a formal requirement, and that would be inconsistent with the > PhantomReference constructor documentation. > > The second sentence (about soft and weak references) could be deleted, > along with the "by contrast" phrase in the third, without loss of > information. It does save the reader a bit of inference though. In a paragraph about when references are cleared and queued, the important point is that you can tell whether the referent of a soft or weak reference is no longer reachable either by testing whether get() returns null, or by polling the queue for the reference. In contrast, phantom references always return null from get(), so to determine if the referent is no longer reachable, you have to look at the queue with which the phantom reference was registered. ... peter > > [Indeed, this whole section isn't strictly necessary; all of it can be > inferred from information in other places.] From mandy.chung at oracle.com Thu Dec 3 23:04:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 15:04:22 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: > On Dec 3, 2015, at 2:33 PM, Kim Barrett wrote: > > I prefer the explicit list in the opening sentence, rather than > collapsing that to just "References", to avoid any possible confusion > that this might apply to (the internal and undocumented, but visible > in the code) FinalReference. The explicit list was what I tried to avoid as it?s repeated in the other sentences. FinalReference is not part of java.lang.ref spec and I don?t think it could cause any confusion. > > I included a serial comma in the list; I generally prefer that usage, > and it's consistent with earlier usage on the same page. > > In the final sentence, I prefer to avoid the use of "must", especially > without any "to be useful" qualification, as that sounds like it might > be a formal requirement, and that would be inconsistent with the > PhantomReference constructor documentation. > > The second sentence (about soft and weak references) could be deleted, > along with the "by contrast" phrase in the third, without loss of > information. It does save the reader a bit of inference though. > > [Indeed, this whole section isn't strictly necessary; all of it can be > inferred from information in other places.] Agree. This section is no longer necessary and maybe just remove it: --- a/src/java.base/share/classes/java/lang/ref/package-info.java +++ b/src/java.base/share/classes/java/lang/ref/package-info.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2015, 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 @@ -43,8 +43,7 @@ * implementing memory-sensitive caches, weak references are for * implementing canonicalizing mappings that do not prevent their keys * (or values) from being reclaimed, and phantom references are for - * scheduling pre-mortem cleanup actions in a more flexible way than - * is possible with the Java finalization mechanism. + * scheduling post-mortem cleanup actions. * *

Each reference-object type is implemented by a subclass of the * abstract base {@link java.lang.ref.Reference} class. @@ -64,9 +63,9 @@ * object with a reference queue at the time the reference * object is created. Some time after the garbage collector * determines that the reachability of the referent has changed to the - * value corresponding to the type of the reference, it will add the - * reference to the associated queue. At this point, the reference is - * considered to be enqueued. The program may remove + * value corresponding to the type of the reference, it will clear the + * reference and add it to the associated queue. At this point, the + * reference is considered to be enqueued. The program may remove * references from a queue either by polling or by blocking until a * reference becomes available. Reference queues are implemented by * the {@link java.lang.ref.ReferenceQueue} class. @@ -92,16 +91,6 @@ * structure, this check will add little overhead to the hashtable * access methods. * - *

Automatically-cleared references

- * - * Soft and weak references are automatically cleared by the collector - * before being added to the queues with which they are registered, if - * any. Therefore soft and weak references need not be registered - * with a queue in order to be useful, while phantom references do. - * An object that is reachable via phantom references will remain so - * until all such references are cleared or themselves become - * unreachable. - * * *

Reachability

* Mandy From brian.burkhalter at oracle.com Fri Dec 4 00:23:24 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Dec 2015 16:23:24 -0800 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException Message-ID: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8143394 Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/ The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ?false? but before the variable ?buf? was dereferenced at line 87. The fix is to change close() to use the ?lock? variable as in the other methods. Similar problems were found to exist in CharArrayReader and StringReader. The test reliably reproduces the NPE in all three classes with the NPE in PushbackReader being reproduced frequently and the NPE in the other classes less so. Thanks, Brian From aleksej.efimov at oracle.com Fri Dec 4 00:25:54 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 4 Dec 2015 03:25:54 +0300 Subject: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518 Message-ID: <5660DD92.8070506@oracle.com> Hi, Please, help to review and approve JDK-8133924 backport to JDK8. The source fix is identical to JDK9 changes, but there was no test added for this issue in JDK9. The existing jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test was modified to test the reported problem in JDK8 and it is a subject of review: http://cr.openjdk.java.net/~aefimov/8133924/8/00 No regression tests failures were observed for the proposed fix in JDK8 + the fix is in JDK9 for 3 months already. With Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8133924 JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 JDK9 Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html From stuart.marks at oracle.com Fri Dec 4 00:58:00 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 3 Dec 2015 16:58:00 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <565E590D.3090007@oracle.com> References: <565E590D.3090007@oracle.com> Message-ID: <5660E518.4040705@oracle.com> Small refresh here: after some consultation with Brian Goetz and John Rose, I've updated the class doc text covers immutability and value-based. They now say, * They are structurally immutable. Elements cannot be added, removed, or replaced. Attempts to do so result in UnsupportedOperationException. However, if the contained elements are themselves mutable, this may cause the List's contents to appear to change. [and similar for Set and Map] * They are value-based. Callers should make no assumptions about the identity of the returned instances. Factories are free to create new instances or reuse existing ones. Therefore, identity-sensitive operations on these instances (reference equality (==), identity hash code, and synchronization) are unreliable and should be avoided. -- I still need an official OpenJDK Reviewer. -- API: http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ Thanks, s'marks On 12/1/15 6:35 PM, Stuart Marks wrote: > Hi all, > > Thanks for the previous round of review comments. Here's an updated API and > implementation for review. > > I've run specdiff with the --hu ("hide unchanged") option, so only the bits of > the specification that have changed are shown. As before, though, please ignore > the spurious change to EnumSet caused by a javadoc bug. > > API changes: > - add clarifying notes on immutability > - remove wording that implied creation of new objects > - add "value-based" disclaimers > - add ordering specification for List and non-ordering disclaimers > for Set and Map > - clarify that Map.ofEntries() doesn't store the Map.Entry objects, instead > it extracts keys and values > - Map.Entry instances returned from Map.entry() are *not* serializable > > Other: > - markup cleanups > - small implementation cleanups > > JEP: > > http://openjdk.java.net/jeps/269 > > API spec (basically List, Map, and Set): > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html > > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ > > Thanks, > > s'marks From kumar.x.srinivasan at oracle.com Fri Dec 4 01:04:22 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 03 Dec 2015 17:04:22 -0800 Subject: 8144660: VersionCheck.java fails when it tries to run jaccess*.exe -J-version on windows Message-ID: <5660E696.1030900@oracle.com> Hello, This is a change to ignore these binaries in the bin directory, which causes the test to fail, as these are GUI applications. Appreciate a quick reviewn. Please review. Thanks # HG changeset patch # Parent 8ef2bf79539ca446bd14505705cdf208dc2644cc diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -47,6 +47,10 @@ "java-rmi.cgi", "java", "javacpl", + "jaccessinspector", + "jaccessinspector-32", + "jaccesswalker", + "jaccesswalker-32", "javaw", "javaws", "jcontrol", @@ -64,6 +68,10 @@ static final String[] BLACKLIST_VERSION = { "appletviewer", "controlpanel", + "jaccessinspector", + "jaccessinspector-32", + "jaccesswalker", + "jaccesswalker-32", "jar", "jarsigner", "java-rmi", From sundararajan.athijegannathan at oracle.com Fri Dec 4 01:41:49 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 4 Dec 2015 07:11:49 +0530 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <566062D9.4020907@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> Message-ID: <5660EF5D.9040000@oracle.com> Hi, Thanks. Updated: http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ Thanks, -Sundar On 12/3/2015 9:12 PM, Alan Bateman wrote: > > > On 03/12/2015 15:06, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143404 >> Webrev: http://cr.openjdk.java.net/~sundar/8143404/webrev.00/ >> >> Apple script engine implementing javax.script engine API is being >> removed. AppleScript engine has flip flopped between working and >> broken many times.The services configuration (META-INF/services) file >> was missing and only worked by accident when installing JDK 7 or JDK >> 8 on systems that had Apple's version of AppleScriptEngine.jar >> already on the system. So, it is removed for jdk 9. > There are few references to these classes/directories that will need > to be cleaned up too. I see on in the langtools repo, another in the > top-level repo in the unshuffle_list.txt. > > -Alan. From mandy.chung at oracle.com Fri Dec 4 01:43:59 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 17:43:59 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5660B1F9.6090305@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> Message-ID: > On Dec 3, 2015, at 1:19 PM, Roger Riggs wrote: > > [1] http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > [2] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ The implementation looks good. I?ll wait for an updated javadoc and re-review that incorporates the editorial comments that Mark made. Some additional comments: - null should be {@code null} 150 * Refer to the API Note above for cautions about the behavior 151 * of cleaning functions. It may be good to add a link back to the API note. 76 * and not block. If the cleaning function blocks it may delay processing - should there be ?,? before ?it?? 77 * other cleaning functions using the same Cleaner. 78 * All cleaning functions using a Cleaner should be mutually compatible. - ?using a cleaner? - should the terminology be ?registered in a cleaner? consistent with other references in the spec? 104 * The thread sets the ThreadContextClassLoader to the system class loader, 105 * sets the AccessControlContext to an empty ProtectionDomain, 106 * clears ThreadLocals, and sets the thread to be a 107 * {@link Thread#setDaemon(boolean) daemon thread}. I think clearing thread locals may not need to be mentioned. Below is one suggestion to rephrase the above. Similarly can be applied to the thread factory variant. * The thread is a {@linkplain Thread#isDaemon() daemon thread}. * The thread's {@linkplain Thread#getContextClassLoader context class loader} * is set to {@linkplain ClassLoader#getSystemClassLoader() system class loader}. * The thread has no permission to access any security operation. Minor comment on the CleanerTest.java: 530 // unless it is know this case throws an exception, rethrow typo: s/know/known It would be better to rename the test[1-5] methods to reflect what it verifies. 254 Reference r = queue.remove(); Minor one: remove(long timeout) may be a better option while in practice remove() will not block forever. Mandy From mandy.chung at oracle.com Fri Dec 4 03:31:46 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 19:31:46 -0800 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <5660EF5D.9040000@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> Message-ID: <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> > On Dec 3, 2015, at 5:41 PM, Sundararajan Athijegannathan wrote: > > Hi, > > Thanks. Updated: > > http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ > http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ > http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ > jdk/src/jdk.deploy.osx/macosx/native/libapplescriptengine - jdk webrev didn?t show they are removed. jdk/make/lib/Lib-jdk.deploy.osx.gmk unshuffle_list.txt 1296 jdk/src/jdk.deploy.osx/macosx/classes/apple/security : jdk/src/macosx/classes/apple/security since you are on this file, do you mind taking out this line as well (which was a leftover from the changeset when moving out the apple security provider to java.abs). modules.xml I believe this should be updated as well and jdk.deploy.osx dependency on java.desktop and java.scripting can be removed. I notice that there are qualified exports from sun.misc to jdk.deploy.osx that looks like they are not needed. Run jdeps on $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.osx from your build will show the new dependency. It?d be good to clean this up but this is not related to this change. It?s okay with me either way. Mandy From sundararajan.athijegannathan at oracle.com Fri Dec 4 04:35:17 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 4 Dec 2015 10:05:17 +0530 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> Message-ID: <56611805.4030405@oracle.com> I'm only removing applescript code. Not all of jdk.deploy.osx code (collection etc). Not sure if jdk.deploy.osx dependencies can be completely removed (yet). Removal of the other stuff has to be another bug. I'll update for other stuff you mentioned. -Sundar On 12/4/2015 9:01 AM, Mandy Chung wrote: >> On Dec 3, 2015, at 5:41 PM, Sundararajan Athijegannathan wrote: >> >> Hi, >> >> Thanks. Updated: >> >> http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ >> http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ >> http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ >> > jdk/src/jdk.deploy.osx/macosx/native/libapplescriptengine > - jdk webrev didn?t show they are removed. > > jdk/make/lib/Lib-jdk.deploy.osx.gmk > > unshuffle_list.txt > 1296 jdk/src/jdk.deploy.osx/macosx/classes/apple/security : jdk/src/macosx/classes/apple/security > > since you are on this file, do you mind taking out this line as well (which was a leftover from the changeset when moving out the apple security provider to java.abs). > > modules.xml > > I believe this should be updated as well and jdk.deploy.osx dependency on java.desktop and java.scripting can be removed. > > I notice that there are qualified exports from sun.misc to jdk.deploy.osx that looks like they are not needed. Run jdeps on $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.osx from your build will show the new dependency. It?d be good to clean this up but this is not related to this change. It?s okay with me either way. > > Mandy From joe.darcy at oracle.com Fri Dec 4 06:03:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 3 Dec 2015 22:03:54 -0800 Subject: 8144660: VersionCheck.java fails when it tries to run jaccess*.exe -J-version on windows In-Reply-To: <5660E696.1030900@oracle.com> References: <5660E696.1030900@oracle.com> Message-ID: <56612CCA.5060703@oracle.com> Looks fine Kumar; thanks, -Joe On 12/3/2015 5:04 PM, Kumar Srinivasan wrote: > Hello, > > This is a change to ignore these binaries in the bin directory, which > causes the test to fail, as these are GUI applications. Appreciate a > quick reviewn. > > Please review. > Thanks > > # HG changeset patch > # Parent 8ef2bf79539ca446bd14505705cdf208dc2644cc > > diff --git a/test/tools/launcher/VersionCheck.java > b/test/tools/launcher/VersionCheck.java > --- a/test/tools/launcher/VersionCheck.java > +++ b/test/tools/launcher/VersionCheck.java > @@ -47,6 +47,10 @@ > "java-rmi.cgi", > "java", > "javacpl", > + "jaccessinspector", > + "jaccessinspector-32", > + "jaccesswalker", > + "jaccesswalker-32", > "javaw", > "javaws", > "jcontrol", > @@ -64,6 +68,10 @@ > static final String[] BLACKLIST_VERSION = { > "appletviewer", > "controlpanel", > + "jaccessinspector", > + "jaccessinspector-32", > + "jaccesswalker", > + "jaccesswalker-32", > "jar", > "jarsigner", > "java-rmi", > From mandy.chung at oracle.com Fri Dec 4 06:42:03 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Dec 2015 22:42:03 -0800 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <56611805.4030405@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> <56611805.4030405@oracle.com> Message-ID: Right. Run this on your repo after removing applescript $ jdeps $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.os You will see the dependency. It?s okay to remain the qualified exports. But you should remove the dependency on java.desktop and java.scripting. >> jdk/make/lib/Lib-jdk.deploy.osx.gmk I assume libapplescriptengine should be removed too. So this makefile needs update too. Mandy > On Dec 3, 2015, at 8:35 PM, Sundararajan Athijegannathan wrote: > > I'm only removing applescript code. Not all of jdk.deploy.osx code (collection etc). Not sure if jdk.deploy.osx dependencies can be completely removed (yet). Removal of the other stuff has to be another bug. I'll update for other stuff you mentioned. > > -Sundar > > On 12/4/2015 9:01 AM, Mandy Chung wrote: >>> On Dec 3, 2015, at 5:41 PM, Sundararajan Athijegannathan wrote: >>> >>> Hi, >>> >>> Thanks. Updated: >>> >>> http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ >>> http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ >>> http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ >>> >> jdk/src/jdk.deploy.osx/macosx/native/libapplescriptengine >> - jdk webrev didn?t show they are removed. >> >> jdk/make/lib/Lib-jdk.deploy.osx.gmk >> >> unshuffle_list.txt >> 1296 jdk/src/jdk.deploy.osx/macosx/classes/apple/security : jdk/src/macosx/classes/apple/security >> >> since you are on this file, do you mind taking out this line as well (which was a leftover from the changeset when moving out the apple security provider to java.abs). >> >> modules.xml >> >> I believe this should be updated as well and jdk.deploy.osx dependency on java.desktop and java.scripting can be removed. >> >> I notice that there are qualified exports from sun.misc to jdk.deploy.osx that looks like they are not needed. Run jdeps on $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.osx from your build will show the new dependency. It?d be good to clean this up but this is not related to this change. It?s okay with me either way. >> >> Mandy > From per.liden at oracle.com Fri Dec 4 07:16:36 2015 From: per.liden at oracle.com (Per Liden) Date: Fri, 4 Dec 2015 08:16:36 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> Message-ID: <56613DD4.40600@oracle.com> Hi Kim, On 2015-12-02 19:37, Kim Barrett wrote: > Please review this change to PhantomReference processing, changing the > GC-based notification to automatically clear the referent. > > This change provides performance benefits by eliminating the work > involved in keeping the otherwise inaccessible referent objects alive, > as required by the existing specification. This not only immediately > removes some work, but may enable further performance improvements. > It also allows the referent objects to be immediately reclaimed in > the GC cycle in which they were determined to be inaccessible, rather > than lingering as a form of floating garbage until the application > deals with the notified reference. > > This change results in a behavioral change to application code, as > demonstrated by the associated test. Under the old specification, a > reference R with referent X may be kept alive because it is referenced > by an otherwise inaccessible referent Y of phantom reference P. This > will result in X being treated as strongly referenced and prevent R > from being notified, even if R is a phantom reference and X has become > inaccessible to the application. With this change, Y is reclaimed > when it becomes inaccessible and P is notified, and no longer prevents > X from itself becoming a candidate for reclaimation once it is no > longer accessible to the application. While this is a change in > behavior, it seems unlikely to affect applications negatively. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8071507 > > Webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ test/java/lang/ref/PhantomReferentClearing.java: 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. 86 O1 = null; 87 System.gc(); 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { 89 throw new RuntimeException("P1 not notified by O1 deletion"); 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { 91 throw new RuntimeException("P2 notified by O1 deletion."); 92 } 93 94 // Delete root -> O2, collect. P2 should be notified. 95 O2 = null; 96 System.gc(); 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { 98 throw new RuntimeException("P2 not notified by O2 deletion"); 99 } The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. cheers, /Per > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ > > Testing: > jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) > From patrick at reini.net Fri Dec 4 07:40:36 2015 From: patrick at reini.net (patrick at reini.net) Date: Fri, 04 Dec 2015 08:40:36 +0100 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5660E518.4040705@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <922b091ba51357d50d6ebc3168a58d31@reini.net> It may be discussed already but based on the definition as you just changed, would it make sense to have a way to create such a Set/List/Map based on a existing mutable implementation? We use a the builder pattern a lot to create immutable objects that get serialized later. At the moment we have to do the following in order to decouple the builders actual set content in case the builder is re-used: Set immutable = Collections.unmodifiableSet(new HashSet<>(builderSet))); Instead of may be using: Set immutable = Set.of(builderSet); The same pattern would also apply to List/Map - Patrick On 2015-12-04 01:58, Stuart Marks wrote: > Small refresh here: after some consultation with Brian Goetz and John > Rose, I've updated the class doc text covers immutability and > value-based. They now say, > > * They are structurally immutable. Elements cannot be added, > removed, or replaced. Attempts to do so result in > UnsupportedOperationException. However, if the contained elements are > themselves mutable, this may cause the List's contents to appear to > change. > > [and similar for Set and Map] > > * They are value-based. Callers should make no assumptions about the > identity of the returned instances. Factories are free to create new > instances or reuse existing ones. Therefore, identity-sensitive > operations on these instances (reference equality (==), identity hash > code, and synchronization) are unreliable and should be avoided. > > -- > From daniel.fuchs at oracle.com Fri Dec 4 08:48:20 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Dec 2015 09:48:20 +0100 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> Message-ID: <56615354.3080900@oracle.com> Hi Brian, The fix looks good to me! Good that you were able to find these other classes where the same issue appeared. I see that FilterReader.close() calls in.close(). Hopefully wrapping this call (from PushbackReader) in a synchronized(lock) block won't be an issue. I wonder if: 248 public void close() throws IOException { 249 synchronized (lock) { 250 buf = null; 251 } 252 super.close(); 253 } would be a safer implementation. I don't know the java.io code in depth - so that's just a question... The only other possible issue I spotted is in the test: Because readers[0] is set by one thread and read by both then using an array without synchronization is not thread safe. I would advise using an AtomicReference instead. Best regards, -- daniel On 12/4/15 1:23 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8143394 > Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/ > > The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ?false? but before the variable ?buf? was dereferenced at line 87. The fix is to change close() to use the ?lock? variable as in the other methods. Similar problems were found to exist in CharArrayReader and StringReader. The test reliably reproduces the NPE in all three classes with the NPE in PushbackReader being reproduced frequently and the NPE in the other classes less so. > > Thanks, > > Brian From paul.sandoz at oracle.com Fri Dec 4 09:30:37 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Dec 2015 10:30:37 +0100 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5660E518.4040705@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <5EDB8CD3-136D-43F5-86AA-278ACD879F0B@oracle.com> > On 4 Dec 2015, at 01:58, Stuart Marks wrote: > > Small refresh here: after some consultation with Brian Goetz and John Rose, I've updated the class doc text covers immutability and value-based. They now say, > > * They are structurally immutable. Elements cannot be added, removed, or replaced. Attempts to do so result in UnsupportedOperationException. However, if the contained elements are themselves mutable, this may cause the List's contents to appear to change. > > [and similar for Set and Map] > > * They are value-based. Callers should make no assumptions about the identity of the returned instances. Factories are free to create new instances or reuse existing ones. Therefore, identity-sensitive operations on these instances (reference equality (==), identity hash code, and synchronization) are unreliable and should be avoided. > > -- > > I still need an official OpenJDK Reviewer. > +1 This is purely a suggestion, take it or leave it: you could use a static import for Objects.requireNonNull, that makes the current code marginally easier on the eyes (i know this area is likely to change). List/Set/Map/MOAT ? Update the license header date to 2015. Map ? 1689 * The key and the value must not be null. Calling {@link Entry#setValue Entry.setValue()} s/null/{@code null} Paul. From aph at redhat.com Fri Dec 4 09:48:38 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Dec 2015 09:48:38 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5A7F25D7-02BC-44DE-BAF3-4AD941439C3F@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <5654A2B0.7090007@Oracle.com> <56559EA6.9020806@redhat.com> <20151203133502.741773@eggemoggin.niobe.net> <5A7F25D7-02BC-44DE-BAF3-4AD941439C3F@oracle.com> Message-ID: <56616176.1050709@redhat.com> On 03/12/15 21:47, John Rose wrote: > We are takeing a crack at it with Panama, since using C APIs > often requires timely deallocation of (non-Java) temps. Indeed it does, and I guess I'll wait. I'm a bit disappointed because I quite fancied trying to do mapped ByteBuffer.close(). While I could hold off and wait for your more ambitious solution, I wonder if it makes more sense for me to do something anyway. Some big data people seem to be suffering with this problem, so a solution to just ByteBuffers might be more timely than Panama. Andrew. From scolebourne at joda.org Fri Dec 4 09:50:47 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 4 Dec 2015 09:50:47 +0000 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5660E518.4040705@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: Sorry for my delayed review. Basically, I'm happy with this. Some oddments: Map.ofEntries(Entry...) "The entry objects themselves are not stored in the map." This seems wrong. `Entry` might be implemented as a value, not an object in the future. And if so, it might form part of the state of an optimised list implementation. The use of looks like it should have an extra space after the comma to me. I prefer to avoid apostrophes in docs "the map's key type" -> "the key type of the map" "the first mapping's key" -> "the key of the first mapping" I note that java.util.Stream uses empty() but this API uses of() for the empty case. I can see both points of view and don't have much of a preference. Is consistency with Stream needed? KeyValueHolder needs a

at line 41 thanks Stephen On 4 December 2015 at 00:58, Stuart Marks wrote: > Small refresh here: after some consultation with Brian Goetz and John Rose, > I've updated the class doc text covers immutability and value-based. They > now say, > > * They are structurally immutable. Elements cannot be added, removed, or > replaced. Attempts to do so result in UnsupportedOperationException. > However, if the contained elements are themselves mutable, this may cause > the List's contents to appear to change. > > [and similar for Set and Map] > > * They are value-based. Callers should make no assumptions about the > identity of the returned instances. Factories are free to create new > instances or reuse existing ones. Therefore, identity-sensitive operations > on these instances (reference equality (==), identity hash code, and > synchronization) are unreliable and should be avoided. > > -- > > I still need an official OpenJDK Reviewer. > > -- > > API: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ > > Thanks, > > s'marks > > > On 12/1/15 6:35 PM, Stuart Marks wrote: >> >> Hi all, >> >> Thanks for the previous round of review comments. Here's an updated API >> and >> implementation for review. >> >> I've run specdiff with the --hu ("hide unchanged") option, so only the >> bits of >> the specification that have changed are shown. As before, though, please >> ignore >> the spurious change to EnumSet caused by a javadoc bug. >> >> API changes: >> - add clarifying notes on immutability >> - remove wording that implied creation of new objects >> - add "value-based" disclaimers >> - add ordering specification for List and non-ordering disclaimers >> for Set and Map >> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >> instead >> it extracts keys and values >> - Map.Entry instances returned from Map.entry() are *not* serializable >> >> Other: >> - markup cleanups >> - small implementation cleanups >> >> JEP: >> >> http://openjdk.java.net/jeps/269 >> >> API spec (basically List, Map, and Set): >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >> >> Specdiff: >> >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >> >> Thanks, >> >> s'marks From nadeesh.tv at oracle.com Fri Dec 4 11:04:31 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 04 Dec 2015 16:34:31 +0530 Subject: RFR: JDK-8142936:Additional java.time.Duration methods In-Reply-To: <5660B72A.1010805@oracle.com> References: <5656A9A5.6050409@oracle.com> <565C3252.4030800@oracle.com> <565C9D4D.4020800@oracle.com> <56608165.5020300@oracle.com> <5660B72A.1010805@oracle.com> Message-ID: <5661733F.3060009@oracle.com> Hi , Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8142936/webrev.04/ Thanks and Regards, Nadeesh On 12/4/2015 3:12 AM, Roger Riggs wrote: > Hi Nadeesh, > > Thanks for the update, sorry I missed some editorial comments last time. > > toSeconds method missing a final period '.' > "* This returns the total number of seconds in the duration" > toMinutesPart method: Extra text: > + * @return the number of minutes parts in the duration, may be negative > + * @since 9 > *+ * may be negative* > + */ > + public int toMinutesPart(){ > > > Missing space in multiple places: "(){" should have a space before "{" > > > toMillisPart and toNanosPart methods: unneeded description: > "+ * The total duration is defined by calling {@link #getNano()} and > {@link #getSeconds()}." > > toMillisPart method: remove the final "."; it should be omitted on > @return, @param > "+ * @return the number of milliseconds part of the duration." > > Thanks for coalescing the data providers. > > Roger > > > > On 12/03/2015 12:52 PM, nadeesh tv wrote: >> Hi all, >> >> Please see the updated webrev - >> http://cr.openjdk.java.net/~ntv/8142936/webrev.03/ >> - changes - Modified the dataprovider as suggested by Roger >> >> Thanks and regards, >> Nadeesh >> >> >> On 12/1/2015 2:39 AM, Stephen Colebourne wrote: >>> This is all about fixing a messy API that was created in 8. The >>> methods propose are all about consistency. The toSeconds() method >>> completes the set. For each unit there is a toXxx() and a toXxxPart(). >>> Missing one out makes everything worse. >>> >>> Stephen >>> >>> >>> On 30 November 2015 at 19:02, Roger Riggs >>> wrote: >>>> Hi Stephen, Nadeesh, >>>> >>>> The toXXXPart methods look fine. >>>> >>>> I'm not entirely convinced that the toSeconds() method is worth it >>>> and may >>>> be >>>> deemed as confusing with the new toSecondsPart method. >>>> How many people have problems with getSeconds()? >>>> >>>> The toXXXPart tests could have used a single DataProvider with >>>> the values supplied for each unit to reduce the duplication. >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> >>>> >>>> On 11/30/2015 09:29 AM, Stephen Colebourne wrote: >>>>> I think thats ready to be merged, thanks >>>>> Stephen >>>>> >>>>> On 30 November 2015 at 11:26, nadeesh tv >>>>> wrote: >>>>>> Hi all, >>>>>> Please see the updated webrev >>>>>> http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ >>>>>> Regards, >>>>>> Nadeesh TV >>>>>> >>>>>> On 11/27/2015 11:20 PM, Stephen Colebourne wrote: >>>>>>> "Overall, looks pretty good. >>>>>>> >>>>>>> There a a number of double spaces that should be single spaces >>>>>>> in the >>>>>>> Javadoc. >>>>>>> >>>>>>> Change >>>>>>> "This is based on the standard definition of a day has 24 hours." >>>>>>> to >>>>>>> "This is based on the standard definition of a day as 24 hours." >>>>>>> ("has" to "as") >>>>>>> There are three places to fix this. >>>>>>> >>>>>>> The toMillisPart() docs could do with some rework. >>>>>>> change >>>>>>> "number of milliseconds part in the nanosecond part of the >>>>>>> duration" >>>>>>> to >>>>>>> "number of milliseconds part of the duration" >>>>>>> >>>>>>> try this: >>>>>>> "This returns the milliseconds part by dividing the number of >>>>>>> nanoseconds by 1,000,000." >>>>>>> >>>>>>> On the tests. >>>>>>> >>>>>>> There is no test for toSeconds(). >>>>>>> >>>>>>> For the other tests, I have been bitten before by not testing edge >>>>>>> cases. >>>>>>> A test for zero, and for a negative round number would be good. >>>>>>> eg. for toHoursPart() the round number would be a duration of >>>>>>> exactly >>>>>>> minus 2 hours. >>>>>>> >>>>>>> Duration.ofHours(2).toDaysPart() = 0 >>>>>>> Duration.ofHours(2).toHoursPart() = 2 >>>>>>> Duration.ofHours(2).toMinutesPart() = 0 >>>>>>> Duration.ofHours(2).toSecondsPart() = 0 >>>>>>> Duration.ofHours(2).toMillisPart() = 0 >>>>>>> Duration.ofHours(2).toNanosPart() = 0 >>>>>>> >>>>>>> thus really six tests are needed each time. The best way to achieve >>>>>>> this is using @DataProvider in TestNG, where you can setup a >>>>>>> data grid >>>>>>> of inputs and 6 expected outputs. >>>>>>> >>>>>>> thanks >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 26 November 2015 at 06:41, nadeesh tv >>>>>>> wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a fix for >>>>>>>> >>>>>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8142936 >>>>>>>> >>>>>>>> -Enhance Duration by adding toNanosPart() , >>>>>>>> >>>>>>>> toMillisPart(),toSecondsPart(),toMinutesPart(),toHoursPart(),toDaysPart() >>>>>>>> >>>>>>>> methods . >>>>>>>> - Had to rename private BigDecimal toSeconds() -> >>>>>>>> private >>>>>>>> BigDecimal >>>>>>>> toBigDecimalSeconds() >>>>>>>> >>>>>>>> >>>>>>>> webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.01/ >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks and Regards, >>>>>>>> Nadeesh TV >>>>>>>>

>>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >> > -- Thanks and Regards, Nadeesh TV From Alan.Bateman at oracle.com Fri Dec 4 11:34:15 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Dec 2015 11:34:15 +0000 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> Message-ID: <56617A37.3070408@oracle.com> On 04/12/2015 00:23, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8143394 > Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/ > > The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ?false? but before the variable ?buf? was dereferenced at line 87. The fix is to change close() to use the ?lock? variable as in the other methods. Similar problems were found to exist in CharArrayReader and StringReader. The test reliably reproduces the NPE in all three classes with the NPE in PushbackReader being reproduced frequently and the NPE in the other classes less so. > I suspect this is going to need a spec update to make it clear that close will now block when there is another thread blocking on the reader. -Alan From daniel.fuchs at oracle.com Fri Dec 4 11:44:47 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Dec 2015 12:44:47 +0100 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <56615354.3080900@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56615354.3080900@oracle.com> Message-ID: <56617CAF.6090601@oracle.com> Hi Brian, On 12/4/15 9:48 AM, Daniel Fuchs wrote: > I wonder if: > 248 public void close() throws IOException { > 249 synchronized (lock) { > 250 buf = null; > 251 } > 252 super.close(); > 253 } > > would be a safer implementation. I don't know the java.io code > in depth - so that's just a question... Actually scratch that. I see that all other super methods are called from within the lock. So calling super.close() from within the same lock as well is probably safer - and what you have is good. best regards, -- daniel From peter.levart at gmail.com Fri Dec 4 12:35:18 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 13:35:18 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56613DD4.40600@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> Message-ID: <56618886.50309@gmail.com> On 12/04/2015 08:16 AM, Per Liden wrote: > > test/java/lang/ref/PhantomReferentClearing.java: > > 85 // Delete root -> O1, collect, verify P1 notified, P2 not > notified. > 86 O1 = null; > 87 System.gc(); > 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { > 89 throw new RuntimeException("P1 not notified by O1 > deletion"); > 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { > 91 throw new RuntimeException("P2 notified by O1 > deletion."); > 92 } > 93 > 94 // Delete root -> O2, collect. P2 should be notified. > 95 O2 = null; > 96 System.gc(); > 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { > 98 throw new RuntimeException("P2 not notified by O2 > deletion"); > 99 } > > The calls to System.gc() isn't guaranteed to do what the test expects > here. As you know, System.gc(), might not actually do anything, > depending on which collector is used and the current circumstances (GC > locker held, a concurrent GC is already in process, etc). To make the > test robust I'd suggest you call System.gc() and check the queue in a > loop, and fail after some reasonable amount of time/iterations. Whether you poll the queue for some time T or you remove from queue with timeout of T, it doesn't matter. The Reference(s) are enqueued by a ReferenceHandler thread and the thread waiting in remove() will get notified when a reference gets enqueued... Regards, Peter > > cheers, > /Per > >> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >> >> Testing: >> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >> From dl at cs.oswego.edu Fri Dec 4 13:46:24 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 4 Dec 2015 08:46:24 -0500 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <566009BA.50804@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> Message-ID: <56619930.8060100@cs.oswego.edu> On 12/03/2015 04:22 AM, Peter Levart wrote: > What about the 4th option (keep current behavior, but try the best-effort > with reflection to make new exception of the same type): We could do this, and if the attempt to clone fails, fall back to addSuppressed of the original exception. As in: } catch (Throwable ex) { if (x == null) x = ex; else if (x != ex) { Throwable cx = tryCloneException(x); if (cx != null) x = cx; x.addSuppressed(ex); } } Although considering the prospects for failure to clone (as also discussed by Jason), I'm still not sure it is worthwhile. Whenever code throws exceptions within exception handlers, the best you can do inside libraries is to be as informative as possible to developers, which was among the motivations for introducing addSuppressed. Given the choice of visibly (but safely) adding a suppressed exception while some other stage may be processing the primary exception (as in the current webrev), vs fallible reflection-based clone attempts with unknown side effects, I still think the former is likely to be best-behaved, but would not object to the mixed approach if we could come up with a reasonable implementation of tryCloneException. Also, could you explain... > > Note that such code and similar code in ForkJoinTask.getThrowableException > will probably have to be modified for jigsaw to include dynamic addition of > read-edge to the module of exception class... > -Doug From paul.sandoz at oracle.com Fri Dec 4 13:47:55 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Dec 2015 14:47:55 +0100 Subject: Reference.reachabilityFence In-Reply-To: <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> Message-ID: <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> > On 3 Dec 2015, at 22:33, Mandy Chung wrote: > > >> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: >> >> Hi, >> >> I have updated the patches: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ >> >> There is now more documentation on Reference (copied and suitable rearranged from 166 Fences.java). The method name remains the same. >> > > I think the addition to the Reference class specification should belong to the reachabilityFence method specification. Any reason why not? I thought it would be more visible in the JavaDoc, as it?s there upfront. The api note may get larger if we include some additional real world examples. I don?t have a strong opinion on this, if yours is stronger i will move it :-) > > I suggest to change this (occurs in the class spec and the method spec): > strongly reachable (as defined in the {@link java.lang.ref} package documentation), > > to > strongly reachable > Good point. I also linked to the referred section in the JLS. > Should the reachabilityFence method throw NPE if ref is null? > I am ok with it doing nothing, it?s a performance sensitive method. It means no null checks/de-opts are required and (hand-waving here...) might make it more amenable to optimization see https://bugs.openjdk.java.net/browse/JDK-8130398). Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ reachabilityFence is now annotated with @DontInline (to be pushed real soon now) and the HotSpot changes are no longer needed. Paul. From per.liden at oracle.com Fri Dec 4 14:17:25 2015 From: per.liden at oracle.com (Per Liden) Date: Fri, 4 Dec 2015 15:17:25 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56618886.50309@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <56618886.50309@gmail.com> Message-ID: <5661A075.9080602@oracle.com> Hi Peter, On 2015-12-04 13:35, Peter Levart wrote: > > > On 12/04/2015 08:16 AM, Per Liden wrote: >> >> test/java/lang/ref/PhantomReferentClearing.java: >> >> 85 // Delete root -> O1, collect, verify P1 notified, P2 not >> notified. >> 86 O1 = null; >> 87 System.gc(); >> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >> 89 throw new RuntimeException("P1 not notified by O1 >> deletion"); >> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >> 91 throw new RuntimeException("P2 notified by O1 >> deletion."); >> 92 } >> 93 >> 94 // Delete root -> O2, collect. P2 should be notified. >> 95 O2 = null; >> 96 System.gc(); >> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >> 98 throw new RuntimeException("P2 not notified by O2 >> deletion"); >> 99 } >> >> The calls to System.gc() isn't guaranteed to do what the test expects >> here. As you know, System.gc(), might not actually do anything, >> depending on which collector is used and the current circumstances (GC >> locker held, a concurrent GC is already in process, etc). To make the >> test robust I'd suggest you call System.gc() and check the queue in a >> loop, and fail after some reasonable amount of time/iterations. > > Whether you poll the queue for some time T or you remove from queue with > timeout of T, it doesn't matter. The Reference(s) are enqueued by a > ReferenceHandler thread and the thread waiting in remove() will get > notified when a reference gets enqueued... I think you maybe missed my point. There's no guarantee that a call to System.gc() will cause reference processing to happen at all, and if it happens there's no guarantee that it will discover P1/P2 here. In this specific test it's very likely to happen, but that's a different story. I still don't think this test should rely on a behavior that isn't guaranteed by the spec. cheers, /Per > > Regards, Peter > >> >> cheers, >> /Per >> >>> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >>> >>> Testing: >>> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >>> > From peter.levart at gmail.com Fri Dec 4 14:57:26 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 15:57:26 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56619930.8060100@cs.oswego.edu> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> <56619930.8060100@cs.oswego.edu> Message-ID: <5661A9D6.3000009@gmail.com> On 12/04/2015 02:46 PM, Doug Lea wrote: > Also, could you explain... > >> >> Note that such code and similar code in >> ForkJoinTask.getThrowableException >> will probably have to be modified for jigsaw to include dynamic >> addition of >> read-edge to the module of exception class... >> > > -Doug As jigsaw currently stands (but this might change before JDK9 ships), reflective access to class members (Class.newInstance(), [Method|Constructor].invoke(), Field.[get()|set()]) is governed by same access checks as bytecode instructions accessing those members, which means that: - the module doing access "must read" the module that the target class is declared in ("requires targetModule" in module-info of accessing module) - the package of the target class "must be exported" to at least the module doing the access ("exports targetPackage [to accessingModule]" in module-info of target module) - class/member access modifiers must allow access as normally classes in java.util.concurrent and sub-packages are part of java.base module, but exceptions that will be thrown in ForkJoinTask(s) and CompletableFuture actions can come from any module (a user module for example). - It is a responsibility of (user) modules to export exception types that they are throwing and which instances can escape to code of other modules. - java.base module does not (at startup) read any module, but read-edges can be added dynamically at runtime from the module adding the read-edge (self module) to any module (Module.addRead(Module) API). So before we can successfully invoke: exceptionClass.newInstance(); there would have to be something like: ThisClass.class.getModule().addRead(exceptionClass.getModule()); ...because we are invoking the constructor of the exceptionClass which might be declared in some other module (not java.base) which is not read by java.base by default. The solution with Throwable.clone() would not suffer from that, as the only type we would be dealing with is java.lang.Throwable (part of java.base). Regards, Peter From Roger.Riggs at Oracle.com Fri Dec 4 15:13:31 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 10:13:31 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <51B3A31E-ABBB-4E40-AE73-E5F7CD079014@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <51B3A31E-ABBB-4E40-AE73-E5F7CD079014@oracle.com> Message-ID: <5661AD9B.5010105@Oracle.com> Hi Kim, On 12/3/2015 5:29 PM, Kim Barrett wrote: > On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote: > ... >>> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >>> 237 /** >>> 238 * Returns true if the list's next reference refers to itself. >>> 239 * >>> 240 * @return true if the list is empty >>> 241 */ >>> 242 boolean isListEmpty() { >>> 243 PhantomCleanable list = cleanerImpl.phantomCleanableList; >>> 244 synchronized (list) { >>> 245 return next == list; >>> 246 } >>> 247 } >>> >>> Based on the description, one might expect some occurrence of "this" >>> in the body. This function must only be applied to the special head >>> sentinal, so a pre-condition is "list == this". Either an assert or >>> some mention of this would make this easier to understand. >>> >>> [Applies to all three of {Soft,Weak,Phantom}Cleanable.] >>> >> The implicit reference to 'this' is in via cleanerImpl. >> >> All of the functions insert, remove, isListEmpty need to lock on the list root >> and explicitly referring to the list root (via the clearerImpl) in each method >> keeps them aligned. >> IsListEmpty could be recoded to operate only on the distinguished root entry >> but it would be harder to see that the same lock is being used consistently. > I think that, as written, it would return true if applied to the last element of a > non-empty list. (That never happens at present.) If the test were > "list == list.next? that (potential) failure mode would be eliminated. That > would also make the code and the comment line up nicely, though the > comment would then be kind of redundant, as it doesn?t provide any > explanation for why that works. Your call. Good point, that would reduce some possible doubt. Will fix. Thanks, Roger > > So looks good to me. > > From peter.levart at gmail.com Fri Dec 4 15:24:50 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 16:24:50 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5661A075.9080602@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <56618886.50309@gmail.com> <5661A075.9080602@oracle.com> Message-ID: <5661B042.20704@gmail.com> On 12/04/2015 03:17 PM, Per Liden wrote: > Hi Peter, > > On 2015-12-04 13:35, Peter Levart wrote: >> >> >> On 12/04/2015 08:16 AM, Per Liden wrote: >>> >>> test/java/lang/ref/PhantomReferentClearing.java: >>> >>> 85 // Delete root -> O1, collect, verify P1 notified, P2 not >>> notified. >>> 86 O1 = null; >>> 87 System.gc(); >>> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >>> 89 throw new RuntimeException("P1 not notified by O1 >>> deletion"); >>> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >>> 91 throw new RuntimeException("P2 notified by O1 >>> deletion."); >>> 92 } >>> 93 >>> 94 // Delete root -> O2, collect. P2 should be notified. >>> 95 O2 = null; >>> 96 System.gc(); >>> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >>> 98 throw new RuntimeException("P2 not notified by O2 >>> deletion"); >>> 99 } >>> >>> The calls to System.gc() isn't guaranteed to do what the test expects >>> here. As you know, System.gc(), might not actually do anything, >>> depending on which collector is used and the current circumstances (GC >>> locker held, a concurrent GC is already in process, etc). To make the >>> test robust I'd suggest you call System.gc() and check the queue in a >>> loop, and fail after some reasonable amount of time/iterations. >> >> Whether you poll the queue for some time T or you remove from queue with >> timeout of T, it doesn't matter. The Reference(s) are enqueued by a >> ReferenceHandler thread and the thread waiting in remove() will get >> notified when a reference gets enqueued... > > I think you maybe missed my point. There's no guarantee that a call to > System.gc() will cause reference processing to happen at all, and if > it happens there's no guarantee that it will discover P1/P2 here. In > this specific test it's very likely to happen, but that's a different > story. I still don't think this test should rely on a behavior that > isn't guaranteed by the spec. Ah, you meant to call both System.gc() and queue.poll() in a loop. Sorry, I haven't understood you at first. I agree that would be better. Short of System.gc(), is there anything else that could be used to trigger GC processing more reliably? What about a loop that allocates until OOME is thrown and then releases everything so application can recover: static void triggerGC() { try { Object garbage = null; while(true) { Object[] chunk = new Object[1<<16]; chunk[0] = garbage; garbage = chunk; } } catch (OutOfMemoryError e) { // ignore } } I think most GCs guarantee they run the GC before VM throws OOME. Such test would have to be executed in othrevm with small heap: -Xmx16m or so... Regards, Peter > > cheers, > /Per > >> >> Regards, Peter >> >>> >>> cheers, >>> /Per >>> >>>> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ >>>> >>>> Testing: >>>> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK) >>>> >> From brian.burkhalter at oracle.com Fri Dec 4 16:21:38 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 4 Dec 2015 08:21:38 -0800 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <56617A37.3070408@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56617A37.3070408@oracle.com> Message-ID: <13730DF1-89B1-435A-8626-BC6E2D48DCFC@oracle.com> On Dec 4, 2015, at 3:34 AM, Alan Bateman wrote: > I suspect this is going to need a spec update to make it clear that close will now block when there is another thread blocking on the reader. Do you think that could be done for java.io.Reader.close() (?This method might block when another thread is blocking the Reader.?) or would be better on each of the specific methods (?This method will block when another thread is blocking the Reader.?)? Brian From claes.redestad at oracle.com Fri Dec 4 16:28:04 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Dec 2015 17:28:04 +0100 Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed Message-ID: <5661BF14.6070705@oracle.com> Hi, please review this issue to remove explicit initialization of MethodHandleImpl, which doesn't seem to be needed after recent j.l.invoke bootstrap improvements. Bug: https://bugs.openjdk.java.net/browse/JDK-8144723 Webrev: http://cr.openjdk.java.net/~redestad/8144723/webrev.01/ This removes 21 classes from jdk9/dev startup. I additionally identified a few eagerly initialized functions that can be made lazily initialized, which defers 6 classes from loading eagerly in startup tests that use lambdas explicitly. Thanks! /Claes From Roger.Riggs at Oracle.com Fri Dec 4 16:55:50 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 11:55:50 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <20151203135022.165903@eggemoggin.niobe.net> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> <20151203135022.165903@eggemoggin.niobe.net> Message-ID: <5661C596.1070801@Oracle.com> Hi, Thanks for the review and comments. The webrev[1] and javadoc[2] are updated in place. Roger [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/3/2015 4:50 PM, mark.reinhold at oracle.com wrote: > Looks good -- thanks for the further simplification. > > Minor editorial comments, to add what Kim and Chris noted: > > - In many places you write, e.g., "Cleaner" rather than "{@code > Cleaner}". For consistency with the rest of the package it'd be > better in most cases just to write "cleaner" or, if its nature as > a class is important, write "{@code Cleaner}". The same goes for > Cleanable, Thread, ThreadFactory, and all other types. > > - The specification of Cleaner::create() mentions > "ThreadContextClassLoader", but that's not actually a type anywhere > in the JDK. Suggest "{@linkplain > java.lang.Thread#getContextClassLoader context class loader}. > > - In the same method, it'd be helpful to provide links into the Thread > class (or wherever) for the concepts of access-control context and > thread locals. > > - Mark From Roger.Riggs at Oracle.com Fri Dec 4 16:56:05 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 11:56:05 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> Message-ID: <5661C5A5.9020904@Oracle.com> Hi Mandy, The webrev[1] and javadoc[2] are updated in to address your comments. Thanks, Roger [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/3/2015 8:43 PM, Mandy Chung wrote: >> On Dec 3, 2015, at 1:19 PM, Roger Riggs wrote: >> >> [1] http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> [2] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > The implementation looks good. I?ll wait for an updated javadoc and re-review that incorporates the editorial comments that Mark made. > > Some additional comments: > - null should be {@code null} > > 150 * Refer to the API Note above for cautions about the behavior > 151 * of cleaning functions. ok > > It may be good to add a link back to the API note. ok > > 76 * and not block. If the cleaning function blocks it may delay processing > - should there be ?,? before ?it?? ok > > 77 * other cleaning functions using the same Cleaner. > 78 * All cleaning functions using a Cleaner should be mutually compatible. > - ?using a cleaner? - should the terminology be ?registered in a cleaner? consistent with other references in the spec? ok > > 104 * The thread sets the ThreadContextClassLoader to the system class loader, > 105 * sets the AccessControlContext to an empty ProtectionDomain, > 106 * clears ThreadLocals, and sets the thread to be a > 107 * {@link Thread#setDaemon(boolean) daemon thread}. > > I think clearing thread locals may not need to be mentioned. Below is one suggestion to rephrase the above. Similarly can be applied to the thread factory variant. > > * The thread is a {@linkplain Thread#isDaemon() daemon thread}. > * The thread's {@linkplain Thread#getContextClassLoader context class loader} > * is set to {@linkplain ClassLoader#getSystemClassLoader() system class loader}. > * The thread has no permission to access any security operation. Reworded both method doc. > > Minor comment on the CleanerTest.java: > > 530 // unless it is know this case throws an exception, rethrow > > typo: s/know/known > > It would be better to rename the test[1-5] methods to reflect what it verifies. done > > 254 Reference r = queue.remove(); > > Minor one: remove(long timeout) may be a better option while in practice remove() will not block forever. done. Roger > > Mandy From jason_mehrens at hotmail.com Fri Dec 4 17:26:22 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 4 Dec 2015 17:26:22 +0000 Subject: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions In-Reply-To: <56533063.5060008@oracle.com> References: <564F24AD.3060006@oracle.com> <564F5801.2030202@oracle.com> , <56533063.5060008@oracle.com> Message-ID: Alexander, >What is wrong with get/serErrorManager for Formatter? It should be just >a way for Formatter to report its internal errors. 1. You can't inherit the Handler error manager until after construction of the formatter. That means the concept of inheriting an error manager from a handler is flawed. Forcing subclasses to include an ErrorManager or Handler constructor is not very clean either. Especially if the formatter already has constructors that take multiple arguments. 2. Formatters can decorate other formatters. See point #1. Logging does not allow for creating an ErrorManager that is hostile that allows an exception to escape (without resorting to hacks). Making the internal and external formatter work as one unit gets messy. 3. How do you control System.err chatter? It used to be that every handler had an error manager and every error manager could report one problem. If we increase the number of error managers we can increase the amount of chatter. 3. The JDK Handlers already expect that formatters throw exceptions see (StreamHandler). Publishing is where things are expected to fail. Everything that happens upstream from a Handler is expected not to fail. It is already cleanly established that the handler should be the mediator between the formatter and the error manager. The creation of a handler creates the error manager and formatters so it is much cleaner to have the formatter simply throw exceptions to the handler and have the handler delegate to the error manager. 4. ErrorManagers installed on formatters would mainly deal with programing bugs (pattern syntax errors and broken Object.toString implementations) not expected failures like I/O. Seems excessive to add an ErrorManager that conditionally handles bugs. Handers on the other hand can fail with checked exceptions like I/O which is a different class of errors. 5. ErrorManager properties on a Formatter is more API complexity and more mutable state to deal with and test. I think API producers and API consumers would like to avoid this debt. 6. ErrorManager defines an error code as an argument. If objects belonging to a Handler were supposed to have an ErrorManager we wouldn't need the code argument. This new addtion conflicts with the original design. 7. It is wasted object. Not all Handlers have just one formatter and those formatters can contain formatters. There are two clean ways errors should be reported in a formatter without changing the API. Either throw the exception to the caller (Handler) or format the error using a best effort and return it as a string. Going back to https://bugs.openjdk.java.net/browse/JDK-8028233, the pain point is that the error is lost when we create buggy Object.toString implementations. A very clean solution would be to make the formatter simply format the exception, the pattern syntax (record.getMessage), the types of the arguments (avoids calling overridden toString methods) and return a concatinated string. This gets around the limitation of reporting only one failure and is not hostile which is nice for compatiblity. Since we are dealing with formatMessage, changing the behavior doesn't break XMLFormatter or SimpleFormatter because that returned string is free form. All the API says is "returns a localized and formatted message" when faced with a bad command (pattern syntax error) it would be legal to alter the string returned in the failure case. Jason From kim.barrett at oracle.com Fri Dec 4 17:56:54 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 12:56:54 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5661C5A5.9020904@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> Message-ID: On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote: > > Hi Mandy, > > The webrev[1] and javadoc[2] are updated in to address your comments. > > Thanks, Roger > > [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > One tiny nit: src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java 136 // Cleanable the thread locals "Cleanable" seems like the wrong word here. All of my previous points have been addressed. Looks good to me. From Roger.Riggs at Oracle.com Fri Dec 4 17:58:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 12:58:59 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> Message-ID: <5661D463.4070507@Oracle.com> Hi Kim, Corrected Thanks for all the review, Roger On 12/4/2015 12:56 PM, Kim Barrett wrote: > On Dec 4, 2015, at 11:56 AM, Roger Riggs wrote: >> Hi Mandy, >> >> The webrev[1] and javadoc[2] are updated in to address your comments. >> >> Thanks, Roger >> >> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> > One tiny nit: > src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > 136 // Cleanable the thread locals > > "Cleanable" seems like the wrong word here. > > All of my previous points have been addressed. > > Looks good to me. > From sean.coffey at oracle.com Fri Dec 4 18:02:52 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 4 Dec 2015 18:02:52 +0000 Subject: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518 In-Reply-To: <5660DD92.8070506@oracle.com> References: <5660DD92.8070506@oracle.com> Message-ID: <5661D54C.6000803@oracle.com> Looks fine Aleksej. Reviewed. Also approved for jdk8u-dev. Regards, Sean. On 04/12/15 00:25, Aleksej Efimov wrote: > Hi, > > Please, help to review and approve JDK-8133924 backport to JDK8. The > source fix is identical to JDK9 changes, but there was no test added > for this issue in JDK9. > > The existing > jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test > was modified to test the reported problem in JDK8 and it is a subject > of review: > http://cr.openjdk.java.net/~aefimov/8133924/8/00 > > No regression tests failures were observed for the proposed fix in > JDK8 + the fix is in JDK9 for 3 months already. > > With Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8133924 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 > > JDK9 Review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html > From kim.barrett at oracle.com Fri Dec 4 18:07:44 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 13:07:44 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> Message-ID: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> [Indeed, this whole section isn't strictly necessary; all of it can be >> inferred from information in other places.] > > Agree. This section is no longer necessary and maybe just remove it: I wasn't actually intending to suggest removal. It seems like there is useful overview information to be had here, rather than requiring readers to make not necessarily obvious inferences. My impression is that readability is valued more highly than terseness in Java documentation. From bitterfoxc at gmail.com Fri Dec 4 06:57:03 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Fri, 4 Dec 2015 15:57:03 +0900 Subject: RFR 8144675: Add a filtering collector Message-ID: Hi, core-libs-dev and Brian, Paul, I'd like to propose adding filtering method to Collectors. When I consider the operation what is "grouping the number of employees whose income is over 2000 by the depertment from employees", we have to write following because there is no way to filter for Collector: (Note: In this case, we need the entry which the value is 0) Map map = emps.stream() .collect(groupingBy(Employee::getDepartment, collectingAndThen(toList(), es -> es.stream().filter(e -> e.getSalary() > 2000).count()))); When I add filtering like following to Collectors, we can write it easy, and it would be more efficient. public static Collector filtering(Predicate filter, Collector downstream) { BiConsumer downstreamAccumulator = downstream.accumulator(); return new CollectorImpl<>(downstream.supplier(), (r, t) -> { if (filter.test(t)) { downstreamAccumulator.accept(r, t); } }, downstream.combiner(), downstream.finisher(), downstream.characteristics()); } Map map = emps.stream() .collect(groupingBy(Employee::getDepartment, filtering(e -> e.getSalary() > 2000, counting()))); Here is patch: webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 Could you consider this patch and proposal? Regards, shinyafox(Shinya Yoshida) From alber84ou at gmail.com Fri Dec 4 15:22:37 2015 From: alber84ou at gmail.com (=?UTF-8?Q?Alberto_Otero_Rodr=C3=ADguez?=) Date: Fri, 4 Dec 2015 16:22:37 +0100 Subject: Java language and API improvements Message-ID: Hi, I'm Alberto, a Java EE developer from Spain. I would like to suggest several improvements to the Java language and API. These are my suggestions: *1) Variable declaration block* I don't know why, but you can declare variables in a for declaration, but not in an if declaration. I would add a variable declaration block that could be use in if declarations like this: varDeclarationBlock(XSpecificClass x = complicatedXCalculation(), YSpecificClass y = complicatedYCalculation()) { if(x != null && x.getValue() < 100) { ... } else if(y != null && y.getValue() == 1) { ... } else { ... } } *2) Null-safe operator* Many times I have to write code like this: String customerName = (order != null && order.getCustomer() != null) ? order.getCustomer().getName() : null; I think there should be an # operator in the object class that could check if the object is null and return null in this case without doing the next methods. So, the previous sentence could be written like: String customerName = order#getCustomer()#getName(); *3) Switch with blocks* I think there should be a switch made with blocks in order to permit using variables with the same name and avoid the problems of not putting a break. It would be something like: switch(x) { case(1) { int i = 1; ... } case(2) { int i = 2; ... } default { ... } } *4) Multiple condition ternary operator* I think it would be useful to be able to do this: String str = condition1 \ condition2 ? stringCondition1 : stringCondition2 : stringElse; Instead of: String str = null; if(condition1) { str = stringCondition1; } else if(condition2) { str = stringCondition2; }. else { str = stringElse; } *5) printObject* Sometimes I want to know the values of all the properties of an Object recursively. I have written a method to do that, but I think Java should have something similar. I attach my method which is called Util.printObject(Object initialObject, int initialDepth, String filePath) where initialObject is the object to print recursively, initialDepth is the maximum depth to print and filePath the path of the file where the String will be printed. From viktor.klang at gmail.com Tue Dec 1 12:47:43 2015 From: viktor.klang at gmail.com (Viktor Klang) Date: Tue, 1 Dec 2015 13:47:43 +0100 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <561E6F04.9030708@cs.oswego.edu> <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com> <561FC6F9.1080701@cs.oswego.edu> <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com> <562BC968.70603@cs.oswego.edu> <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com> <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: While we are painting the bikeshed, what about `powerNap()` On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich wrote: > Minor quibble, but why the "on" prefix in the name? Maybe just me, but > onXYX is typically used for event notification style APIs. > > Also, the "wait" part seems inappropriate as the method itself isn't doing > any waiting. What was wrong with the original spinLoopHint name? Or > cpuRelax()? > > sent from my phone > On Nov 30, 2015 9:59 PM, "Gil Tene" wrote: > >> Update: After some significant back-and-forth between Doug and I on >> naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we >> have what we think is a good spec and name selection for this thing. We're >> proposing to add a new static method to the Runtime class: >> >> class Runtime { /... >> /** >> * Method signifying that the caller is momentarily unable to >> * progress until the occurrence of one or more actions of one or >> * more other activities. When invoked within each iteration, this >> * method typically improves performance of spin wait loop >> * constructions. >> */ >> public static void onSpinWait() {}; >> } >> >> See updated details, including a link to the updated JEP draft, as well >> as links to working prototype implementations, webrevs against OpenJDK9b94, >> and example here: >> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest < >> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All >> names have changed to reflect the new naming (onSpinWait, >> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.). >> >> As an interesting stat, the total changes in the WebRevs amount to 78 >> added lines (across 14 files) , and 0 lines removed or changed. Hopefully a >> good indication of relatively low footprint and risk. >> >> ? Gil. >> >> >> >> >> >> > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, ? From kim.barrett at oracle.com Fri Dec 4 18:16:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 13:16:47 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56613DD4.40600@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> Message-ID: <05734348-D522-464B-9133-CA64793E8979@oracle.com> On Dec 4, 2015, at 2:16 AM, Per Liden wrote: > > On 2015-12-02 19:37, Kim Barrett wrote: >> Please review this change to PhantomReference processing, changing the >> GC-based notification to automatically clear the referent. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8071507 >> >> Webrevs: >> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ > > test/java/lang/ref/PhantomReferentClearing.java: > > 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. > 86 O1 = null; > 87 System.gc(); > 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { > 89 throw new RuntimeException("P1 not notified by O1 deletion"); > 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { > 91 throw new RuntimeException("P2 notified by O1 deletion."); > 92 } > 93 > 94 // Delete root -> O2, collect. P2 should be notified. > 95 O2 = null; > 96 System.gc(); > 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { > 98 throw new RuntimeException("P2 not notified by O2 deletion"); > 99 } > > The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. I'd rather not clutter and uglify this and other tests to deal with a problem we don't (so far as I can tell) presently actually have. If a problem does arise, the form of that problem will help guide what the solution needs to be. I suspect adding something to WhiteBox would be the proper approach, so that it can be shared with other tests of this form. From jawnsy at cpan.org Fri Dec 4 18:28:01 2015 From: jawnsy at cpan.org (Jonathan Yu) Date: Fri, 4 Dec 2015 13:28:01 -0500 Subject: Java language and API improvements In-Reply-To: References: Message-ID: Hi Alberto, It might be easier to discuss these proposals by separating them into individual emails, to help keep things focussed. I'm not even sure if this is the right list for Java language discussions. I'm not an expert but just sharing some quick thoughts... On Fri, Dec 4, 2015 at 10:22 AM, Alberto Otero Rodr?guez < alber84ou at gmail.com> wrote: > > *3) Switch with blocks* > > I think there should be a switch made with blocks in order to permit > using variables with the same name and avoid the problems of not putting a > break. It would be something like: > > switch(x) > { > case(1) > { > int i = 1; > ... > } > case(2) > { > int i = 2; > ... > } > default > { > ... > } > } > This should already be doable today, e.g. switch (x) { case 1: { int i = 1; break; } case 2: { int i = 2; break; } The "break" part is unfortunate but cannot be changed without breaking existing code, since code that currently falls through would suddenly start behaving differently. > *4) Multiple condition ternary operator* > > I think it would be useful to be able to do this: > > String str = condition1 \ condition2 ? stringCondition1 : > stringCondition2 : stringElse; > > > Instead of: > > String str = null; > if(condition1) > { > str = stringCondition1; > } > else if(condition2) > { > str = stringCondition2; > }. > else > { > str = stringElse; > } > Personally, I find even a single ternary operator to sometimes be a bit hard to follow in code, and I think having multiple like this would be worse. It can also make stepping through line-by-line in a debugger more difficult (a reason that I like to use lots of intermediate variables), even if it results in more lines of code. Cheers, Jonathan From henry.jen at oracle.com Fri Dec 4 18:28:51 2015 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 4 Dec 2015 10:28:51 -0800 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: Message-ID: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> My first thought is what?s wrong with stream.filter(predicate).collect(...)? In your case, that would be, amps.stream().filter(e -> e.getSalary() > 2000) .collect(groupingBy(Employee::getDepartment), Collectors.counting()) That should work just fine? Cheers, Henry > On Dec 3, 2015, at 10:57 PM, ShinyaYoshida wrote: > > Hi, core-libs-dev and Brian, Paul, > I'd like to propose adding filtering method to Collectors. > > When I consider the operation what is "grouping the number of employees > whose income is over 2000 by the depertment from employees", we have to > write following because there is no way to filter for Collector: > (Note: In this case, we need the entry which the value is 0) > > Map map = emps.stream() > .collect(groupingBy(Employee::getDepartment, > collectingAndThen(toList(), > es -> es.stream().filter(e -> e.getSalary() > 2000).count()))); > > When I add filtering like following to Collectors, we can write it easy, > and it would be more efficient. > public static > Collector filtering(Predicate filter, > Collector downstream) { > BiConsumer downstreamAccumulator = > downstream.accumulator(); > return new CollectorImpl<>(downstream.supplier(), > (r, t) -> { > if (filter.test(t)) { > downstreamAccumulator.accept(r, > t); > } > }, > downstream.combiner(), > downstream.finisher(), > downstream.characteristics()); > } > > Map map = emps.stream() > .collect(groupingBy(Employee::getDepartment, > filtering(e -> e.getSalary() > 2000, counting()))); > > Here is patch: > webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ > bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 > > Could you consider this patch and proposal? > > Regards, > shinyafox(Shinya Yoshida) From joe.darcy at oracle.com Fri Dec 4 18:31:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 4 Dec 2015 10:31:54 -0800 Subject: JDK 9 RFR of JDK-8144742: Instrument intermittently failing test GCDuringIteration.java Message-ID: <5661DC1A.7000707@oracle.com> Hello, Please review the patch below to address JDK-8144742: Instrument intermittently failing test GCDuringIteration.java In brief, after GCDuringIteration.java was un- at ignored recently, it has been seen to fail intermittently in some of our testing. As the test uses randomness, to help the investigation GCDuringIteration.java should be switched over to the standard random number generator which prints out the seed and allows the seed to be set. Also, the test is marked as being known to intermittently fail and for that reason, is bumped from tier 1 to tier 2. Thanks, -Joe diff -r 8ef2bf79539c test/TEST.groups --- a/test/TEST.groups Thu Dec 03 13:18:51 2015 -0800 +++ b/test/TEST.groups Fri Dec 04 10:30:58 2015 -0800 @@ -30,6 +30,7 @@ -java/lang/ProcessHandle/TreeTest.java \ -java/util/zip/TestLocalTime.java \ :jdk_util \ + -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/Phaser/Basic.java \ sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ @@ -40,6 +41,7 @@ java/lang/ProcessHandle/TreeTest.java \ java/util/zip/TestLocalTime.java \ java/util/concurrent/Phaser/Basic.java \ + java/util/WeakHashMap/GCDuringIteration.java \ :jdk_io \ :jdk_nio \ -sun/nio/cs/ISO8859x.java \ diff -r 8ef2bf79539c test/java/util/WeakHashMap/GCDuringIteration.java --- a/test/java/util/WeakHashMap/GCDuringIteration.java Thu Dec 03 13:18:51 2015 -0800 +++ b/test/java/util/WeakHashMap/GCDuringIteration.java Fri Dec 04 10:30:58 2015 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2015, 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 @@ -24,13 +24,17 @@ /* * @test * @bug 6499848 + * @library /lib/testlibrary/ + * @build jdk.testlibrary.RandomFactory + * @run main GCDuringIteration * @summary Check that iterators work properly in the presence of * concurrent finalization and removal of elements. - * @key randomness + * @key randomness intermittent */ import java.util.*; import java.util.concurrent.CountDownLatch; +import jdk.testlibrary.RandomFactory; public class GCDuringIteration { private static void waitForFinalizersToRun() { @@ -65,8 +69,9 @@ equal(map.values().iterator().next(), v); } + static final Random rnd = RandomFactory.getRandom(); + void checkIterator(final Iterator> it, int first) { - final Random rnd = new Random(); for (int i = first; i >= 0; --i) { if (rnd.nextBoolean()) check(it.hasNext()); equal(it.next().getValue(), i); @@ -86,7 +91,7 @@ final int n = 10; // Create array of strong refs final Foo[] foos = new Foo[2*n]; - final Map map = new WeakHashMap(foos.length); + final Map map = new WeakHashMap<>(foos.length); check(map.isEmpty()); equal(map.size(), 0); From Roger.Riggs at oracle.com Fri Dec 4 18:45:09 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 13:45:09 -0500 Subject: JDK 9 RFR of JDK-8144742: Instrument intermittently failing test GCDuringIteration.java In-Reply-To: <5661DC1A.7000707@oracle.com> References: <5661DC1A.7000707@oracle.com> Message-ID: <5661DF35.706@oracle.com> Hi Joe, Looks fine, Roger On 12/04/2015 01:31 PM, joe darcy wrote: > Hello, > > Please review the patch below to address > > JDK-8144742: Instrument intermittently failing test > GCDuringIteration.java > > In brief, after GCDuringIteration.java was un- at ignored recently, it > has been seen to fail intermittently in some of our testing. As the > test uses randomness, to help the investigation GCDuringIteration.java > should be switched over to the standard random number generator which > prints out the seed and allows the seed to be set. > > Also, the test is marked as being known to intermittently fail and for > that reason, is bumped from tier 1 to tier 2. > > Thanks, > > -Joe > > diff -r 8ef2bf79539c test/TEST.groups > --- a/test/TEST.groups Thu Dec 03 13:18:51 2015 -0800 > +++ b/test/TEST.groups Fri Dec 04 10:30:58 2015 -0800 > @@ -30,6 +30,7 @@ > -java/lang/ProcessHandle/TreeTest.java \ > -java/util/zip/TestLocalTime.java \ > :jdk_util \ > + -java/util/WeakHashMap/GCDuringIteration.java \ > -java/util/concurrent/Phaser/Basic.java \ > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > @@ -40,6 +41,7 @@ > java/lang/ProcessHandle/TreeTest.java \ > java/util/zip/TestLocalTime.java \ > java/util/concurrent/Phaser/Basic.java \ > + java/util/WeakHashMap/GCDuringIteration.java \ > :jdk_io \ > :jdk_nio \ > -sun/nio/cs/ISO8859x.java \ > diff -r 8ef2bf79539c test/java/util/WeakHashMap/GCDuringIteration.java > --- a/test/java/util/WeakHashMap/GCDuringIteration.java Thu Dec 03 > 13:18:51 2015 -0800 > +++ b/test/java/util/WeakHashMap/GCDuringIteration.java Fri Dec 04 > 10:30:58 2015 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2007, 2015, 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 > @@ -24,13 +24,17 @@ > /* > * @test > * @bug 6499848 > + * @library /lib/testlibrary/ > + * @build jdk.testlibrary.RandomFactory > + * @run main GCDuringIteration > * @summary Check that iterators work properly in the presence of > * concurrent finalization and removal of elements. > - * @key randomness > + * @key randomness intermittent > */ > > import java.util.*; > import java.util.concurrent.CountDownLatch; > +import jdk.testlibrary.RandomFactory; > > public class GCDuringIteration { > private static void waitForFinalizersToRun() { > @@ -65,8 +69,9 @@ > equal(map.values().iterator().next(), v); > } > > + static final Random rnd = RandomFactory.getRandom(); > + > void checkIterator(final Iterator> it, > int first) { > - final Random rnd = new Random(); > for (int i = first; i >= 0; --i) { > if (rnd.nextBoolean()) check(it.hasNext()); > equal(it.next().getValue(), i); > @@ -86,7 +91,7 @@ > final int n = 10; > // Create array of strong refs > final Foo[] foos = new Foo[2*n]; > - final Map map = new > WeakHashMap(foos.length); > + final Map map = new WeakHashMap<>(foos.length); > check(map.isEmpty()); > equal(map.size(), 0); > > From martinrb at google.com Fri Dec 4 18:56:21 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 4 Dec 2015 10:56:21 -0800 Subject: JDK 9 RFR of JDK-8144742: Instrument intermittently failing test GCDuringIteration.java In-Reply-To: <5661DC1A.7000707@oracle.com> References: <5661DC1A.7000707@oracle.com> Message-ID: Looks OK. Sorry for the continuing troubles, but this test has survived many iterations on Google machines without failure. Failures are more likely to be collector-specific than random-number-specific. If you can repro, you can try varying hotspot GC flags. On Fri, Dec 4, 2015 at 10:31 AM, joe darcy wrote: > Hello, > > Please review the patch below to address > > JDK-8144742: Instrument intermittently failing test > GCDuringIteration.java > > In brief, after GCDuringIteration.java was un- at ignored recently, it has been > seen to fail intermittently in some of our testing. As the test uses > randomness, to help the investigation GCDuringIteration.java should be > switched over to the standard random number generator which prints out the > seed and allows the seed to be set. > > Also, the test is marked as being known to intermittently fail and for that > reason, is bumped from tier 1 to tier 2. > > Thanks, > > -Joe > > diff -r 8ef2bf79539c test/TEST.groups > --- a/test/TEST.groups Thu Dec 03 13:18:51 2015 -0800 > +++ b/test/TEST.groups Fri Dec 04 10:30:58 2015 -0800 > @@ -30,6 +30,7 @@ > -java/lang/ProcessHandle/TreeTest.java \ > -java/util/zip/TestLocalTime.java \ > :jdk_util \ > + -java/util/WeakHashMap/GCDuringIteration.java \ > -java/util/concurrent/Phaser/Basic.java \ > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > @@ -40,6 +41,7 @@ > java/lang/ProcessHandle/TreeTest.java \ > java/util/zip/TestLocalTime.java \ > java/util/concurrent/Phaser/Basic.java \ > + java/util/WeakHashMap/GCDuringIteration.java \ > :jdk_io \ > :jdk_nio \ > -sun/nio/cs/ISO8859x.java \ > diff -r 8ef2bf79539c test/java/util/WeakHashMap/GCDuringIteration.java > --- a/test/java/util/WeakHashMap/GCDuringIteration.java Thu Dec 03 > 13:18:51 2015 -0800 > +++ b/test/java/util/WeakHashMap/GCDuringIteration.java Fri Dec 04 > 10:30:58 2015 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2007, 2015, 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 > @@ -24,13 +24,17 @@ > /* > * @test > * @bug 6499848 > + * @library /lib/testlibrary/ > + * @build jdk.testlibrary.RandomFactory > + * @run main GCDuringIteration > * @summary Check that iterators work properly in the presence of > * concurrent finalization and removal of elements. > - * @key randomness > + * @key randomness intermittent > */ > > import java.util.*; > import java.util.concurrent.CountDownLatch; > +import jdk.testlibrary.RandomFactory; > > public class GCDuringIteration { > private static void waitForFinalizersToRun() { > @@ -65,8 +69,9 @@ > equal(map.values().iterator().next(), v); > } > > + static final Random rnd = RandomFactory.getRandom(); > + > void checkIterator(final Iterator> it, int > first) { > - final Random rnd = new Random(); > for (int i = first; i >= 0; --i) { > if (rnd.nextBoolean()) check(it.hasNext()); > equal(it.next().getValue(), i); > @@ -86,7 +91,7 @@ > final int n = 10; > // Create array of strong refs > final Foo[] foos = new Foo[2*n]; > - final Map map = new > WeakHashMap(foos.length); > + final Map map = new WeakHashMap<>(foos.length); > check(map.isEmpty()); > equal(map.size(), 0); > > From kim.barrett at oracle.com Fri Dec 4 19:16:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 Dec 2015 14:16:14 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <05734348-D522-464B-9133-CA64793E8979@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <05734348-D522-464B-9133-CA64793E8979@oracle.com> Message-ID: On Dec 4, 2015, at 1:16 PM, Kim Barrett wrote: > > I'd rather not clutter and uglify this and other tests to deal with a > problem we don't (so far as I can tell) presently actually have. If a > problem does arise, the form of that problem will help guide what the > solution needs to be. I suspect adding something to WhiteBox would be > the proper approach, so that it can be shared with other tests of this > form. But maybe I should use WhiteBox.fullGC instead of System.gc? From xueming.shen at oracle.com Fri Dec 4 19:41:11 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 04 Dec 2015 11:41:11 -0800 Subject: RPR JDK-8143854: java/util/regex/RegExTest.java.RegExTest failed Message-ID: <5661EC57.3090007@oracle.com> Hi, Please help review the change for JDK-8143854 Issue: https://bugs.openjdk.java.net/browse/JDK-8143854 webrev: http://cr.openjdk.java.net/~sherman/8143854 This is triggered by the same cause of bug JDK-8079419. However the fix for 8079419 missed the possibility that the last character of the pattern might be a supplementary character, therefor the patternLength might not be equal to pattern.length(), the check put in fails to function. Thanks, Sherman From joe.darcy at oracle.com Fri Dec 4 19:53:39 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 4 Dec 2015 11:53:39 -0800 Subject: RPR JDK-8143854: java/util/regex/RegExTest.java.RegExTest failed In-Reply-To: <5661EC57.3090007@oracle.com> References: <5661EC57.3090007@oracle.com> Message-ID: <5661EF43.4090505@oracle.com> Looks fine Sherman; thanks, -Joe On 12/4/2015 11:41 AM, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8143854 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8143854 > webrev: http://cr.openjdk.java.net/~sherman/8143854 > > This is triggered by the same cause of bug JDK-8079419. However > the fix for 8079419 missed the possibility that the last character > of the pattern might be a supplementary character, therefor the > patternLength might not be equal to pattern.length(), the check > put in fails to function. > > Thanks, > Sherman From peter.levart at gmail.com Fri Dec 4 20:30:37 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 21:30:37 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5661C596.1070801@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> <20151203135022.165903@eggemoggin.niobe.net> <5661C596.1070801@Oracle.com> Message-ID: <5661F7ED.7070400@gmail.com> Just a nit more, Roger: 131 *

132 * The cleaner terminates when it is unreachable and all of the 133 * registered cleaning functions are complete. (and also in the javadoc of the other create() method) The cleaner is an object. What terminates is a thread. So what about: "The thread terminates after the cleaner becomes unreachable and all of the registered cleaning functions have completed." Would writing something like the following make sense: "A future implementation may use more than one thread. The ThreadFactory should not assume that only one thread will be requested." ? Regards, Peter On 12/04/2015 05:55 PM, Roger Riggs wrote: > Hi, > > Thanks for the review and comments. > > The webrev[1] and javadoc[2] are updated in place. > > Roger > > [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > On 12/3/2015 4:50 PM, mark.reinhold at oracle.com wrote: >> Looks good -- thanks for the further simplification. >> >> Minor editorial comments, to add what Kim and Chris noted: >> >> - In many places you write, e.g., "Cleaner" rather than "{@code >> Cleaner}". For consistency with the rest of the package it'd be >> better in most cases just to write "cleaner" or, if its nature as >> a class is important, write "{@code Cleaner}". The same goes for >> Cleanable, Thread, ThreadFactory, and all other types. >> >> - The specification of Cleaner::create() mentions >> "ThreadContextClassLoader", but that's not actually a type anywhere >> in the JDK. Suggest "{@linkplain >> java.lang.Thread#getContextClassLoader context class loader}. >> >> - In the same method, it'd be helpful to provide links into the >> Thread >> class (or wherever) for the concepts of access-control context and >> thread locals. >> >> - Mark > From Roger.Riggs at oracle.com Fri Dec 4 20:39:56 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 15:39:56 -0500 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5660E518.4040705@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <5661FA1C.2030008@oracle.com> Hi Stuart, List.java: - The varargs form would be more readable if the parameter was named 'elements' instead of 'es'. - ditto Map and Set Map.java: - in the @returns I would say returns "a {@code Map}" to be explicit about the return type. (ditto in Set and List to reinforce the return type) - the exception for duplicate keys that is thrown says duplicate elements but it is really the keys that are duplicated. In the @throws clause it would be more readable to say "if there are duplicates in the keys" or as is appears in Set: "if there are any duplicate elements" Reviewed: +1 Roger On 12/03/2015 07:58 PM, Stuart Marks wrote: > Small refresh here: after some consultation with Brian Goetz and John > Rose, I've updated the class doc text covers immutability and > value-based. They now say, > > * They are structurally immutable. Elements cannot be added, removed, > or replaced. Attempts to do so result in > UnsupportedOperationException. However, if the contained elements are > themselves mutable, this may cause the List's contents to appear to > change. > > [and similar for Set and Map] > > * They are value-based. Callers should make no assumptions about the > identity of the returned instances. Factories are free to create new > instances or reuse existing ones. Therefore, identity-sensitive > operations on these instances (reference equality (==), identity hash > code, and synchronization) are unreliable and should be avoided. > > -- > > I still need an official OpenJDK Reviewer. > > -- > > API: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html > > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ > > Thanks, > > s'marks > > > On 12/1/15 6:35 PM, Stuart Marks wrote: >> Hi all, >> >> Thanks for the previous round of review comments. Here's an updated >> API and >> implementation for review. >> >> I've run specdiff with the --hu ("hide unchanged") option, so only >> the bits of >> the specification that have changed are shown. As before, though, >> please ignore >> the spurious change to EnumSet caused by a javadoc bug. >> >> API changes: >> - add clarifying notes on immutability >> - remove wording that implied creation of new objects >> - add "value-based" disclaimers >> - add ordering specification for List and non-ordering disclaimers >> for Set and Map >> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >> instead >> it extracts keys and values >> - Map.Entry instances returned from Map.entry() are *not* serializable >> >> Other: >> - markup cleanups >> - small implementation cleanups >> >> JEP: >> >> http://openjdk.java.net/jeps/269 >> >> API spec (basically List, Map, and Set): >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >> >> Thanks, >> >> s'marks From bitterfoxc at gmail.com Fri Dec 4 20:53:45 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Sat, 5 Dec 2015 05:53:45 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> Message-ID: Thank you for your comment. 2015-12-05 3:28 GMT+09:00 Henry Jen : > My first thought is what?s wrong with > > stream.filter(predicate).collect(...)? > > In your case, that would be, > > amps.stream().filter(e -> e.getSalary() > 2000) > .collect(groupingBy(Employee::getDepartment), Collectors.counting()) > > That should work just fine? > Unfortunately, not, Stream#filter could not satisfy us in this case. Because when I filter before collecting, the entry which the value is 0 will not be appeared in the result map. Ex) filtering collector(Collectors#filtering): http://ideone.com/83Lzb7 filtering before collecting(Stream#filter): http://ideone.com/EmTrXE Regards, shinyafox(ShinyaYoshida) > > Cheers, > Henry > > > > > On Dec 3, 2015, at 10:57 PM, ShinyaYoshida wrote: > > > > Hi, core-libs-dev and Brian, Paul, > > I'd like to propose adding filtering method to Collectors. > > > > When I consider the operation what is "grouping the number of employees > > whose income is over 2000 by the depertment from employees", we have to > > write following because there is no way to filter for Collector: > > (Note: In this case, we need the entry which the value is 0) > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > collectingAndThen(toList(), > > es -> es.stream().filter(e -> e.getSalary() > > 2000).count()))); > > > > When I add filtering like following to Collectors, we can write it easy, > > and it would be more efficient. > > public static > > Collector filtering(Predicate filter, > > Collector downstream) { > > BiConsumer downstreamAccumulator = > > downstream.accumulator(); > > return new CollectorImpl<>(downstream.supplier(), > > (r, t) -> { > > if (filter.test(t)) { > > downstreamAccumulator.accept(r, > > t); > > } > > }, > > downstream.combiner(), > > downstream.finisher(), > > downstream.characteristics()); > > } > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > filtering(e -> e.getSalary() > 2000, counting()))); > > > > Here is patch: > > webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ > > bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 > > > > Could you consider this patch and proposal? > > > > Regards, > > shinyafox(Shinya Yoshida) > > From chris.plummer at oracle.com Fri Dec 4 21:00:21 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 4 Dec 2015 13:00:21 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets Message-ID: <5661FEE5.2040108@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ Tested with JPRT with: ? "-testset hotspot" ? "-testset svc" ? "-testset chris" from the example custom testset provided in the CR. ? no testset specified BTW, if anyone knows of an "include" mechanism for jprt.properties, please let me know. Although that won't change the need for the above changes, it would make it possible to put custom testsets in a file rather than having to paste them in your ~/.jprt.properties file. thanks, Chris From Roger.Riggs at oracle.com Fri Dec 4 21:04:43 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 16:04:43 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5661F7ED.7070400@gmail.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> <20151203135022.165903@eggemoggin.niobe.net> <5661C596.1070801@Oracle.com> <5661F7ED.7070400@gmail.com> Message-ID: <5661FFEB.9090406@oracle.com> Hi Peter, On 12/04/2015 03:30 PM, Peter Levart wrote: > Just a nit more, Roger: > > 131 *

> 132 * The cleaner terminates when it is unreachable and all of the > 133 * registered cleaning functions are complete. > > (and also in the javadoc of the other create() method) > > The cleaner is an object. What terminates is a thread. So what about: > > "The thread terminates after the cleaner becomes unreachable and all > of the registered cleaning functions have completed." The cleaner is not just an object but is an active processing element. The thread is an artifact of the implementation and not exposed in the API any more than necessary (due to the thread factory). Colloquially, the combination of state and thread can be referred to as the cleaner; it starts, it processes cleanup functions for unreachable objects, and it stops when there are no more. It may be useful to talk about the thread terminating, but that is an implementation detail and not readily visible. > > > Would writing something like the following make sense: "A future > implementation may use more than one thread. The ThreadFactory should > not assume that only one thread will be requested." ? I'm not sure it adds anything to talk about how many times the thread factory will be used. A ThreadFactory has no specific mins or maxes. Roger > > Regards, Peter > > On 12/04/2015 05:55 PM, Roger Riggs wrote: >> Hi, >> >> Thanks for the review and comments. >> >> The webrev[1] and javadoc[2] are updated in place. >> >> Roger >> >> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> On 12/3/2015 4:50 PM, mark.reinhold at oracle.com wrote: >>> Looks good -- thanks for the further simplification. >>> >>> Minor editorial comments, to add what Kim and Chris noted: >>> >>> - In many places you write, e.g., "Cleaner" rather than "{@code >>> Cleaner}". For consistency with the rest of the package it'd be >>> better in most cases just to write "cleaner" or, if its nature as >>> a class is important, write "{@code Cleaner}". The same goes for >>> Cleanable, Thread, ThreadFactory, and all other types. >>> >>> - The specification of Cleaner::create() mentions >>> "ThreadContextClassLoader", but that's not actually a type >>> anywhere >>> in the JDK. Suggest "{@linkplain >>> java.lang.Thread#getContextClassLoader context class loader}. >>> >>> - In the same method, it'd be helpful to provide links into the >>> Thread >>> class (or wherever) for the concepts of access-control context and >>> thread locals. >>> >>> - Mark >> > From peter.levart at gmail.com Fri Dec 4 21:31:28 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 4 Dec 2015 22:31:28 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5661FFEB.9090406@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> <20151203135022.165903@eggemoggin.niobe.net> <5661C596.1070801@Oracle.com> <5661F7ED.7070400@gmail.com> <5661FFEB.9090406@oracle.com> Message-ID: <56620630.80603@gmail.com> On 12/04/2015 10:04 PM, Roger Riggs wrote: > Hi Peter, > > On 12/04/2015 03:30 PM, Peter Levart wrote: >> Just a nit more, Roger: >> >> 131 *

>> 132 * The cleaner terminates when it is unreachable and all of the >> 133 * registered cleaning functions are complete. >> >> (and also in the javadoc of the other create() method) >> >> The cleaner is an object. What terminates is a thread. So what about: >> >> "The thread terminates after the cleaner becomes unreachable and all >> of the registered cleaning functions have completed." > > The cleaner is not just an object but is an active processing element. > The thread is an artifact of the implementation and not exposed in the API > any more than necessary (due to the thread factory). > > Colloquially, the combination of state and thread can be referred to > as the cleaner; > it starts, it processes cleanup functions for unreachable objects, and > it stops when there are no more. > > It may be useful to talk about the thread terminating, but that is an > implementation detail > and not readily visible. Ok, I buy that. > >> >> >> Would writing something like the following make sense: "A future >> implementation may use more than one thread. The ThreadFactory should >> not assume that only one thread will be requested." ? > I'm not sure it adds anything to talk about how many times the thread > factory will be used. > A ThreadFactory has no specific mins or maxes. > > Roger Yes, but other parts of javadoc strictly mention a thread (as singular object). Users are sloppy and like to depend on implementation details. They will be tempted to write code like this: Thread t = new Thread(...); t.setName(...); ... Cleaner c = Cleaner.create(() -> t); ...and it will work. But will fail if some time in the future, Cleaner decides to request multiple threads. Are you sure Cleaner will always use a single thread? It will if the spec. says so. But I don't think there is a reason to specify that and limit the implementation to one thread forever. Regards, Peter > >> >> Regards, Peter >> >> On 12/04/2015 05:55 PM, Roger Riggs wrote: >>> Hi, >>> >>> Thanks for the review and comments. >>> >>> The webrev[1] and javadoc[2] are updated in place. >>> >>> Roger >>> >>> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> On 12/3/2015 4:50 PM, mark.reinhold at oracle.com wrote: >>>> Looks good -- thanks for the further simplification. >>>> >>>> Minor editorial comments, to add what Kim and Chris noted: >>>> >>>> - In many places you write, e.g., "Cleaner" rather than "{@code >>>> Cleaner}". For consistency with the rest of the package it'd be >>>> better in most cases just to write "cleaner" or, if its nature as >>>> a class is important, write "{@code Cleaner}". The same goes for >>>> Cleanable, Thread, ThreadFactory, and all other types. >>>> >>>> - The specification of Cleaner::create() mentions >>>> "ThreadContextClassLoader", but that's not actually a type >>>> anywhere >>>> in the JDK. Suggest "{@linkplain >>>> java.lang.Thread#getContextClassLoader context class loader}. >>>> >>>> - In the same method, it'd be helpful to provide links into the >>>> Thread >>>> class (or wherever) for the concepts of access-control context >>>> and >>>> thread locals. >>>> >>>> - Mark >>> >> > From stuart.marks at oracle.com Fri Dec 4 21:46:46 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Dec 2015 13:46:46 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <922b091ba51357d50d6ebc3168a58d31@reini.net> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> <922b091ba51357d50d6ebc3168a58d31@reini.net> Message-ID: <566209C6.2020109@oracle.com> Hi Patrick, Please see my response to a similar query from Peter Levart: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036909.html Briefly, this is something we should consider as a future extension. The current workaround is to load values into an array and then call the appropriate varargs factory method. s'marks On 12/3/15 11:40 PM, patrick at reini.net wrote: > It may be discussed already but based on the definition as you just changed, > would it make sense to have a way to create such a Set/List/Map based on a > existing mutable implementation? We use a the builder pattern a lot to create > immutable objects that get serialized later. > > At the moment we have to do the following in order to decouple the builders actual > set content in case the builder is re-used: > > Set immutable = Collections.unmodifiableSet(new HashSet<>(builderSet))); > > Instead of may be using: > > Set immutable = Set.of(builderSet); > > The same pattern would also apply to List/Map > > - Patrick > > > On 2015-12-04 01:58, Stuart Marks wrote: >> Small refresh here: after some consultation with Brian Goetz and John >> Rose, I've updated the class doc text covers immutability and >> value-based. They now say, >> >> * They are structurally immutable. Elements cannot be added, >> removed, or replaced. Attempts to do so result in >> UnsupportedOperationException. However, if the contained elements are >> themselves mutable, this may cause the List's contents to appear to >> change. >> >> [and similar for Set and Map] >> >> * They are value-based. Callers should make no assumptions about the >> identity of the returned instances. Factories are free to create new >> instances or reuse existing ones. Therefore, identity-sensitive >> operations on these instances (reference equality (==), identity hash >> code, and synchronization) are unreliable and should be avoided. >> >> -- >> From stuart.marks at oracle.com Fri Dec 4 21:55:14 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Dec 2015 13:55:14 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5EDB8CD3-136D-43F5-86AA-278ACD879F0B@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> <5EDB8CD3-136D-43F5-86AA-278ACD879F0B@oracle.com> Message-ID: <56620BC2.1000409@oracle.com> >> I still need an official OpenJDK Reviewer. > > +1 Thanks. > > This is purely a suggestion, take it or leave it: you could use a static import for Objects.requireNonNull, that makes the current code marginally easier on the eyes (i know this area is likely to change). Will consider for future code cleanups. > List/Set/Map/MOAT > ? > > Update the license header date to 2015. > > > Map > ? > > 1689 * The key and the value must not be null. Calling {@link Entry#setValue Entry.setValue()} > > s/null/{@code null} Will fix the above. s'marks From mandy.chung at oracle.com Fri Dec 4 21:58:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Dec 2015 13:58:55 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> > On Dec 4, 2015, at 10:07 AM, Kim Barrett wrote: > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >> >>> [Indeed, this whole section isn't strictly necessary; all of it can be >>> inferred from information in other places.] >> >> Agree. This section is no longer necessary and maybe just remove it: > > I wasn't actually intending to suggest removal. It seems like there > is useful overview information to be had here, rather than requiring > readers to make not necessarily obvious inferences. My impression is > that readability is valued more highly than terseness in Java > documentation. Actually I considered to remove it in the past but just tried to minimize the spec change. I believe one purpose of that section was intended to call out the difference that PhantomReference is not automatically-cleared that is no longer true. In addition it?s clearly mentioned in PhantomReference constructor. I don?t see the need for it in the package summary. The reader will look at the PhantomRefererence to use it.. "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. Mandy From brian.goetz at oracle.com Fri Dec 4 22:05:59 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 4 Dec 2015 17:05:59 -0500 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> Message-ID: <56620E47.1060907@oracle.com> This seems reasonable; mapping() already exists for use in this space (as a combinator for the downstream collector of groupingBy and friends), filtering() is also reasonable in this context. On 12/4/2015 3:53 PM, ShinyaYoshida wrote: > Thank you for your comment. > > 2015-12-05 3:28 GMT+09:00 Henry Jen >: > > My first thought is what?s wrong with > > stream.filter(predicate).collect(...)? > > In your case, that would be, > > amps.stream().filter(e -> e.getSalary() > 2000) > .collect(groupingBy(Employee::getDepartment), Collectors.counting()) > > That should work just fine? > > Unfortunately, not, Stream#filter could not satisfy us in this case. > Because when I filter before collecting, the entry which the value is > 0 will not be appeared in the result map. > Ex) > filtering collector(Collectors#filtering): http://ideone.com/83Lzb7 > filtering before collecting(Stream#filter): http://ideone.com/EmTrXE > > Regards, > shinyafox(ShinyaYoshida) > > > Cheers, > Henry > > > > > On Dec 3, 2015, at 10:57 PM, ShinyaYoshida > wrote: > > > > Hi, core-libs-dev and Brian, Paul, > > I'd like to propose adding filtering method to Collectors. > > > > When I consider the operation what is "grouping the number of > employees > > whose income is over 2000 by the depertment from employees", we > have to > > write following because there is no way to filter for Collector: > > (Note: In this case, we need the entry which the value is 0) > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > collectingAndThen(toList(), > > es -> es.stream().filter(e -> e.getSalary() > > 2000).count()))); > > > > When I add filtering like following to Collectors, we can write > it easy, > > and it would be more efficient. > > public static > > Collector filtering(Predicate filter, > > Collector > downstream) { > > BiConsumer downstreamAccumulator = > > downstream.accumulator(); > > return new CollectorImpl<>(downstream.supplier(), > > (r, t) -> { > > if (filter.test(t)) { > > downstreamAccumulator.accept(r, > > t); > > } > > }, > > downstream.combiner(), > > downstream.finisher(), > > downstream.characteristics()); > > } > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > filtering(e -> e.getSalary() > 2000, counting()))); > > > > Here is patch: > > webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ > > > bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 > > > > Could you consider this patch and proposal? > > > > Regards, > > shinyafox(Shinya Yoshida) > > From brian.goetz at oracle.com Fri Dec 4 22:10:27 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 4 Dec 2015 17:10:27 -0500 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <56620F53.70101@oracle.com> .. are not necessarily stored in the Map ... On 12/4/2015 4:50 AM, Stephen Colebourne wrote: > Sorry for my delayed review. Basically, I'm happy with this. Some oddments: > > Map.ofEntries(Entry...) > "The entry objects themselves are not stored in the map." > This seems wrong. `Entry` might be implemented as a value, not an > object in the future. And if so, it might form part of the state of an > optimised list implementation. > > The use of looks like it should have an extra space after the comma to me. > > > I prefer to avoid apostrophes in docs > "the map's key type" -> "the key type of the map" > "the first mapping's key" -> "the key of the first mapping" > > > I note that java.util.Stream uses empty() but this API uses of() for > the empty case. I can see both points of view and don't have much of a > preference. Is consistency with Stream needed? > > > KeyValueHolder needs a

at line 41 > > > thanks > Stephen > > > > On 4 December 2015 at 00:58, Stuart Marks wrote: >> Small refresh here: after some consultation with Brian Goetz and John Rose, >> I've updated the class doc text covers immutability and value-based. They >> now say, >> >> * They are structurally immutable. Elements cannot be added, removed, or >> replaced. Attempts to do so result in UnsupportedOperationException. >> However, if the contained elements are themselves mutable, this may cause >> the List's contents to appear to change. >> >> [and similar for Set and Map] >> >> * They are value-based. Callers should make no assumptions about the >> identity of the returned instances. Factories are free to create new >> instances or reuse existing ones. Therefore, identity-sensitive operations >> on these instances (reference equality (==), identity hash code, and >> synchronization) are unreliable and should be avoided. >> >> -- >> >> I still need an official OpenJDK Reviewer. >> >> -- >> >> API: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ >> >> Thanks, >> >> s'marks >> >> >> On 12/1/15 6:35 PM, Stuart Marks wrote: >>> Hi all, >>> >>> Thanks for the previous round of review comments. Here's an updated API >>> and >>> implementation for review. >>> >>> I've run specdiff with the --hu ("hide unchanged") option, so only the >>> bits of >>> the specification that have changed are shown. As before, though, please >>> ignore >>> the spurious change to EnumSet caused by a javadoc bug. >>> >>> API changes: >>> - add clarifying notes on immutability >>> - remove wording that implied creation of new objects >>> - add "value-based" disclaimers >>> - add ordering specification for List and non-ordering disclaimers >>> for Set and Map >>> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >>> instead >>> it extracts keys and values >>> - Map.Entry instances returned from Map.entry() are *not* serializable >>> >>> Other: >>> - markup cleanups >>> - small implementation cleanups >>> >>> JEP: >>> >>> http://openjdk.java.net/jeps/269 >>> >>> API spec (basically List, Map, and Set): >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >>> >>> Specdiff: >>> >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >>> >>> Thanks, >>> >>> s'marks From Roger.Riggs at oracle.com Fri Dec 4 22:20:34 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 4 Dec 2015 17:20:34 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56620630.80603@gmail.com> References: <560D3F61.6040607@Oracle.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <003A173F-94C6-4842-AC71-E14E77D7AF69@oracle.com> <566066B5.2010104@oracle.com> <20151203135022.165903@eggemoggin.niobe.net> <5661C596.1070801@Oracle.com> <5661F7ED.7070400@gmail.com> <5661FFEB.9090406@oracle.com> <56620630.80603@gmail.com> Message-ID: <566211B2.30309@oracle.com> Hi Peter, On 12/04/2015 04:31 PM, Peter Levart wrote: > > ... >> >>> >>> >>> Would writing something like the following make sense: "A future >>> implementation may use more than one thread. The ThreadFactory >>> should not assume that only one thread will be requested." ? >> I'm not sure it adds anything to talk about how many times the thread >> factory will be used. >> A ThreadFactory has no specific mins or maxes. >> >> Roger > > Yes, but other parts of javadoc strictly mention a thread (as singular > object). > > Users are sloppy and like to depend on implementation details. They > will be tempted to write code like this: > > Thread t = new Thread(...); > t.setName(...); > ... > Cleaner c = Cleaner.create(() -> t); > > ...and it will work. But will fail if some time in the future, Cleaner > decides to request multiple threads. Are you sure Cleaner will always > use a single thread? It will if the spec. says so. But I don't think > there is a reason to specify that and limit the implementation to one > thread forever. ok, how about: * On each call the {@link ThreadFactory#newThread(Runnable) thread factory} * should return a new thread, {@link Thread#start() not started}, * with an appropriate * {@linkplain Thread#getContextClassLoader context class loader}, * {@linkplain Thread#getName() name}, * {@linkplain Thread#getPriority() priority}, * permissions, etc. Which brings up a gap in the specification of create() that it can throw exceptions related to creation and starting of threads, including SecurityExceptions, IllegalThreadStateException, etc. If a future cleaner implementation were to use multiple threads, it would need to handle exceptions from invoking ThreadFactory.newThread and be designed to cope with them. A successfully created cleaner will have at least one thread to work with. Thanks, Roger > > Regards, > > Peter > >> >>> >>> Regards, Peter >>> >>> On 12/04/2015 05:55 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> Thanks for the review and comments. >>>> >>>> The webrev[1] and javadoc[2] are updated in place. >>>> >>>> Roger >>>> >>>> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>> >>>> On 12/3/2015 4:50 PM, mark.reinhold at oracle.com wrote: >>>>> Looks good -- thanks for the further simplification. >>>>> >>>>> Minor editorial comments, to add what Kim and Chris noted: >>>>> >>>>> - In many places you write, e.g., "Cleaner" rather than "{@code >>>>> Cleaner}". For consistency with the rest of the package it'd be >>>>> better in most cases just to write "cleaner" or, if its >>>>> nature as >>>>> a class is important, write "{@code Cleaner}". The same goes >>>>> for >>>>> Cleanable, Thread, ThreadFactory, and all other types. >>>>> >>>>> - The specification of Cleaner::create() mentions >>>>> "ThreadContextClassLoader", but that's not actually a type >>>>> anywhere >>>>> in the JDK. Suggest "{@linkplain >>>>> java.lang.Thread#getContextClassLoader context class loader}. >>>>> >>>>> - In the same method, it'd be helpful to provide links into the >>>>> Thread >>>>> class (or wherever) for the concepts of access-control >>>>> context and >>>>> thread locals. >>>>> >>>>> - Mark >>>> >>> >> > From maurizio.cimadamore at oracle.com Fri Dec 4 22:22:34 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 4 Dec 2015 22:22:34 +0000 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <565E590D.3090007@oracle.com> References: <565E590D.3090007@oracle.com> Message-ID: <5662122A.7020303@oracle.com> Hi Stuart small question: I find it a bit odd that EnumSet has max 5 parameters, while Set has more than that. Also, would it be possible, maybe to add overloads to Set that specifically works on Enum constants? > of(Z z1, Z z2) { ... } This would give you a way to call Set.of and get different answers based on the static type of the arguments passed in - and we could deprecate the of method in EnumSet? Too subtle/magic? Maurizio On 02/12/15 02:35, Stuart Marks wrote: > Hi all, > > Thanks for the previous round of review comments. Here's an updated > API and implementation for review. > > I've run specdiff with the --hu ("hide unchanged") option, so only the > bits of the specification that have changed are shown. As before, > though, please ignore the spurious change to EnumSet caused by a > javadoc bug. > > API changes: > - add clarifying notes on immutability > - remove wording that implied creation of new objects > - add "value-based" disclaimers > - add ordering specification for List and non-ordering disclaimers > for Set and Map > - clarify that Map.ofEntries() doesn't store the Map.Entry objects, > instead > it extracts keys and values > - Map.Entry instances returned from Map.entry() are *not* serializable > > Other: > - markup cleanups > - small implementation cleanups > > JEP: > > http://openjdk.java.net/jeps/269 > > API spec (basically List, Map, and Set): > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html > > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ > > Thanks, > > s'marks From henry.jen at oracle.com Fri Dec 4 22:25:06 2015 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 4 Dec 2015 14:25:06 -0800 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> Message-ID: Uh, you did mention you need entry with value zero. I knew I miss something. :) Cheers, Henry > On Dec 4, 2015, at 12:53 PM, ShinyaYoshida wrote: > > Thank you for your comment. > > 2015-12-05 3:28 GMT+09:00 Henry Jen : > My first thought is what?s wrong with > > stream.filter(predicate).collect(...)? > > In your case, that would be, > > amps.stream().filter(e -> e.getSalary() > 2000) > .collect(groupingBy(Employee::getDepartment), Collectors.counting()) > > That should work just fine? > Unfortunately, not, Stream#filter could not satisfy us in this case. > Because when I filter before collecting, the entry which the value is 0 will not be appeared in the result map. > Ex) > filtering collector(Collectors#filtering): http://ideone.com/83Lzb7 > filtering before collecting(Stream#filter): http://ideone.com/EmTrXE > > Regards, > shinyafox(ShinyaYoshida) > > > Cheers, > Henry > > > > > On Dec 3, 2015, at 10:57 PM, ShinyaYoshida wrote: > > > > Hi, core-libs-dev and Brian, Paul, > > I'd like to propose adding filtering method to Collectors. > > > > When I consider the operation what is "grouping the number of employees > > whose income is over 2000 by the depertment from employees", we have to > > write following because there is no way to filter for Collector: > > (Note: In this case, we need the entry which the value is 0) > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > collectingAndThen(toList(), > > es -> es.stream().filter(e -> e.getSalary() > 2000).count()))); > > > > When I add filtering like following to Collectors, we can write it easy, > > and it would be more efficient. > > public static > > Collector filtering(Predicate filter, > > Collector downstream) { > > BiConsumer downstreamAccumulator = > > downstream.accumulator(); > > return new CollectorImpl<>(downstream.supplier(), > > (r, t) -> { > > if (filter.test(t)) { > > downstreamAccumulator.accept(r, > > t); > > } > > }, > > downstream.combiner(), > > downstream.finisher(), > > downstream.characteristics()); > > } > > > > Map map = emps.stream() > > .collect(groupingBy(Employee::getDepartment, > > filtering(e -> e.getSalary() > 2000, counting()))); > > > > Here is patch: > > webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ > > bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 > > > > Could you consider this patch and proposal? > > > > Regards, > > shinyafox(Shinya Yoshida) > > From stuart.marks at oracle.com Fri Dec 4 23:10:10 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Dec 2015 15:10:10 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <56621D52.1020702@oracle.com> On 12/4/15 1:50 AM, Stephen Colebourne wrote: > Sorry for my delayed review. Basically, I'm happy with this. Great! > Map.ofEntries(Entry...) > "The entry objects themselves are not stored in the map." > This seems wrong. `Entry` might be implemented as a value, not an > object in the future. And if so, it might form part of the state of an > optimised list implementation. I'll change this one to "The entries themselves...." But we really want extract-and-copy semantics for the keys and values, explicitly leaving the entries behind. This is important if actual Map.Entry objects are passed in. Consider an instance of AbstractMap.SimpleEntry, which is mutable, or some other implementation of Map.Entry for which we can't make any guarantees. It's also important for serializability. The return value of Map.entry() is not serializable, but we want the resulting Map to be serializable if possible. So we need to extract the keys and values. In a value-typed future, if what's passed in really are values, then it's kind of nonsensical to talk about "the entries themselves" since they have no identity. But the requirement is necessary for objects. > The use of looks like it should have an extra space after the comma to me. Old habit of mine. But the JDK code base is remarkably inconsistent about this... it seems like most generics code has no spaces if they are all one-letter type variables, but it has spaces if there are type bounds or (multi-letter) concrete type names. This is a pretty loose convention, though, if that. In any case I've added spaces and I've fixed up the rest of the file. > I prefer to avoid apostrophes in docs > "the map's key type" -> "the key type of the map" > "the first mapping's key" -> "the key of the first mapping" Ugh. OK, I've indulged you with the other editorial changes, but this one goes too far. :-) What's the rationale for this preference? Most cleanups suggested by you and others all make sense and conform to established conventions, but I don't think I've ever heard of this one before. > I note that java.util.Stream uses empty() but this API uses of() for > the empty case. I can see both points of view and don't have much of a > preference. Is consistency with Stream needed? Good point. I was aware of Stream.empty(), and I recall your early proposal had List/Set/Map.empty(). When I started on the first prototype, though, it seemed most natural to have the zero-arg of() be named consistently with the other overloads. That seems like it outweighs the inconsistency with Stream.of()/Stream.empty(). (I'll note that Stream.of() with zero args works, at the cost of creating an empty array.) > KeyValueHolder needs a

at line 41 Fixed. Thanks, s'marks From huizhe.wang at oracle.com Fri Dec 4 23:18:25 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 04 Dec 2015 15:18:25 -0800 Subject: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518 In-Reply-To: <5660DD92.8070506@oracle.com> References: <5660DD92.8070506@oracle.com> Message-ID: <56621F41.7070800@oracle.com> Hi Aleksej, First of all, I'm not a reviewer for 8u. The test is fine in proving that no NPE is thrown, which indicates the 2nd nodeset is not null. However, there's a 2nd aspect of this: it should be empty. I suggest improving the test so that it further proves that it's not only "not null" but indeed empty. To do that, you may change the 1st nodeset to return meaningful result to show that the leading function returns the 1st set, which proves that the 2nd is empty. Thanks, Joe On 12/3/2015 4:25 PM, Aleksej Efimov wrote: > Hi, > > Please, help to review and approve JDK-8133924 backport to JDK8. The > source fix is identical to JDK9 changes, but there was no test added > for this issue in JDK9. > > The existing > jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test > was modified to test the reported problem in JDK8 and it is a subject > of review: > http://cr.openjdk.java.net/~aefimov/8133924/8/00 > > No regression tests failures were observed for the proposed fix in > JDK8 + the fix is in JDK9 for 3 months already. > > With Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8133924 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 > > JDK9 Review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html > From aleksej.efimov at oracle.com Fri Dec 4 23:35:30 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sat, 5 Dec 2015 02:35:30 +0300 Subject: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518 In-Reply-To: <56621F41.7070800@oracle.com> References: <5660DD92.8070506@oracle.com> <56621F41.7070800@oracle.com> Message-ID: <56622342.5020204@oracle.com> Hi Joe, Sean, Thank you for the reviews and comments. Joe, Thank you for the suggestion. I added small test changes to address your proposal. New webrev can be found here: http://cr.openjdk.java.net/~aefimov/8133924/8/01/ Best Regards, Aleksej On 12/05/2015 02:18 AM, huizhe wang wrote: > Hi Aleksej, > > First of all, I'm not a reviewer for 8u. > > The test is fine in proving that no NPE is thrown, which indicates the > 2nd nodeset is not null. However, there's a 2nd aspect of this: it > should be empty. I suggest improving the test so that it further > proves that it's not only "not null" but indeed empty. To do that, you > may change the 1st nodeset to return meaningful result to show that > the leading function returns the 1st set, which proves that the 2nd is > empty. > > Thanks, > Joe > > On 12/3/2015 4:25 PM, Aleksej Efimov wrote: >> Hi, >> >> Please, help to review and approve JDK-8133924 backport to JDK8. The >> source fix is identical to JDK9 changes, but there was no test added >> for this issue in JDK9. >> >> The existing >> jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test >> was modified to test the reported problem in JDK8 and it is a subject >> of review: >> http://cr.openjdk.java.net/~aefimov/8133924/8/00 >> >> No regression tests failures were observed for the proposed fix in >> JDK8 + the fix is in JDK9 for 3 months already. >> >> With Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8133924 >> >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 >> >> JDK9 Review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html >> > From mandy.chung at oracle.com Sat Dec 5 00:05:42 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Dec 2015 16:05:42 -0800 Subject: Reference.reachabilityFence In-Reply-To: <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> Message-ID: <5C9099DC-0B11-4765-9AA4-6D81C2CCD682@oracle.com> > On Dec 4, 2015, at 5:47 AM, Paul Sandoz wrote: > >> >> On 3 Dec 2015, at 22:33, Mandy Chung wrote: >> >> >>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: >>> >>> Hi, >>> >>> I have updated the patches: >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ >>> >>> There is now more documentation on Reference (copied and suitable rearranged from 166 Fences.java). The method name remains the same. >>> >> >> I think the addition to the Reference class specification should belong to the reachabilityFence method specification. Any reason why not? > > I thought it would be more visible in the JavaDoc, as it?s there upfront. The api note may get larger if we include some additional real world examples. I don?t have a strong opinion on this, if yours is stronger i will move it :-) > Reference is the best class among other choices to place this reachabilityFence method and not directly tied with the Reference class spec. That?s how I read it. I I think no issue for a method spec contains a long api note. I prefer it to move to the method spec. > > >> Should the reachabilityFence method throw NPE if ref is null? >> > > I am ok with it doing nothing, it?s a performance sensitive method. It means no null checks/de-opts are required and (hand-waving here...) might make it more amenable to optimization see https://bugs.openjdk.java.net/browse/JDK-8130398). > I later also thought performance sensitivity that explain the reason to accept null. It?s fine with me. > > Updated: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ > > reachabilityFence is now annotated with @DontInline (to be pushed real soon now) and the HotSpot changes are no longer needed. Looks fine with me. No need to see any new webrev. Mandy From huizhe.wang at oracle.com Sat Dec 5 00:16:26 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 04 Dec 2015 16:16:26 -0800 Subject: [8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518 In-Reply-To: <56622342.5020204@oracle.com> References: <5660DD92.8070506@oracle.com> <56621F41.7070800@oracle.com> <56622342.5020204@oracle.com> Message-ID: <56622CDA.7030904@oracle.com> On 12/4/2015 3:35 PM, Aleksej Efimov wrote: > Hi Joe, Sean, > Thank you for the reviews and comments. > > Joe, > Thank you for the suggestion. I added small test changes to address > your proposal. New webrev can be found here: > http://cr.openjdk.java.net/~aefimov/8133924/8/01/ Ok, that works. Best, Joe > > Best Regards, > Aleksej > > On 12/05/2015 02:18 AM, huizhe wang wrote: >> Hi Aleksej, >> >> First of all, I'm not a reviewer for 8u. >> >> The test is fine in proving that no NPE is thrown, which indicates >> the 2nd nodeset is not null. However, there's a 2nd aspect of this: >> it should be empty. I suggest improving the test so that it further >> proves that it's not only "not null" but indeed empty. To do that, >> you may change the 1st nodeset to return meaningful result to show >> that the leading function returns the 1st set, which proves that the >> 2nd is empty. >> >> Thanks, >> Joe >> >> On 12/3/2015 4:25 PM, Aleksej Efimov wrote: >>> Hi, >>> >>> Please, help to review and approve JDK-8133924 backport to JDK8. The >>> source fix is identical to JDK9 changes, but there was no test added >>> for this issue in JDK9. >>> >>> The existing >>> jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java >>> test was modified to test the reported problem in JDK8 and it is a >>> subject of review: >>> http://cr.openjdk.java.net/~aefimov/8133924/8/00 >>> >>> No regression tests failures were observed for the proposed fix in >>> JDK8 + the fix is in JDK9 for 3 months already. >>> >>> With Best Regards, >>> Aleksej >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8133924 >>> >>> JDK9 changeset: >>> http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 >>> >>> JDK9 Review thread: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html >>> >> > From stuart.marks at oracle.com Sat Dec 5 00:59:49 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Dec 2015 16:59:49 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5661FA1C.2030008@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> <5661FA1C.2030008@oracle.com> Message-ID: <56623705.5080207@oracle.com> On 12/4/15 12:39 PM, Roger Riggs wrote: > Hi Stuart, > > List.java: > > - The varargs form would be more readable if the parameter was named > 'elements' instead of 'es'. > - ditto Map and Set Renamed. > Map.java: > > - in the @returns I would say returns "a {@code Map}" to be explicit about the > return type. > (ditto in Set and List to reinforce the return type) Markup updated. > - the exception for duplicate keys that is thrown says duplicate elements but > it is really the keys that are duplicated. > In the @throws clause it would be more readable to say "if there are > duplicates in the keys" > or as is appears in Set: "if there are any duplicate elements" Updated wording in @throws clauses and in the exception message. > Reviewed: +1 Thanks, s'marks From mandy.chung at oracle.com Sat Dec 5 01:35:08 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Dec 2015 17:35:08 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5661C5A5.9020904@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> Message-ID: <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> > On Dec 4, 2015, at 8:56 AM, Roger Riggs wrote: > > > [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html 67 * Unless otherwise noted, passing a {@code null} argument to a constructor or 68 * method in any class or interface in this package will cause a s/in any class or interface in this package/in this class/ 100 * Returns a new Cleaner. s/Cleaner/{@code Cleaner} For the create() factory method: should it prepare for future optimization (e.g. returning a shared Cleaner object, or multiple Cleaner object sharing among one or more dedicated threads)? Would it be better not to require a new thread be created and also ?Return a Cleaner? instead of ?a new Cleaner?. 105 * of the thread is set to the system class loader. - can you add a link to ClassLoader#getSystemClassLoader 106 * The thread has no permissions, enforced only if a 107 * {@link java.lang.System#setSecurityManager(SecurityManager) SecurityManager is set}. I realized I didn?t bring this up in my previous comment. I meant to say that it may be fine not to mention about ?inherited ACC? and permissions. I included that sentence just in case there is a reason it needs. I am not aware of any specification talking about the inherited ACC of a newly created thread. This sentence can be removed. Maybe you can add a @apiNote to explain it. > Which brings up a gap in the specification of create() that it can throw exceptions related > to creation and starting of threads, including SecurityExceptions, IllegalThreadStateException, etc. Regarding the exceptions if threadFactory.newThread returns a started thread, @throws IllegalThreadStateException is a good one and I think that?s all. A new thread implies ?not started? - perhaps adding a link to Thread.State.NEW. I did look at whether the security exception will be thrown and I don?t see any. You should double check. Cleanable is missing @since 9 164 * Cleanable is a registered cleaning function. I read ?thunk? passed to Cleaner::register is the ?registered cleaning function?. What about: {@code Cleanable} represents the object and its associated cleaning function registered in a {@code Cleaner} Mandy From sunqihui at huawei.com Sat Dec 5 03:30:39 2015 From: sunqihui at huawei.com (Sunqihui (Solomon)) Date: Sat, 5 Dec 2015 03:30:39 +0000 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <56620E47.1060907@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> Message-ID: <4F8D42992718EB47B72C0E520FD85438CAD61F39@SZXEMA501-MBX.china.huawei.com> I'd like agree with Goetz's opinion, Collectors like in Clojure 1.7 Transducers. Java 8 have some transducers, such as Comparator.comparing, java.util.stream.Collectors.mapping?reducing?groupingBy?partitioningBy?summing ?Collectors.flatMapping(in Java 9) etc. I think a Java 8 Collector is a "reducing function", it's supplier fn is arity-0, it's accumulator fn is arity-2,it's arity-1 fn is finisher or completion. And Stream.collect() is similar to Clojure into function. see also: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/InsideTransducers.md Best regards, Solomon From amaembo at gmail.com Sat Dec 5 03:31:36 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sat, 5 Dec 2015 09:31:36 +0600 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: Message-ID: <151686327.20151205093136@gmail.com> Hello! Sounds reasonable. I already have such collector in my library [1]. As an alternative solution for your problem I have groupingBy collector with domain parameter [2], so you can specify the set of possible keys and all keys are guaranteed to be created: Set getAllDepartmentsSet() {...} Map map = emps.stream() .filter(e -> e.getSalary() > 2000) .collect(MoreCollectors.groupingBy(Employee::getDepartment, getAllDepartmentsSet(), counting())); With best regards, Tagir Valeev. [1] http://amaembo.github.io/streamex/javadoc/one/util/streamex/MoreCollectors.html#filtering-java.util.function.Predicate-java.util.stream.Collector- [2] http://amaembo.github.io/streamex/javadoc/one/util/streamex/MoreCollectors.html#groupingBy-java.util.function.Function-java.util.Set-java.util.stream.Collector- S> Hi, core-libs-dev and Brian, Paul, S> I'd like to propose adding filtering method to Collectors. S> When I consider the operation what is "grouping the number of employees S> whose income is over 2000 by the depertment from employees", we have to S> write following because there is no way to filter for Collector: S> (Note: In this case, we need the entry which the value is 0) S> Map map = emps.stream() S> .collect(groupingBy(Employee::getDepartment, S> collectingAndThen(toList(), S> es -> es.stream().filter(e -> e.getSalary() > 2000).count()))); S> When I add filtering like following to Collectors, we can write it easy, S> and it would be more efficient. S> public static S> Collector filtering(Predicate filter, S> Collector downstream) { S> BiConsumer downstreamAccumulator = S> downstream.accumulator(); S> return new CollectorImpl<>(downstream.supplier(), S> (r, t) -> { S> if (filter.test(t)) { S> downstreamAccumulator.accept(r, S> t); S> } S> }, S> downstream.combiner(), S> downstream.finisher(), S> downstream.characteristics()); S> } S> Map map = emps.stream() S> .collect(groupingBy(Employee::getDepartment, S> filtering(e -> e.getSalary() > 2000, counting()))); S> Here is patch: S> webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ S> bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 S> Could you consider this patch and proposal? S> Regards, S> shinyafox(Shinya Yoshida) From huaming.li at oracle.com Sat Dec 5 05:00:44 2015 From: huaming.li at oracle.com (Hamlin Li) Date: Sat, 5 Dec 2015 13:00:44 +0800 Subject: JDK 9 RFR of JDK-8144321: Improve existent tests to check the exact line numbers in Stack Frame. Message-ID: <56626F7C.7070901@oracle.com> Hi all, Would you please help to review the test development of https://bugs.openjdk.java.net/browse/JDK-8144321. webrev : http://cr.openjdk.java.net/~mli/8144321/webrev.00/ Thank you -Hamlin From daniel.fuchs at oracle.com Sat Dec 5 10:35:28 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 5 Dec 2015 11:35:28 +0100 Subject: JDK 9 RFR of JDK-8144321: Improve existent tests to check the exact line numbers in Stack Frame. In-Reply-To: <56626F7C.7070901@oracle.com> References: <56626F7C.7070901@oracle.com> Message-ID: <5662BDF0.5040400@oracle.com> HI Hamlin, If I understand well any line, comment, etc, added to the test in the future is likely to make the tests fail because the line numbers will no longer match. I have seen other tests (I think they where compiler tests) which exhibited such a characteristic, but those had a big warning in their summary to warn maintainer that the tests were dependent on line numbers. If you can't find a way to make these test independent of line numbers, then at least there should be a big warning in the test summary, together with instruction on how to figure out which values to put in the annotation... One possibility to avoid having the test depend on hardcode line numbers could be to embed some logic in the test to make it process (read) its own source file to discover the actual line numbers at run time and generate some kind of data file/or static Map that StackFrameAnnotationUtil could in turn read to get the expected line number. For instance, instead of embedding the real number, the annotation could embed an index, and the corresponding line could have a marker comment at the end referring to the index... e.g.: 93 @StackFrameAnnotation(lineNumbers = {1, 2}) ... 120 walker.walk(s -> { // should check this line number in @StackFrameAnnotation. // @LINE#1 121 s.filter(f -> f.getClassName().startsWith("AcrossThreads$")) 122 .forEach(f -> StackFrameAnnotationUtils.verifyLineNumber( 123 f.getClassName(), 124 f.getMethodName(), 125 f.getLineNumber().getAsInt())); 126 return null; 127 }); 128 } else { 129 assertWalker(walker, n); // should check this line number in @StackFrameAnnotation. // @LINE#2 130 } The test could then first process its source file to figure out that @LINE#1 is at line 120 and @LINE#2 is at line 129, and then build a map { 1 -> 120, 2 -> 129 } which StackFrameAnnotationUtil would use to get the real line number from the index it finds in the annotation... Directly hardcoding line numbers inside annotations in the test looks a bit fragile. Maybe someone else on the list will be able to suggest even better ideas :-) best regards, -- daniel On 12/5/15 6:00 AM, Hamlin Li wrote: > Hi all, Would you please help to review the test development of > https://bugs.openjdk.java.net/browse/JDK-8144321. webrev : > http://cr.openjdk.java.net/~mli/8144321/webrev.00/ Thank you -Hamlin From peter.levart at gmail.com Sat Dec 5 11:12:20 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 5 Dec 2015 12:12:20 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> Message-ID: <5662C694.9040306@gmail.com> On 12/04/2015 10:58 PM, Mandy Chung wrote: > "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? > > The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. > > Mandy Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) Regards, Peter From paul.sandoz at oracle.com Sat Dec 5 13:18:41 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sat, 5 Dec 2015 14:18:41 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <56620E47.1060907@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> Message-ID: <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> > On 4 Dec 2015, at 23:05, Brian Goetz wrote: > > This seems reasonable; mapping() already exists for use in this space (as a combinator for the downstream collector of groupingBy and friends), filtering() is also reasonable in this context. > Agreed, i like it, and will review it more closely next week. FWIW one can use Collectors.flatMapping to achieve similar functionality, but it?s a little awkward for such filtering use-cases. Thanks, Paul. From dl at cs.oswego.edu Sat Dec 5 16:23:49 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 5 Dec 2015 11:23:49 -0500 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <565FD8C8.6020105@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> <565FD8C8.6020105@oracle.com> Message-ID: <56630F95.4080908@cs.oswego.edu> On 12/03/2015 12:53 AM, David Holmes wrote: > On 3/12/2015 12:56 AM, Doug Lea wrote: >> In the absence of any of: tail-recursion support, reliable cleanup, >> or growable stacks, it seems reasonable to choose larger default >> stack sizes so that these long but finite chains of completions >> are far less likely to hit SOE. >> >> On 32bit systems the 1MB limit is completely defensible. But expanding >> to say 64MB on 64bit systems would reduce practical encounters with >> SOE in these kinds of constructions by a factor of 64 or so. >> Is there any reason not to do this? > > The same discussion on the concurrency-interest mailing list seems to indicate > that there are indeed reasons to not do this. > > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html > And all of them amount to arguments that it could interfere with other configuration assumptions and practices. Perhaps hotspot could at least support simpler ways that fluent/functionally-flavored programs could override defaults to start up with more friendly settings (as in "java -XX:+FP" ...) -Doug From mandy.chung at oracle.com Sat Dec 5 16:28:27 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 5 Dec 2015 08:28:27 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5662C694.9040306@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> Message-ID: > On Dec 5, 2015, at 3:12 AM, Peter Levart wrote: > > > > On 12/04/2015 10:58 PM, Mandy Chung wrote: >> "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? >> >> The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. >> >> Mandy >> > > Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) That?s right. There may likely be some reason why it takes the null ReferenceQueue as noted in this comment in sun.misc.Cleaner: // Dummy reference queue, needed because the PhantomReference constructor // insists that we pass a queue. Mandy From Roger.Riggs at oracle.com Sat Dec 5 17:26:40 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 5 Dec 2015 12:26:40 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> Message-ID: <56631E50.2090107@oracle.com> Hi Mandy, Thanks for the comments, Updated the artifacts: [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/04/2015 08:35 PM, Mandy Chung wrote: >> On Dec 4, 2015, at 8:56 AM, Roger Riggs wrote: >> >> >> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > 67 * Unless otherwise noted, passing a {@code null} argument to a constructor or > 68 * method in any class or interface in this package will cause a > > s/in any class or interface in this package/in this class/ right > > 100 * Returns a new Cleaner. > s/Cleaner/{@code Cleaner} right > > For the create() factory method: should it prepare for future optimization (e.g. returning a shared Cleaner object, or multiple Cleaner object sharing among one or more dedicated threads)? Would it be better not to require a new thread be created and also ?Return a Cleaner? instead of ?a new Cleaner?. You will remember that a common cleaner method was proposed a couple of months ago and it was removed because it was thought to be an attractive nuisance. If any library or application can use it, then bugs, intentional or not can disrupt the cleaning mechanism. Such a cleaner would need to be written very defensively and be prepared for cleaning functions to block or not return. There is no way to be fully robust if some code is very badly behaved on a thread; threads can not be stopped or destroyed effectively. It was considered at that time that every library and application needed to give adequate thought to its cleaning needs and implement accordingly. If there is to be a common cleaner provided, it should be a different factory method that explicitly returns a common cleaner. For example, public static Cleaner commonCleaner() {...} > > 105 * of the thread is set to the system class loader. > > - can you add a link to ClassLoader#getSystemClassLoader ok ClassLoader#getSystemClassLoader > > 106 * The thread has no permissions, enforced only if a > 107 * {@link java.lang.System#setSecurityManager(SecurityManager) SecurityManager is set}. > > I realized I didn?t bring this up in my previous comment. I meant to say that it may be fine not to mention about ?inherited ACC? and permissions. I included that sentence just in case there is a reason it needs. I am not aware of any specification talking about the inherited ACC of a newly created thread. This sentence can be removed. Maybe you can add a @apiNote to explain it. It should be clear and specified what access control is effective for the new thread. Since InnocuousThread is non-public, it is uncomfortable to refer to it (as does ForkJoinWorkerThread) Next best is to describe the attributes of the threads it produces. > >> Which brings up a gap in the specification of create() that it can throw exceptions related >> to creation and starting of threads, including SecurityExceptions, IllegalThreadStateException, etc. > Regarding the exceptions if threadFactory.newThread returns a started thread, @throws IllegalThreadStateException is a good one and I think that?s all. A new thread implies ?not started? - perhaps adding a link to Thread.State.NEW. I did look at whether the security exception will be thrown and I don?t see any. You should double check. For the default threadFactory, there should be no exceptions, between a clean thread state and doPrivileged to create the thread. But for the create(ThreadFactory) method, SecurityExceptions could occur; and IllegalThreadStateException if it was started. > > Cleanable is missing @since 9 fixed > > 164 * Cleanable is a registered cleaning function. > > I read ?thunk? passed to Cleaner::register is the ?registered cleaning function?. What about: > > {@code Cleanable} represents the object and its associated cleaning function registered in a {@code Cleaner} a bit more concise and aligned with the description of register(). {@code Cleanable} represents an object and a cleaning function registered in a {@code Cleaner}. The only function available through the Cleanable is the cleaning function. Thanks, Roger From peter.levart at gmail.com Sat Dec 5 18:23:15 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 5 Dec 2015 19:23:15 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> Message-ID: <56632B93.6070105@gmail.com> On 12/05/2015 05:28 PM, Mandy Chung wrote: >> On Dec 5, 2015, at 3:12 AM, Peter Levart wrote: >> >> >> >> On 12/04/2015 10:58 PM, Mandy Chung wrote: >>> "It is possible to create a phantom reference with a null queue, but such a reference is completely useless: Its get method will always return null and, since it does not have a queue, it will never be enqueued.? >>> >>> The puzzling part to me is why PhantomReference accepts null ReferenceQueue. I can?t evaluate how high of the source incompatibility risk if we fixed it but I may propose that in a future release until I have cycle. >>> >>> Mandy >>> >> Well, it is not completely useless for PhantomReference to accept null ReferenceQueue. It's sometimes useful to have a common subtype of PhantomReference where most of instances perform a function of PhantomReference, but some instances are just there to provide the "glue" in the data structure. See the implementation of java.lang.ref.Cleaner and it's "root" nodes of a doubly-linked list ;-) > That?s right. > > There may likely be some reason why it takes the null ReferenceQueue as noted in this comment in sun.misc.Cleaner: > // Dummy reference queue, needed because the PhantomReference constructor > // insists that we pass a queue. > > Mandy Digging up the src.jar of JDK 1.2.2, here's what the constructor of PhantomReference looked like: /** * Creates a new phantom reference that refers to the given object and * is registered with the given queue. * * @throws NullPointerException If the queue argument * is null */ public PhantomReference(Object referent, ReferenceQueue q) { super(referent, q); } ...so it seems Mark wanted PhantomReference constructor to throw NPE. But implementation did not do that (here's also the constructor of Reference): Reference(Object referent, ReferenceQueue queue) { this.referent = referent; if (referent == null) { /* Immediately make this instance inactive */ this.queue = ReferenceQueue.NULL; this.next = this; } else { this.queue = (queue == null) ? ReferenceQueue.NULL : queue; this.next = null; } } ...and so the spec. has probably been modified to follow the standing behavior. Regards, Peter From martijnverburg at gmail.com Sun Dec 6 09:37:23 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 6 Dec 2015 09:37:23 +0000 Subject: Java language and API improvements In-Reply-To: References: Message-ID: Hi Alberto, Further to this, all of these have been proposed in one form or another previously during Project Coin during Java 7's development. I suggest you have a look at the old coin-dev archives (http://mail.openjdk.java.net/ pipermail/coin-dev/) to see why they weren't taken on board (or were deferred). Cheers, Martijn On 4 December 2015 at 18:28, Jonathan Yu wrote: > Hi Alberto, > > It might be easier to discuss these proposals by separating them into > individual emails, to help keep things focussed. I'm not even sure if this > is the right list for Java language discussions. > > I'm not an expert but just sharing some quick thoughts... > > On Fri, Dec 4, 2015 at 10:22 AM, Alberto Otero Rodr?guez < > alber84ou at gmail.com> wrote: > > > > *3) Switch with blocks* > > > > I think there should be a switch made with blocks in order to permit > > using variables with the same name and avoid the problems of not putting > a > > break. It would be something like: > > > > switch(x) > > { > > case(1) > > { > > int i = 1; > > ... > > } > > case(2) > > { > > int i = 2; > > ... > > } > > default > > { > > ... > > } > > } > > > > This should already be doable today, e.g. > > switch (x) { > case 1: { > int i = 1; > break; > } > case 2: { > int i = 2; > break; > } > > The "break" part is unfortunate but cannot be changed without breaking > existing code, since code that currently falls through would suddenly start > behaving differently. > > > > *4) Multiple condition ternary operator* > > > > I think it would be useful to be able to do this: > > > > String str = condition1 \ condition2 ? stringCondition1 : > > stringCondition2 : stringElse; > > > > > > Instead of: > > > > String str = null; > > if(condition1) > > { > > str = stringCondition1; > > } > > else if(condition2) > > { > > str = stringCondition2; > > }. > > else > > { > > str = stringElse; > > } > > > > Personally, I find even a single ternary operator to sometimes be a bit > hard to follow in code, and I think having multiple like this would be > worse. It can also make stepping through line-by-line in a debugger more > difficult (a reason that I like to use lots of intermediate variables), > even if it results in more lines of code. > > Cheers, > > Jonathan > From amaembo at gmail.com Sun Dec 6 12:21:51 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sun, 6 Dec 2015 18:21:51 +0600 Subject: Pattern.splitAsStream JavaDoc doubt Message-ID: <95164276.20151206182151@gmail.com> Hello! Currently Pattern.splitAsStream JavaDoc says [1]: *

If the input sequence is mutable, it must remain constant during the * execution of the terminal stream operation. Otherwise, the result of the * terminal stream operation is undefined. However in reality the sequence must remain constant from the stream creation till the end of the terminal operation. Let's check: public static void main(String[] args) { StringBuilder sb = new StringBuilder("a,b,c,d,e"); Stream stream = Pattern.compile(",").splitAsStream(sb); // Modify the CharSequence after stream creation sb.setLength(3); // During the terminal operation it remains constant stream.forEach(System.out::println); } The result is: a Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 3 at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:210) at java.lang.StringBuilder.charAt(StringBuilder.java:76) ... So I feel either the JavaDoc or the implementation should be changed. Changing the implementation to fit the JavaDoc is quite simple. See the attached pattern-patch.txt and pattern-patch2.txt for two possible alternatives. What do you think? With best regards, Tagir Valeev. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/3c3a5343044c/src/java.base/share/classes/java/util/regex/Pattern.java#l5803 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pattern-patch.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pattern-patch2.txt URL: From david.holmes at oracle.com Sun Dec 6 23:52:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 09:52:42 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5661FEE5.2040108@oracle.com> References: <5661FEE5.2040108@oracle.com> Message-ID: <5664CA4A.1090704@oracle.com> Hi Chris, On 5/12/2015 7:00 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8144677 > http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ > > Tested with JPRT with: > ? "-testset hotspot" > ? "-testset svc" > ? "-testset chris" from the example custom testset provided in the CR. > ? no testset specified Looks good! > BTW, if anyone knows of an "include" mechanism for jprt.properties, Properties files do not have an include mechanism. See: http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- Thanks, David > please let me know. Although that won't change the need for the above > changes, it would make it possible to put custom testsets in a file > rather than having to paste them in your ~/.jprt.properties file. > > thanks, > > Chris > > From david.holmes at oracle.com Mon Dec 7 00:46:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 10:46:21 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56631E50.2090107@oracle.com> References: <560D3F61.6040607@Oracle.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> Message-ID: <5664D6DD.9010709@oracle.com> Hi Roger, Sorry to be late here but was trying not to get involved :) It is already implicit that ThreadFactory.newThread should return unstarted threads - that is what a new Thread is - so I don't think IllegalThreadStateException needs to be documented here as it is documenting behaviour of a broken ThreadFactory (and a broken ThreadFactory could throw anything) . Also the no-arg cleaner() can also throw SecurityException. Also this: 127 * On each call the {@link ThreadFactory#newThread(Runnable) thread factory} 128 * should return a {@link Thread.State#NEW new thread} with an appropriate 129 * {@linkplain Thread#getContextClassLoader context class loader}, 130 * {@linkplain Thread#getName() name}, 131 * {@linkplain Thread#getPriority() priority}, 132 * permissions, etc. then begs the questions as to what is "appropriate". I think this can be said much more simply as: "The ThreadFactory must provide a Thread that is suitable for performing the cleaning work". Though even that raises questions. I'm not sure why a ThreadFactory is actually needed here ?? Special security context? If so that could be mentioned, but I don't think name or priority need to be discussed. Thanks, David On 6/12/2015 3:26 AM, Roger Riggs wrote: > Hi Mandy, > > Thanks for the comments, > > Updated the artifacts: > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > > > On 12/04/2015 08:35 PM, Mandy Chung wrote: >>> On Dec 4, 2015, at 8:56 AM, Roger Riggs wrote: >>> >>> >>> [1] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> [2] http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> 67 * Unless otherwise noted, passing a {@code null} argument to a >> constructor or >> 68 * method in any class or interface in this package will cause a >> >> s/in any class or interface in this package/in this class/ > right >> >> 100 * Returns a new Cleaner. >> s/Cleaner/{@code Cleaner} > right >> >> For the create() factory method: should it prepare for future >> optimization (e.g. returning a shared Cleaner object, or multiple >> Cleaner object sharing among one or more dedicated threads)? Would >> it be better not to require a new thread be created and also ?Return a >> Cleaner? instead of ?a new Cleaner?. > > You will remember that a common cleaner method was proposed a couple of > months ago > and it was removed because it was thought to be an attractive nuisance. > If any library or application can use it, then bugs, intentional or not > can disrupt the cleaning > mechanism. Such a cleaner would need to be written very defensively and > be prepared for > cleaning functions to block or not return. There is no way to be fully > robust if some code > is very badly behaved on a thread; threads can not be stopped or > destroyed effectively. > It was considered at that time that every library and application needed > to give adequate > thought to its cleaning needs and implement accordingly. > > If there is to be a common cleaner provided, it should be a different > factory method that explicitly > returns a common cleaner. For example, > public static Cleaner commonCleaner() {...} > >> >> 105 * of the thread is set to the system class loader. >> >> - can you add a link to ClassLoader#getSystemClassLoader > ok ClassLoader#getSystemClassLoader >> >> 106 * The thread has no permissions, enforced only if a >> 107 * {@link >> java.lang.System#setSecurityManager(SecurityManager) SecurityManager >> is set}. >> >> I realized I didn?t bring this up in my previous comment. I meant to >> say that it may be fine not to mention about ?inherited ACC? and >> permissions. I included that sentence just in case there is a reason >> it needs. I am not aware of any specification talking about the >> inherited ACC of a newly created thread. This sentence can be >> removed. Maybe you can add a @apiNote to explain it. > It should be clear and specified what access control is effective for > the new thread. > Since InnocuousThread is non-public, it is uncomfortable to refer to it > (as does ForkJoinWorkerThread) > Next best is to describe the attributes of the threads it produces. > >> >>> Which brings up a gap in the specification of create() that it can >>> throw exceptions related >>> to creation and starting of threads, including SecurityExceptions, >>> IllegalThreadStateException, etc. >> Regarding the exceptions if threadFactory.newThread returns a started >> thread, @throws IllegalThreadStateException is a good one and I think >> that?s all. A new thread implies ?not started? - perhaps adding a >> link to Thread.State.NEW. I did look at whether the security >> exception will be thrown and I don?t see any. You should double check. > For the default threadFactory, there should be no exceptions, between a > clean thread state > and doPrivileged to create the thread. > > But for the create(ThreadFactory) method, SecurityExceptions could > occur; and IllegalThreadStateException if it was started. >> >> Cleanable is missing @since 9 > fixed >> >> 164 * Cleanable is a registered cleaning function. >> >> I read ?thunk? passed to Cleaner::register is the ?registered cleaning >> function?. What about: >> >> {@code Cleanable} represents the object and its associated cleaning >> function registered in a {@code Cleaner} > a bit more concise and aligned with the description of register(). > > {@code Cleanable} represents an object and a cleaning function > registered in a {@code Cleaner}. > > The only function available through the Cleanable is the cleaning function. > > Thanks, Roger > > From david.holmes at oracle.com Mon Dec 7 00:51:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 10:51:19 +1000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <56630F95.4080908@cs.oswego.edu> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu> <56525823.6010506@cs.oswego.edu> <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com> <56572F4E.8050603@oracle.com> <565F0698.7080600@cs.oswego.edu> <565FD8C8.6020105@oracle.com> <56630F95.4080908@cs.oswego.edu> Message-ID: <5664D807.9080600@oracle.com> On 6/12/2015 2:23 AM, Doug Lea wrote: > On 12/03/2015 12:53 AM, David Holmes wrote: >> On 3/12/2015 12:56 AM, Doug Lea wrote: >>> In the absence of any of: tail-recursion support, reliable cleanup, >>> or growable stacks, it seems reasonable to choose larger default >>> stack sizes so that these long but finite chains of completions >>> are far less likely to hit SOE. >>> >>> On 32bit systems the 1MB limit is completely defensible. But expanding >>> to say 64MB on 64bit systems would reduce practical encounters with >>> SOE in these kinds of constructions by a factor of 64 or so. >>> Is there any reason not to do this? >> >> The same discussion on the concurrency-interest mailing list seems to >> indicate >> that there are indeed reasons to not do this. >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html >> >> > > And all of them amount to arguments that it could interfere > with other configuration assumptions and practices. > Perhaps hotspot could at least support simpler ways that > fluent/functionally-flavored programs could override defaults > to start up with more friendly settings (as in "java -XX:+FP" ...) So some kind of guided ergonomics beyond that implied by server/client or raw machine parameters? Is there such a set that would be of general enough use to warrant something like -XX:+FP, or should these simply be set in a configuration file determined at deployment time? Thanks, David > > -Doug > > > > From bitterfoxc at gmail.com Mon Dec 7 02:45:05 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 7 Dec 2015 11:45:05 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> Message-ID: Hi, I'd like to wait for the review, but I have a trivial question: Which @since is preferred, 1.9 or 9? For ex, at Optional#or and stream, @since 9 is used. On the other hand, at Collectors#flatMap, @since 1.9 is used. Regards, shinyafox(Shinya Yoshida) 2015-12-05 22:18 GMT+09:00 Paul Sandoz : > > On 4 Dec 2015, at 23:05, Brian Goetz wrote: > > This seems reasonable; mapping() already exists for use in this space (as > a combinator for the downstream collector of groupingBy and friends), > filtering() is also reasonable in this context. > > > Agreed, i like it, and will review it more closely next week. > > FWIW one can use Collectors.flatMapping to achieve similar functionality, > but it?s a little awkward for such filtering use-cases. > > Thanks, > Paul. > From sundararajan.athijegannathan at oracle.com Mon Dec 7 03:17:26 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 7 Dec 2015 08:47:26 +0530 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> <56611805.4030405@oracle.com> Message-ID: <5664FA46.4050004@oracle.com> Hi, Please review the updated webrevs http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.01/ http://cr.openjdk.java.net/~sundar/8143404/top/webrev.01/ http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ Thanks, -Sundar On 12/4/2015 12:12 PM, Mandy Chung wrote: > Right. Run this on your repo after removing applescript > $ jdeps $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.os > > You will see the dependency. It?s okay to remain the qualified exports. But you should remove the dependency on java.desktop and java.scripting. > >>> jdk/make/lib/Lib-jdk.deploy.osx.gmk > I assume libapplescriptengine should be removed too. So this makefile needs update too. > > Mandy > >> On Dec 3, 2015, at 8:35 PM, Sundararajan Athijegannathan wrote: >> >> I'm only removing applescript code. Not all of jdk.deploy.osx code (collection etc). Not sure if jdk.deploy.osx dependencies can be completely removed (yet). Removal of the other stuff has to be another bug. I'll update for other stuff you mentioned. >> >> -Sundar >> >> On 12/4/2015 9:01 AM, Mandy Chung wrote: >>>> On Dec 3, 2015, at 5:41 PM, Sundararajan Athijegannathan wrote: >>>> >>>> Hi, >>>> >>>> Thanks. Updated: >>>> >>>> http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ >>>> http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ >>>> http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ >>>> >>> jdk/src/jdk.deploy.osx/macosx/native/libapplescriptengine >>> - jdk webrev didn?t show they are removed. >>> >>> jdk/make/lib/Lib-jdk.deploy.osx.gmk >>> >>> unshuffle_list.txt >>> 1296 jdk/src/jdk.deploy.osx/macosx/classes/apple/security : jdk/src/macosx/classes/apple/security >>> >>> since you are on this file, do you mind taking out this line as well (which was a leftover from the changeset when moving out the apple security provider to java.abs). >>> >>> modules.xml >>> >>> I believe this should be updated as well and jdk.deploy.osx dependency on java.desktop and java.scripting can be removed. >>> >>> I notice that there are qualified exports from sun.misc to jdk.deploy.osx that looks like they are not needed. Run jdeps on $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.osx from your build will show the new dependency. It?d be good to clean this up but this is not related to this change. It?s okay with me either way. >>> >>> Mandy From huaming.li at oracle.com Mon Dec 7 05:54:34 2015 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 7 Dec 2015 13:54:34 +0800 Subject: JDK 9 RFR of JDK-8144321: Improve existent tests to check the exact line numbers in Stack Frame. In-Reply-To: <5662BDF0.5040400@oracle.com> References: <56626F7C.7070901@oracle.com> <5662BDF0.5040400@oracle.com> Message-ID: <56651F1A.7010107@oracle.com> Hi Daniel, Thanks for reviewing and suggestions, 1> add big warning to warn maintainer that the tests were dependent on line numbers.; 2> verify line numbers by parsing the source code. I think your second suggestion is great! :-), but to keep the logic simple and straight, I prefer your first suggestion which is to add big warning. When tests detect that line numbers are mismatched, there will be detailed error message explaining the reason. webrev : http://cr.openjdk.java.net/~mli/8144321/webrev.01/ Thank you -Hamlin On 2015/12/5 18:35, Daniel Fuchs wrote: > HI Hamlin, > > If I understand well any line, comment, etc, added to the test > in the future is likely to make the tests fail because the line numbers > will no longer match. > > I have seen other tests (I think they where compiler tests) which > exhibited such a characteristic, but those had a big warning in > their summary to warn maintainer that the tests were dependent > on line numbers. > > If you can't find a way to make these test independent of > line numbers, then at least there should be a big warning > in the test summary, together with instruction on how to figure out > which values to put in the annotation... > > One possibility to avoid having the test depend on hardcode line numbers > could be to embed some logic in the test to make it process (read) its > own source > file to discover the actual line numbers at run time and generate some > kind of > data file/or static Map that StackFrameAnnotationUtil could in turn > read to get > the expected line number. > For instance, instead of embedding the real number, the annotation could > embed an index, and the corresponding line could have a marker comment > at the end referring to the index... e.g.: > > 93 @StackFrameAnnotation(lineNumbers = {1, 2}) > ... > > 120 walker.walk(s -> { // should check this line number in > @StackFrameAnnotation. // @LINE#1 > 121 s.filter(f -> f.getClassName().startsWith("AcrossThreads$")) > 122 .forEach(f -> StackFrameAnnotationUtils.verifyLineNumber( > 123 f.getClassName(), > 124 f.getMethodName(), > 125 f.getLineNumber().getAsInt())); > 126 return null; > 127 }); > 128 } else { > 129 assertWalker(walker, n); // should check this line number in > @StackFrameAnnotation. // @LINE#2 > 130 } > > The test could then first process its source file to figure out that @LINE#1 is at line 120 and > @LINE#2 is at line 129, and then build a map { 1 -> 120, 2 -> 129 } which > StackFrameAnnotationUtil would use to get the real line number from the index > it finds in the annotation... > Directly hardcoding line numbers inside annotations in the test looks > a bit fragile. Maybe someone else on the list will be able to suggest > even better ideas :-) best regards, -- daniel On 12/5/15 6:00 AM, > Hamlin Li wrote: >> Hi all, Would you please help to review the test development of >> https://bugs.openjdk.java.net/browse/JDK-8144321. webrev : >> http://cr.openjdk.java.net/~mli/8144321/webrev.00/ Thank you -Hamlin From per.liden at oracle.com Mon Dec 7 07:26:41 2015 From: per.liden at oracle.com (Per Liden) Date: Mon, 7 Dec 2015 08:26:41 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <05734348-D522-464B-9133-CA64793E8979@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56613DD4.40600@oracle.com> <05734348-D522-464B-9133-CA64793E8979@oracle.com> Message-ID: <566534B1.7030401@oracle.com> On 2015-12-04 19:16, Kim Barrett wrote: > On Dec 4, 2015, at 2:16 AM, Per Liden wrote: >> >> On 2015-12-02 19:37, Kim Barrett wrote: >>> Please review this change to PhantomReference processing, changing the >>> GC-based notification to automatically clear the referent. >>> >>> [?] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8071507 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ >> >> test/java/lang/ref/PhantomReferentClearing.java: >> >> 85 // Delete root -> O1, collect, verify P1 notified, P2 not notified. >> 86 O1 = null; >> 87 System.gc(); >> 88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) { >> 89 throw new RuntimeException("P1 not notified by O1 deletion"); >> 90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) { >> 91 throw new RuntimeException("P2 notified by O1 deletion."); >> 92 } >> 93 >> 94 // Delete root -> O2, collect. P2 should be notified. >> 95 O2 = null; >> 96 System.gc(); >> 97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) { >> 98 throw new RuntimeException("P2 not notified by O2 deletion"); >> 99 } >> >> The calls to System.gc() isn't guaranteed to do what the test expects here. As you know, System.gc(), might not actually do anything, depending on which collector is used and the current circumstances (GC locker held, a concurrent GC is already in process, etc). To make the test robust I'd suggest you call System.gc() and check the queue in a loop, and fail after some reasonable amount of time/iterations. > > I'd rather not clutter and uglify this and other tests to deal with a > problem we don't (so far as I can tell) presently actually have. If a > problem does arise, the form of that problem will help guide what the > solution needs to be. I suspect adding something to WhiteBox would be > the proper approach, so that it can be shared with other tests of this > form. We do actually have this problem today, i.e. there are cases where our collectors will not do a "full GC" as a result of a call to System.gc(). One example would be if the GC-locker is active. However, it's seems very unlikely that this particular test would provoking such a condition. Our current WhiteBox API for FullGC is prone to the same issue. Maybe it would be a good idea to strengthen that API and used that in the future for tests like this. I understand if you don't want to take on this problem here and now, given that we have other test which is very similar to this one, and they seem to have worked so far without issues. cheers, /Per From paul.sandoz at oracle.com Mon Dec 7 08:31:59 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Dec 2015 09:31:59 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> Message-ID: <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> > On 7 Dec 2015, at 03:45, ShinyaYoshida wrote: > > Hi, > I'd like to wait for the review, but I have a trivial question: > > Which @since is preferred, 1.9 or 9? > @since 9 > For ex, at Optional#or and stream, @since 9 is used. > On the other hand, at Collectors#flatMap, @since 1.9 is used. > Feel free to update that to 9. I started using @9 a little while ago in anticipation of the new version-string scheme (http://openjdk.java.net/jeps/223 ). I expect there will be a global sweep through the code updating @since tags. Paul. From erik.joelsson at oracle.com Mon Dec 7 08:33:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Dec 2015 09:33:08 +0100 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5661FEE5.2040108@oracle.com> References: <5661FEE5.2040108@oracle.com> Message-ID: <56654444.9050505@oracle.com> On 2015-12-04 22:00, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8144677 > http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ > > Tested with JPRT with: > ? "-testset hotspot" > ? "-testset svc" > ? "-testset chris" from the example custom testset provided in the CR. > ? no testset specified > > BTW, if anyone knows of an "include" mechanism for jprt.properties, > please let me know. Although that won't change the need for the above > changes, it would make it possible to put custom testsets in a file > rather than having to paste them in your ~/.jprt.properties file. > JPRT properties files are pretty special, but to my knowledge, there is no include mechanism. I don't think it would be hard to implement though. /Erik From michael.haupt at oracle.com Mon Dec 7 08:43:16 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 7 Dec 2015 09:43:16 +0100 Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed In-Reply-To: <5661BF14.6070705@oracle.com> References: <5661BF14.6070705@oracle.com> Message-ID: Hi Claes, this is a lower-case review, but thumbs up. Truth or dare. ;-) Best, Michael > Am 04.12.2015 um 17:28 schrieb Claes Redestad : > > Hi, > > please review this issue to remove explicit initialization of MethodHandleImpl, which doesn't seem to be needed after recent j.l.invoke bootstrap improvements. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144723 > Webrev: http://cr.openjdk.java.net/~redestad/8144723/webrev.01/ > > This removes 21 classes from jdk9/dev startup. I additionally identified a few eagerly initialized functions that can be made lazily initialized, which defers 6 classes from loading eagerly in startup tests that use lambdas explicitly. > > Thanks! > > /Claes -- 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 is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Mon Dec 7 08:59:32 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Dec 2015 08:59:32 +0000 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <5664FA46.4050004@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> <56611805.4030405@oracle.com> <5664FA46.4050004@oracle.com> Message-ID: <56654A74.1060305@oracle.com> On 07/12/2015 03:17, Sundararajan Athijegannathan wrote: > Hi, > > Please review the updated webrevs > > http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.01/ > http://cr.openjdk.java.net/~sundar/8143404/top/webrev.01/ > http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ Updated patches lookup good, I think you've got everything now. -Alan. From bitterfoxc at gmail.com Mon Dec 7 08:59:48 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Mon, 7 Dec 2015 17:59:48 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> Message-ID: Hi Paul, Thank you for your answer. I've just updated my webrev to use 9: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.01/ Regards, shinyafox(Shinya Yoshida) 2015-12-07 17:31 GMT+09:00 Paul Sandoz : > > On 7 Dec 2015, at 03:45, ShinyaYoshida wrote: > > Hi, > I'd like to wait for the review, but I have a trivial question: > > Which @since is preferred, 1.9 or 9? > > > @since 9 > > > For ex, at Optional#or and stream, @since 9 is used. > On the other hand, at Collectors#flatMap, @since 1.9 is used. > > > Feel free to update that to 9. > > I started using @9 a little while ago in anticipation of the new > version-string scheme (http://openjdk.java.net/jeps/223). I expect there > will be a global sweep through the code updating @since tags. > > Paul. > > > From chris.hegarty at oracle.com Mon Dec 7 10:18:24 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Dec 2015 10:18:24 +0000 Subject: Pattern.splitAsStream JavaDoc doubt In-Reply-To: <95164276.20151206182151@gmail.com> References: <95164276.20151206182151@gmail.com> Message-ID: <56655CF0.1040703@oracle.com> Tagir, It would seem most useful to update the implementation to match the current spec. To that end, your first patch looks like the most appropriate change, pattern-patch.txt. -Chris. On 06/12/15 12:21, Tagir F. Valeev wrote: > Hello! > > Currently Pattern.splitAsStream JavaDoc says [1]: > > *

If the input sequence is mutable, it must remain constant during the > * execution of the terminal stream operation. Otherwise, the result of the > * terminal stream operation is undefined. > > However in reality the sequence must remain constant from the stream > creation till the end of the terminal operation. Let's check: > > public static void main(String[] args) { > StringBuilder sb = new StringBuilder("a,b,c,d,e"); > Stream stream = Pattern.compile(",").splitAsStream(sb); > // Modify the CharSequence after stream creation > sb.setLength(3); > // During the terminal operation it remains constant > stream.forEach(System.out::println); > } > > The result is: > a > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 3 > at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:210) > at java.lang.StringBuilder.charAt(StringBuilder.java:76) > ... > > So I feel either the JavaDoc or the implementation should be changed. > Changing the implementation to fit the JavaDoc is quite simple. See > the attached pattern-patch.txt and pattern-patch2.txt for two possible > alternatives. > > What do you think? > > With best regards, > Tagir Valeev. > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/3c3a5343044c/src/java.base/share/classes/java/util/regex/Pattern.java#l5803 > From david.holmes at oracle.com Mon Dec 7 11:18:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 21:18:51 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56654444.9050505@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> Message-ID: <56656B1B.2020107@oracle.com> On 7/12/2015 6:33 PM, Erik Joelsson wrote: > > > On 2015-12-04 22:00, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8144677 >> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >> >> Tested with JPRT with: >> ? "-testset hotspot" >> ? "-testset svc" >> ? "-testset chris" from the example custom testset provided in the CR. >> ? no testset specified >> >> BTW, if anyone knows of an "include" mechanism for jprt.properties, >> please let me know. Although that won't change the need for the above >> changes, it would make it possible to put custom testsets in a file >> rather than having to paste them in your ~/.jprt.properties file. >> > JPRT properties files are pretty special, but to my knowledge, there is > no include mechanism. I don't think it would be hard to implement though. They aren't really special they just use Properties.loadFromStream (or something like that). To do an include mechanism you'd have to implement all the reading and parsing logic yourself. David > /Erik > From chris.hegarty at oracle.com Mon Dec 7 11:29:56 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Dec 2015 11:29:56 +0000 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5660E518.4040705@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> Message-ID: <56656DB4.9060702@oracle.com> 102 *

  • They are serializable if all elements are serializable. To avoid any ambiguity or "leaking", would it make sense to have the serial form of these types be defined, in a similar manner to what was done for Serializable types in the java.time package [1]. This can be done as a follow up, so as to not block your progress. -Chris. [1] https://docs.oracle.com/javase/8/docs/api/serialized-form.html#java.time.Ser. On 04/12/15 00:58, Stuart Marks wrote: > ... > > I still need an official OpenJDK Reviewer. > API: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html > > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ > > Thanks, > > s'marks > > > On 12/1/15 6:35 PM, Stuart Marks wrote: >> Hi all, >> >> Thanks for the previous round of review comments. Here's an updated >> API and >> implementation for review. >> >> I've run specdiff with the --hu ("hide unchanged") option, so only the >> bits of >> the specification that have changed are shown. As before, though, >> please ignore >> the spurious change to EnumSet caused by a javadoc bug. >> >> API changes: >> - add clarifying notes on immutability >> - remove wording that implied creation of new objects >> - add "value-based" disclaimers >> - add ordering specification for List and non-ordering disclaimers >> for Set and Map >> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >> instead >> it extracts keys and values >> - Map.Entry instances returned from Map.entry() are *not* serializable >> >> Other: >> - markup cleanups >> - small implementation cleanups >> >> JEP: >> >> http://openjdk.java.net/jeps/269 >> >> API spec (basically List, Map, and Set): >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >> >> Thanks, >> >> s'marks From erik.joelsson at oracle.com Mon Dec 7 11:39:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Dec 2015 12:39:25 +0100 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56656B1B.2020107@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> <56656B1B.2020107@oracle.com> Message-ID: <56656FED.5050105@oracle.com> On 2015-12-07 12:18, David Holmes wrote: > On 7/12/2015 6:33 PM, Erik Joelsson wrote: >> >> >> On 2015-12-04 22:00, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>> >>> Tested with JPRT with: >>> ? "-testset hotspot" >>> ? "-testset svc" >>> ? "-testset chris" from the example custom testset provided in the >>> CR. >>> ? no testset specified >>> >>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>> please let me know. Although that won't change the need for the above >>> changes, it would make it possible to put custom testsets in a file >>> rather than having to paste them in your ~/.jprt.properties file. >>> >> JPRT properties files are pretty special, but to my knowledge, there is >> no include mechanism. I don't think it would be hard to implement >> though. > > They aren't really special they just use Properties.loadFromStream (or > something like that). To do an include mechanism you'd have to > implement all the reading and parsing logic yourself. > They are special in that there are a lot of constructs not normal to properties, like ${foo} expansion, weird conditionals and expanding variants {foo|bar}. None of these are order dependent however, meaning, it doesn't matter which order you put the properties in. The evaluation of all those things happens when a property is read, not when it is parsed. So the only reasonable implementation of include, at least as I see it, would be to read a file like now, check a special "include-file" property for new values and if so, read that file too. /Erik > David > > >> /Erik >> From forax at univ-mlv.fr Mon Dec 7 11:42:23 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 7 Dec 2015 12:42:23 +0100 (CET) Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed In-Reply-To: <5661BF14.6070705@oracle.com> References: <5661BF14.6070705@oracle.com> Message-ID: <1612154831.177401.1449488543418.JavaMail.zimbra@u-pem.fr> Hi Claes, Makers should be declared 'private', so the constructor by default will be private. You should remove 'private' in front of TYPED_COLLECTORS, PRODUCE_BLOCK_INLINING_FORM and PRODUCE_REINVOKER_FORM because otherwise the compiler will generate methods access$xxx inside Makers to access to these fields. Those methods are unnecessary here. In TYPED_COLLECTORS, it should be return new MethodHandle[1 + MAX_JVM_ARITY]; otherwise, changes look fine. R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev" > Envoy?: Vendredi 4 D?cembre 2015 17:28:04 > Objet: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed > > Hi, > > please review this issue to remove explicit initialization of > MethodHandleImpl, which doesn't seem to be needed after recent > j.l.invoke bootstrap improvements. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144723 > Webrev: http://cr.openjdk.java.net/~redestad/8144723/webrev.01/ > > This removes 21 classes from jdk9/dev startup. I additionally identified > a few eagerly initialized functions that can be made lazily initialized, > which defers 6 classes from loading eagerly in startup tests that use > lambdas explicitly. > > Thanks! > > /Claes > From claes.redestad at oracle.com Mon Dec 7 13:36:13 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Dec 2015 14:36:13 +0100 Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed In-Reply-To: <1612154831.177401.1449488543418.JavaMail.zimbra@u-pem.fr> References: <5661BF14.6070705@oracle.com> <1612154831.177401.1449488543418.JavaMail.zimbra@u-pem.fr> Message-ID: <56658B4D.1080905@oracle.com> Hi Remi, On 2015-12-07 12:42, Remi Forax wrote: > Hi Claes, > Makers should be declared 'private', so the constructor by default will be private. > > You should remove 'private' in front of TYPED_COLLECTORS, PRODUCE_BLOCK_INLINING_FORM and PRODUCE_REINVOKER_FORM because otherwise the compiler will generate methods access$xxx inside Makers to access to these fields. Those methods are unnecessary here. > > In TYPED_COLLECTORS, it should be > return new MethodHandle[1 + MAX_JVM_ARITY]; Fixed: http://cr.openjdk.java.net/~redestad/8144723/webrev.02/ > > otherwise, changes look fine. Thanks! There's been some off-list comments about whether or not this change might make it possible to call into java.lang.invoke in surprising before things are properly initialized, which might not be covered by available tests. I've not been able to find or produce a test that demonstrate any bootstrapping and think we should push this now and fix any unforeseen bootstrapping issues it may cause as they come in. I hope some reviewer agrees. :-) /Claes From Sergey.Bylokhov at oracle.com Mon Dec 7 13:49:23 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 Dec 2015 16:49:23 +0300 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <56632B93.6070105@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <80575736-AB1F-4B01-B272-1CA7BBD08ACB@oracle.com> <5662C694.9040306@gmail.com> <56632B93.6070105@gmail.com> Message-ID: <56658E63.8070607@oracle.com> On 05.12.15 21:23, Peter Levart wrote: > Digging up the src.jar of JDK 1.2.2, here's what the constructor of > PhantomReference looked like: > > /** > * Creates a new phantom reference that refers to the given object and > * is registered with the given queue. > * > * @throws NullPointerException If the queue argument > * is null > */ > public PhantomReference(Object referent, ReferenceQueue q) { > super(referent, q); > } > > > ...so it seems Mark wanted PhantomReference constructor to throw NPE. > But implementation did not do that (here's also the constructor of > Reference): > > > Reference(Object referent, ReferenceQueue queue) { > this.referent = referent; > if (referent == null) { > /* Immediately make this instance inactive */ > this.queue = ReferenceQueue.NULL; > this.next = this; > } else { > this.queue = (queue == null) ? ReferenceQueue.NULL : queue; > this.next = null; > } > } > > > ...and so the spec. has probably been modified to follow the standing > behavior. Looks like it was updated in jdk5: https://bugs.openjdk.java.net/browse/JDK-4239039 -- Best regards, Sergey. From paul.sandoz at oracle.com Mon Dec 7 13:55:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Dec 2015 14:55:14 +0100 Subject: Pattern.splitAsStream JavaDoc doubt In-Reply-To: <56655CF0.1040703@oracle.com> References: <95164276.20151206182151@gmail.com> <56655CF0.1040703@oracle.com> Message-ID: > On 7 Dec 2015, at 11:18, Chris Hegarty wrote: > > Tagir, > > It would seem most useful to update the implementation to > match the current spec. Yes, it?s an oversight and lacked a test for such case. Tagir, thanks for finding this. Would it be possible for you to also add a test to jdk/test/java/util/regex/PatternStreamTest.java? > To that end, your first patch looks > like the most appropriate change, pattern-patch.txt. > The second patch would be more preferable and in line with existing last-binding implementations. Paul. From chris.hegarty at oracle.com Mon Dec 7 14:24:13 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Dec 2015 14:24:13 +0000 Subject: Pattern.splitAsStream JavaDoc doubt In-Reply-To: References: <95164276.20151206182151@gmail.com> <56655CF0.1040703@oracle.com> Message-ID: <5665968D.4020308@oracle.com> On 07/12/15 13:55, Paul Sandoz wrote: > >> On 7 Dec 2015, at 11:18, Chris Hegarty wrote: >> >> Tagir, >> >> It would seem most useful to update the implementation to >> match the current spec. > > Yes, it?s an oversight and lacked a test for such case. > > Tagir, thanks for finding this. Would it be possible for you to also add a test to jdk/test/java/util/regex/PatternStreamTest.java? > > >> To that end, your first patch looks >> like the most appropriate change, pattern-patch.txt. >> > > The second patch would be more preferable and in line with existing last-binding implementations. For me the first patch was "cleaner", but I accept your point about late-binding. The second patch is as late as possible. -Chris. From amaembo at gmail.com Mon Dec 7 15:23:03 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Mon, 7 Dec 2015 21:23:03 +0600 Subject: Pattern.splitAsStream JavaDoc doubt In-Reply-To: References: <95164276.20151206182151@gmail.com> <56655CF0.1040703@oracle.com> Message-ID: <231331777.20151207212303@gmail.com> Hello, Chris, Paul! Thank you for the review. >> Tagir, >> >> It would seem most useful to update the implementation to >> match the current spec. PS> Yes, it?s an oversight and lacked a test for such case. PS> Tagir, thanks for finding this. Would it be possible for you to PS> also add a test to jdk/test/java/util/regex/PatternStreamTest.java? Here's an updated pattern-patch2 which includes simple test for late-binding. Is it enough or something more sophisticated is necessary? Should I log the issue using the webbug form? With best regards, Tagir Valeev. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pattern-patch-test.txt URL: From christoph.langer at sap.com Mon Dec 7 15:28:51 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Dec 2015 15:28:51 +0000 Subject: Potential performance improvement for java.util.AbstractList? Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> Hi all, a Java application developer of our company has indicated that it might yield some performance benefit to modify the coding of java.util.AbstractList.equals() that it would first compare the size of the lists before iterating the elements. It would for sure be better in cases where one compares lists which don't have the same size. In case of comparing "equal" lists it would add some minor cost, though. Currently the implementation is like this: public boolean equals(Object o) { if (o == this) return true; if (!(o instanceof List)) return false; ListIterator e1 = listIterator(); ListIterator e2 = ((List) o).listIterator(); while (e1.hasNext() && e2.hasNext()) { E o1 = e1.next(); Object o2 = e2.next(); if (!(o1==null ? o2==null : o1.equals(o2))) return false; } return !(e1.hasNext() || e2.hasNext()); } One could do for instance: public boolean equals(Object o) { if (o == this) return true; if (!(o instanceof List)) return false; if ((List)o).size() != size()) return false; ListIterator e1 = listIterator(); ListIterator e2 = ((List) o).listIterator(); while (e1.hasNext() && e2.hasNext()) { E o1 = e1.next(); Object o2 = e2.next(); if (!(o1==null ? o2==null : o1.equals(o2))) return false; } return !(e1.hasNext() || e2.hasNext()); } How would you assess this idea? Are there other drawbacks/showstoppers to this which I don't see? Thanks in advance for comments. Best regards Christoph From cedric.champeau at gmail.com Mon Dec 7 15:31:56 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 7 Dec 2015 16:31:56 +0100 Subject: Potential performance improvement for java.util.AbstractList? In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> Message-ID: I assume one reason it's done this way is that depending on the list implementation you are using, getting the size might involve iterating over all elements, so you would be iterating twice at worst case. 2015-12-07 16:28 GMT+01:00 Langer, Christoph : > Hi all, > > a Java application developer of our company has indicated that it might > yield some performance benefit to modify the coding of > java.util.AbstractList.equals() that it would first compare the size of the > lists before iterating the elements. It would for sure be better in cases > where one compares lists which don't have the same size. In case of > comparing "equal" lists it would add some minor cost, though. > > Currently the implementation is like this: > > public boolean equals(Object o) { > if (o == this) > return true; > if (!(o instanceof List)) > return false; > > ListIterator e1 = listIterator(); > ListIterator e2 = ((List) o).listIterator(); > while (e1.hasNext() && e2.hasNext()) { > E o1 = e1.next(); > Object o2 = e2.next(); > if (!(o1==null ? o2==null : o1.equals(o2))) > return false; > } > return !(e1.hasNext() || e2.hasNext()); > } > > One could do for instance: > > > public boolean equals(Object o) { > > if (o == this) > > return true; > > if (!(o instanceof List)) > > return false; > > if ((List)o).size() != size()) > > return false; > > > > ListIterator e1 = listIterator(); > > ListIterator e2 = ((List) o).listIterator(); > > while (e1.hasNext() && e2.hasNext()) { > > E o1 = e1.next(); > > Object o2 = e2.next(); > > if (!(o1==null ? o2==null : o1.equals(o2))) > > return false; > > } > > return !(e1.hasNext() || e2.hasNext()); > > } > > How would you assess this idea? Are there other drawbacks/showstoppers to > this which I don't see? > > Thanks in advance for comments. > > Best regards > Christoph > > From rafael.wth at gmail.com Mon Dec 7 15:39:42 2015 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 7 Dec 2015 16:39:42 +0100 Subject: Potential performance improvement for java.util.AbstractList? In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> Message-ID: In this case, one might consider: if (o instanceof java.util.RandomAccess && (List)o).size() != size()) return false; Type checks are cheap, so the overhead of this additional statement should not be too big. Yet, maybe many list comparisons in practice involve lists of equal size. Otherwise, the contract of the List::equals method would allow for such a short-wiring. 2015-12-07 16:31 GMT+01:00 C?dric Champeau : > I assume one reason it's done this way is that depending on the list > implementation you are using, getting the size might involve iterating over > all elements, so you would be iterating twice at worst case. > > 2015-12-07 16:28 GMT+01:00 Langer, Christoph : > > > Hi all, > > > > a Java application developer of our company has indicated that it might > > yield some performance benefit to modify the coding of > > java.util.AbstractList.equals() that it would first compare the size of > the > > lists before iterating the elements. It would for sure be better in cases > > where one compares lists which don't have the same size. In case of > > comparing "equal" lists it would add some minor cost, though. > > > > Currently the implementation is like this: > > > > public boolean equals(Object o) { > > if (o == this) > > return true; > > if (!(o instanceof List)) > > return false; > > > > ListIterator e1 = listIterator(); > > ListIterator e2 = ((List) o).listIterator(); > > while (e1.hasNext() && e2.hasNext()) { > > E o1 = e1.next(); > > Object o2 = e2.next(); > > if (!(o1==null ? o2==null : o1.equals(o2))) > > return false; > > } > > return !(e1.hasNext() || e2.hasNext()); > > } > > > > One could do for instance: > > > > > > public boolean equals(Object o) { > > > > if (o == this) > > > > return true; > > > > if (!(o instanceof List)) > > > > return false; > > > > if ((List)o).size() != size()) > > > > return false; > > > > > > > > ListIterator e1 = listIterator(); > > > > ListIterator e2 = ((List) o).listIterator(); > > > > while (e1.hasNext() && e2.hasNext()) { > > > > E o1 = e1.next(); > > > > Object o2 = e2.next(); > > > > if (!(o1==null ? o2==null : o1.equals(o2))) > > > > return false; > > > > } > > > > return !(e1.hasNext() || e2.hasNext()); > > > > } > > > > How would you assess this idea? Are there other drawbacks/showstoppers to > > this which I don't see? > > > > Thanks in advance for comments. > > > > Best regards > > Christoph > > > > > From paul.sandoz at oracle.com Mon Dec 7 16:32:21 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 7 Dec 2015 17:32:21 +0100 Subject: Pattern.splitAsStream JavaDoc doubt In-Reply-To: <231331777.20151207212303@gmail.com> References: <95164276.20151206182151@gmail.com> <56655CF0.1040703@oracle.com> <231331777.20151207212303@gmail.com> Message-ID: <0C1006F4-72EB-4733-8E26-561147A5A460@oracle.com> > On 7 Dec 2015, at 16:23, Tagir F. Valeev wrote: > > Hello, Chris, Paul! > > Thank you for the review. > >>> Tagir, >>> >>> It would seem most useful to update the implementation to >>> match the current spec. > > PS> Yes, it?s an oversight and lacked a test for such case. > > PS> Tagir, thanks for finding this. Would it be possible for you to > PS> also add a test to jdk/test/java/util/regex/PatternStreamTest.java? > > Here's an updated pattern-patch2 which includes simple test for > late-binding. Is it enough or something more sophisticated is > necessary? That?s fine. > Should I log the issue using the webbug form? > I can log it and push for you this week. After this fix i think you may have contributed enough fixes to become an author: http://openjdk.java.net/projects/#project-author Paul. From sean.coffey at oracle.com Mon Dec 7 16:51:42 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 7 Dec 2015 16:51:42 +0000 Subject: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk In-Reply-To: <5643A368.7010207@oracle.com> References: <5643A368.7010207@oracle.com> Message-ID: <5665B91E.2010209@oracle.com> Hi Sherman, Nice work. It'll certainly help protect the VM from bad application code. I've no major issues with the new code. Some comments below. src/java.base/share/classes/java/util/zip/ZipFile.java unused import : > import java.nio.file.Path; line 840 : This could be marked final > private Key key; line 914 : Same here (final) > private static HashMap files = new HashMap<>(); While in this class, could you also mark inflaterCache as final (line 451) - String prop = sun.misc.VM.getSavedProperty("sun.zip.disableMemoryMapping"); With this property removed, I think you'll need to update src/java.base/share/classes/sun/misc/VM.java line 278 also. It becomes redundant code. We'll also need to log a sub-task to track doc updates to highlight that this property is no longer relevant. ZipFile : line 195 : Objects.requireNonNull(charset, "charset"); You've changed the order of exception throwing here. To aid with a possible backport (and behaviour), could you consider moving the check to post the 'mode' checks ? If you can't, I'll just remember it when backporting! line 525 : byte[] cen = zsrc.cen; It might be no harm to insert a comment here saying that the caller method must check for 'ensureOpen' ? I think you need a ensureOpen check on the new initDataOffset() method. You could hit an NPE otherwise. E.g. : > ZipFile zf = new ZipFile(new File("/tmp/jtreg.zip")); > ZipEntry ze = zf.getEntry("jtreg/release"); > InputStream is = zf.getInputStream(ze); > zf.close(); > is.skip(1); There might be room for a small improvement on the zerror method. Could you pre-append the name of the File to each exception message via this method ? On the new test, are you planning to add this to the jtreg tests or will it be a manual stand alone ? It would have to be tuned down in terms of resources if added to the auto-test list. Regards, Sean. On 11/11/15 20:22, Xueming Shen wrote: > Hi > > Please help review the changes for JDK-8142508 (third try) > > Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 > webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev > > Mainly to address the issues in current j.u.z.ZipFile implementation > as listed > below > > (1) The ZIP file format support code is in native C (shared with the > VM via > ZipFile.c -> zip_util.c). Any entry lookup, creation operation > requires multiple > round-trips of expensive jni calls. > > (2) The native C implementation which uses mmap to map in the central > directory > table appears to be a big risk of vm crash when the underlying > jar file gets > overwritten with new contents while it is still being used by > other ZipFile. The > crash reports keep coming in even after we have introduced in > system flag > to disable it (sun.zip.disableMemoryMapping). > > (3) The use of "filename + lastModified()" cache (zip_util.c) appears > to be broken > if the timestamp is in low resolution/precision > (File.getModified() for example, > might only have "second" ersolution on solaris/linux), and/or the > file is being > overwritten. > > The clean solution appears to bring the ZIP format support code > completely from > native to Java to remove the jni invocation cost and the mmap risk. > Also to use > the fileKey and lastModified from > java.nio.file.attribute.BasicFileAttributes to have > better/correct cache matching. > > Benchmark: > > This simple jmh measurement suggests a big boost of the performance of > ZipFile.getEntry()/entries()/getStream() which are basically entry > related > accesses (the "open only" has some regression, which is expected as we > switched from the mmap to simply read the cen table in into a byte[]) > > http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java > > # JDK9 base > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op > MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op > MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op > MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op > MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op > MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op > -------------------------------------------------------------------------------------- > > # JDK9 ZipFile without jni invocation > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op > MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op > MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op > MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op > MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op > MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op > --------------------------------------------------------------------------------------- > > > Test: > http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html > > > Verified the new ZipFile runs as expected when the underlying jar/zip > file get > deleted/overwritten when the zip still be used. The "old" ZipFile > fails to continue > to work but no crash, and the "new" one works correctly on updated zip > file > without problem (The test runs a little long, have not decided if it > should be > checked in as unit test). > > -Sherman > From mark.reinhold at oracle.com Mon Dec 7 17:34:40 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 Dec 2015 09:34:40 -0800 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com>, <561428BC.3060806@cs.oswego.edu>, <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com>, <56164C3C.4050800@cs.oswego.edu>, <561E6F04.9030708@cs.oswego.edu>, <54AE479E-9891-48FB-AD47-ECED8147DABE@azul.com>, <561FC6F9.1080701@cs.oswego.edu>, <25B8ED3D-4B35-48F4-BF24-32D48E85343E@azul.com>, <562BC968.70603@cs.oswego.edu>, <8917A25C-4A16-4291-B145-FA7180E09F78@azul.com>, <4A8EF318-A674-4619-94A6-6321AA198AEF@azul.com> Message-ID: <20151207093440.607909@eggemoggin.niobe.net> 2015/11/30 6:58 -0800, gil at azul.com: > Update: After some significant back-and-forth between Doug and I on > naming and JavaDoc'ing, and with Martin (Thompson) stepping in to > help, we have what we think is a good spec and name selection for this > thing. We're proposing to add a new static method to the Runtime > class: > > class Runtime { /... > /** > * Method signifying that the caller is momentarily unable to > * progress until the occurrence of one or more actions of one or > * more other activities. When invoked within each iteration, this > * method typically improves performance of spin wait loop > * constructions. > */ > public static void onSpinWait() {}; > } I'm glad to see some agreement here, but I'm puzzled by the proposal to to place this in the Runtime class. What's the reasoning for that? Wouldn't this more naturally be placed in java.lang.Thread? Also, I don't think this single method needs a JEP, but you're welcome to do it that way if you really want to. - Mark From mark.reinhold at oracle.com Mon Dec 7 17:58:25 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 Dec 2015 09:58:25 -0800 Subject: Reference.reachabilityFence In-Reply-To: <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com>, , <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com>, <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> Message-ID: <20151207095825.952677@eggemoggin.niobe.net> 2015/12/4 5:47 -0800, paul.sandoz at oracle.com: >> On 3 Dec 2015, at 22:33, Mandy Chung wrote: >>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ >>> >>> There is now more documentation on Reference (copied and suitable >>> rearranged from 166 Fences.java). The method name remains the same. >> >> I think the addition to the Reference class specification should >> belong to the reachabilityFence method specification. Any reason why >> not? > > I thought it would be more visible in the JavaDoc, as it?s there > upfront. The api note may get larger if we include some additional > real world examples. I don?t have a strong opinion on this, if yours > is stronger i will move it :-) I agree with Mandy -- the new text about fences belongs in the method doc, not the class doc. Further comments, mostly minor: - In the opening sentence, s/strongly reachability/strong reachability/. - I'd remove the phrase "As illustrated in the sample usages of the api note below" from the normative text. The API note follows immediately; there's no need to point to it. - s/a Java Virtual Machine/the virtual machine/ - s/A garbage collector/The garbage collector/ - s/call to/invocation of/ - s/ for example /, for example,/ - s/if it were OK/if it were acceptable/ ("OK" is a bit too informal) - s!in general!, in general,! - s/Fences.reachabilityFence/Reference.reachabilityFence/ in the examples - I now agree with you and Doug about calling this a "fence". Can we just name it "fence" rather than the wordier "reachabilityFence"? Looking at a typical invocation, Reference.reachabilityFence(); seems a bit redundant while Reference.fence(); reads quite nicely. Is there, or will there ever be, any other kind of reference-related fence? - Mark From Roger.Riggs at oracle.com Mon Dec 7 18:50:54 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Dec 2015 13:50:54 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5664D6DD.9010709@oracle.com> References: <560D3F61.6040607@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> Message-ID: <5665D50E.3030606@oracle.com> Hi David, Thanks for the comments, Updated the javadoc and webrev with editorial changes. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html On 12/6/15 7:46 PM, David Holmes wrote: > Hi Roger, > > Sorry to be late here but was trying not to get involved :) > > It is already implicit that ThreadFactory.newThread should return > unstarted threads - that is what a new Thread is - so I don't think > IllegalThreadStateException needs to be documented here as it is > documenting behaviour of a broken ThreadFactory (and a broken > ThreadFactory could throw anything) . It does seem that new is fairly well understood but one can read of ThreadFactory is as a bit ambiguous, lacking a direct reference to the Thread.State of the new thread and since it allows various attributes of the thread to be modified after the constructor. Since the runnable is supplied as an argument it is ready to be started, why not. It seemed useful to reinforce the salient points. > > Also the no-arg cleaner() can also throw SecurityException. The thread construction is done in doPriv so it should not throw. Did I miss some edge case? > > Also this: > > 127 * On each call the {@link ThreadFactory#newThread(Runnable) > thread factory} > 128 * should return a {@link Thread.State#NEW new thread} with > an appropriate > 129 * {@linkplain Thread#getContextClassLoader context class > loader}, > 130 * {@linkplain Thread#getName() name}, > 131 * {@linkplain Thread#getPriority() priority}, > 132 * permissions, etc. > > then begs the questions as to what is "appropriate". I think this can > be said much more simply as: "The ThreadFactory must provide a Thread > that is suitable for performing the cleaning work". Though even that > raises questions. I'm not sure why a ThreadFactory is actually needed > here ?? Special security context? If so that could be mentioned, but I > don't think name or priority need to be discussed. It was intended to prod the client to be deliberate about the threadFactory. Since the client is integrating the Cleaner and respective cleaning functions with the client code, the ThreadFactory makes it possible for the client to initialize a suitable thread and the comments serve as a reminder. I agree that the phrase 'suitable for performing the cleaning work' is the operative one. Thanks, Roger > > Thanks, > David > From xueming.shen at oracle.com Mon Dec 7 19:03:48 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Dec 2015 11:03:48 -0800 Subject: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk In-Reply-To: <5665B91E.2010209@oracle.com> References: <5643A368.7010207@oracle.com> <5665B91E.2010209@oracle.com> Message-ID: <5665D814.8010201@oracle.com> Hi Sean, Thanks for the review. Webrev has been updated accordingly. The only suggestion I did not follow is to append the file name into the zip error/exception message. I would assume it might have vuln concern if the file name is published in such exception. It might be OK to only publish the "name" part (exclude the parent path) in such scenario, but I would prefer to leave this to a separate rfe, if desired. http://cr.openjdk.java.net/~sherman/8142508/webrev Thanks, Sherman On 12/07/2015 08:51 AM, Se?n Coffey wrote: > Hi Sherman, > > Nice work. It'll certainly help protect the VM from bad application code. I've no major issues with the new code. Some comments below. > > src/java.base/share/classes/java/util/zip/ZipFile.java > unused import : >> import java.nio.file.Path; > > line 840 : This could be marked final >> private Key key; > > line 914 : Same here (final) > >> private static HashMap files = new HashMap<>(); > > While in this class, could you also mark inflaterCache as final (line 451) > > > - String prop = sun.misc.VM.getSavedProperty("sun.zip.disableMemoryMapping"); > With this property removed, I think you'll need to update src/java.base/share/classes/sun/misc/VM.java line 278 also. It becomes redundant code. > > We'll also need to log a sub-task to track doc updates to highlight that this property is no longer relevant. > > ZipFile : line 195 : > > Objects.requireNonNull(charset, "charset"); > > You've changed the order of exception throwing here. To aid with a possible backport (and behaviour), could you consider moving the check to post the 'mode' checks ? If you can't, I'll just remember it when backporting! > > line 525 : > > byte[] cen = zsrc.cen; > > It might be no harm to insert a comment here saying that the caller method must check for 'ensureOpen' ? > > I think you need a ensureOpen check on the new initDataOffset() method. You could hit an NPE otherwise. E.g. : >> ZipFile zf = new ZipFile(new File("/tmp/jtreg.zip")); >> ZipEntry ze = zf.getEntry("jtreg/release"); >> InputStream is = zf.getInputStream(ze); >> zf.close(); >> is.skip(1); > > There might be room for a small improvement on the zerror method. Could > you pre-append the name of the File to each exception message via this method ? > > On the new test, are you planning to add this to the jtreg tests or will it be > a manual stand alone ? It would have to be tuned down in terms of resources > if added to the auto-test list. > Regards, > Sean. > On 11/11/15 20:22, Xueming Shen wrote: >> Hi >> >> Please help review the changes for JDK-8142508 (third try) >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 >> webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev >> >> Mainly to address the issues in current j.u.z.ZipFile implementation as listed >> below >> >> (1) The ZIP file format support code is in native C (shared with the VM via >> ZipFile.c -> zip_util.c). Any entry lookup, creation operation requires multiple >> round-trips of expensive jni calls. >> >> (2) The native C implementation which uses mmap to map in the central directory >> table appears to be a big risk of vm crash when the underlying jar file gets >> overwritten with new contents while it is still being used by other ZipFile. The >> crash reports keep coming in even after we have introduced in system flag >> to disable it (sun.zip.disableMemoryMapping). >> >> (3) The use of "filename + lastModified()" cache (zip_util.c) appears to be broken >> if the timestamp is in low resolution/precision (File.getModified() for example, >> might only have "second" ersolution on solaris/linux), and/or the file is being >> overwritten. >> >> The clean solution appears to bring the ZIP format support code completely from >> native to Java to remove the jni invocation cost and the mmap risk. Also to use >> the fileKey and lastModified from java.nio.file.attribute.BasicFileAttributes to have >> better/correct cache matching. >> >> Benchmark: >> >> This simple jmh measurement suggests a big boost of the performance of >> ZipFile.getEntry()/entries()/getStream() which are basically entry related >> accesses (the "open only" has some regression, which is expected as we >> switched from the mmap to simply read the cen table in into a byte[]) >> >> http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java >> >> # JDK9 base >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op >> MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op >> MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op >> MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op >> MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op >> MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op >> -------------------------------------------------------------------------------------- >> # JDK9 ZipFile without jni invocation >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op >> MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op >> MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op >> MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op >> MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op >> MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op >> --------------------------------------------------------------------------------------- >> >> Test: >> http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html >> >> Verified the new ZipFile runs as expected when the underlying jar/zip file get >> deleted/overwritten when the zip still be used. The "old" ZipFile fails to continue >> to work but no crash, and the "new" one works correctly on updated zip file >> without problem (The test runs a little long, have not decided if it should be >> checked in as unit test). >> >> -Sherman >> > From mandy.chung at oracle.com Mon Dec 7 19:51:56 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Dec 2015 11:51:56 -0800 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <5664FA46.4050004@oracle.com> References: <56605A8C.9060300@oracle.com> <566062D9.4020907@oracle.com> <5660EF5D.9040000@oracle.com> <8172659D-6373-41CF-9B77-7548EF8688B2@oracle.com> <56611805.4030405@oracle.com> <5664FA46.4050004@oracle.com> Message-ID: <5665E35C.4070502@oracle.com> On 12/06/2015 07:17 PM, Sundararajan Athijegannathan wrote: > Hi, > > Please review the updated webrevs > > http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.01/ > http://cr.openjdk.java.net/~sundar/8143404/top/webrev.01/ > http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ > Looks good. Thanks Mandy From joel.borggren.franck at gmail.com Mon Dec 7 20:29:11 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Mon, 7 Dec 2015 21:29:11 +0100 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: <564DC981.8000207@oracle.com> References: <564DC981.8000207@oracle.com> Message-ID: Hi, Thanks for the comments. I removed the allocations and fixed the quadratic copy in popAllLocations. New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.01/ cheers /Joel On Thu, Nov 19, 2015 at 2:07 PM, Claes Redestad wrote: > Hi Joel, > > looks good. I see a CCC has been filed. > > Nits: > In AnnotatedTypeFactory.java, newly introduced EMPTY_TYPE_ANNOTATION_ARRAY > could be used to replace a few occurrences of new TypeAnnotation[0] in the > code above). > > In TypeAnnotation.java: > New method popLocation(byte tag) seems to be unused, and popLocation() is > only used from popAllLocations(byte tag), so it might suffice to only keep > popAllLocations: > > public LocationInfo popAllLocations(byte tag) { > LocationInfo l = this; > int depth = l.depth; > while(depth > 0 && l.locations[depth - 1].tag == tag) { > depth--; > } > if (depth != l.depth) { > Location[] res = new Location[depth]; > System.arraycopy(this.locations, 0, res, 0, depth); > return new LocationInfo(depth, res); > } > return l; > } > > Not a reviewer, easy to ignore. :-) > > /Claes > > > On 2015-11-17 20:15, Joel Borggr?n-Franck wrote: >> >> Hi, >> >> When reflecting over annotated types, there is currently no way to get >> the potentially annotated owner of a type. For example, given you have >> an instance of '@A Outer . @B Inner' you can't traverse it to get '@A >> Outer' . >> >> This API addition fixes this. Because both parameterized and >> non-generic types can have an owner, this addition goes into the base >> AnnotatedType interface together with a default implementation. CCC >> has been filed. >> >> The parsing code and annotated type factory had to be fixed to deal >> with navigating inside nested types. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8057804 >> Webrev: http://cr.openjdk.java.net/~rbackman/jbf/8057804/webrev.00/ >> >> >> (OCA is signed and processed). >> >> Cheers >> /Joel > > From pbenedict at apache.org Mon Dec 7 20:39:07 2015 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 7 Dec 2015 14:39:07 -0600 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> Message-ID: Joel, some comments on AnnotatedType#getAnnotatedOwnerType(): * Is it convention to use

    tags to describe the complexity of the return value vs. just explaining it all in the @return tag? * What is the convention for @see nowadays? Is it 1.9 or 9? Cheers, Paul On Mon, Dec 7, 2015 at 2:29 PM, Joel Borggr?n-Franck < joel.borggren.franck at gmail.com> wrote: > Hi, > > Thanks for the comments. I removed the allocations and fixed the > quadratic copy in popAllLocations. > > New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.01/ > > cheers > /Joel > > On Thu, Nov 19, 2015 at 2:07 PM, Claes Redestad > wrote: > > Hi Joel, > > > > looks good. I see a CCC has been filed. > > > > Nits: > > In AnnotatedTypeFactory.java, newly introduced > EMPTY_TYPE_ANNOTATION_ARRAY > > could be used to replace a few occurrences of new TypeAnnotation[0] in > the > > code above). > > > > In TypeAnnotation.java: > > New method popLocation(byte tag) seems to be unused, and popLocation() is > > only used from popAllLocations(byte tag), so it might suffice to only > keep > > popAllLocations: > > > > public LocationInfo popAllLocations(byte tag) { > > LocationInfo l = this; > > int depth = l.depth; > > while(depth > 0 && l.locations[depth - 1].tag == tag) { > > depth--; > > } > > if (depth != l.depth) { > > Location[] res = new Location[depth]; > > System.arraycopy(this.locations, 0, res, 0, depth); > > return new LocationInfo(depth, res); > > } > > return l; > > } > > > > Not a reviewer, easy to ignore. :-) > > > > /Claes > > > > > > On 2015-11-17 20:15, Joel Borggr?n-Franck wrote: > >> > >> Hi, > >> > >> When reflecting over annotated types, there is currently no way to get > >> the potentially annotated owner of a type. For example, given you have > >> an instance of '@A Outer . @B Inner' you can't traverse it to get '@A > >> Outer' . > >> > >> This API addition fixes this. Because both parameterized and > >> non-generic types can have an owner, this addition goes into the base > >> AnnotatedType interface together with a default implementation. CCC > >> has been filed. > >> > >> The parsing code and annotated type factory had to be fixed to deal > >> with navigating inside nested types. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8057804 > >> Webrev: http://cr.openjdk.java.net/~rbackman/jbf/8057804/webrev.00/ > >> > >> > >> (OCA is signed and processed). > >> > >> Cheers > >> /Joel > > > > > From joel.borggren.franck at gmail.com Mon Dec 7 20:43:06 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Mon, 07 Dec 2015 20:43:06 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> Message-ID: Hi Paul, See inline, On Mon, 7 Dec 2015 at 21:39 Paul Benedict wrote: > Joel, some comments on AnnotatedType#getAnnotatedOwnerType(): > > * Is it convention to use

    tags to describe the complexity of the > return value vs. just explaining it all in the @return tag? > > It is for the Core Reflection javadocs. Compare with j.l.Class.get(Declared)Thing. > * What is the convention for @see nowadays? Is it 1.9 or 9? > > Good question. Anyone? I'll grep for 1.9 if it is still there in lots of places I would expect "someone else" to do a big cleanup job. cheers /Joel From Alan.Bateman at oracle.com Mon Dec 7 20:52:54 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Dec 2015 20:52:54 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> Message-ID: <5665F1A6.7030701@oracle.com> On 07/12/2015 20:43, Joel Borggr?n-Franck wrote: > : > Good question. Anyone? I'll grep for 1.9 if it is still there in lots of > places I would expect "someone else" to do a big cleanup job. > > I think Iris is planning a bulk update to change them to 9 soon, might need a couple of rounds to ensure that in-flight changes are caught. -Alan From joe.darcy at oracle.com Mon Dec 7 21:39:37 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 7 Dec 2015 13:39:37 -0800 Subject: JDK 9 RFR of JDK-8144880: Instrument intermittently failing test ConfigChanges.java Message-ID: <5665FC99.4060806@oracle.com> Hello, Please review the changes to address JDK-8144880: Instrument intermittently failing test ConfigChanges.java The test java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java fails intermittently and uses randomness. In the patch below, It is marked accordingly and downgraded from tier 1 to tier 2 until the problem problem in bug JDK-8139237 is addressed. Thanks, -Joe diff -r dc3322ef23ff test/TEST.groups --- a/test/TEST.groups Mon Dec 07 12:35:37 2015 +0100 +++ b/test/TEST.groups Mon Dec 07 13:39:12 2015 -0800 @@ -32,6 +32,7 @@ :jdk_util \ -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/Phaser/Basic.java \ + -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ com/sun/crypto/provider/Cipher \ @@ -42,6 +43,7 @@ java/util/zip/TestLocalTime.java \ java/util/concurrent/Phaser/Basic.java \ java/util/WeakHashMap/GCDuringIteration.java \ + java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ :jdk_io \ :jdk_nio \ -sun/nio/cs/ISO8859x.java \ diff -r dc3322ef23ff test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java --- a/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon Dec 07 12:35:37 2015 +0100 +++ b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon Dec 07 13:39:12 2015 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2015, 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,10 @@ * @test * @bug 6450200 * @summary Test proper handling of pool state changes + * @library /lib/testlibrary/ + * @build jdk.testlibrary.RandomFactory * @run main/othervm ConfigChanges + * @key randomness intermittent * @author Martin Buchholz */ @@ -42,11 +45,12 @@ import java.util.concurrent.ThreadFactory; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.atomic.AtomicInteger; +import jdk.testlibrary.RandomFactory; public class ConfigChanges { static final ThreadGroup tg = new ThreadGroup("pool"); - static final Random rnd = new Random(); + static final Random rnd = RandomFactory.getRandom(); static void report(ThreadPoolExecutor tpe) { try { From lance.andersen at oracle.com Mon Dec 7 21:43:25 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 7 Dec 2015 16:43:25 -0500 Subject: JDK 9 RFR of JDK-8144880: Instrument intermittently failing test ConfigChanges.java In-Reply-To: <5665FC99.4060806@oracle.com> References: <5665FC99.4060806@oracle.com> Message-ID: <260DA6B1-B6F2-46D9-BFFD-5D448E03A9B4@oracle.com> Hi Joe +1 Best Lance On Dec 7, 2015, at 4:39 PM, joe darcy wrote: > Hello, > > Please review the changes to address > > JDK-8144880: Instrument intermittently failing test ConfigChanges.java > > The test > > java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > > fails intermittently and uses randomness. In the patch below, It is marked accordingly and downgraded from tier 1 to tier 2 until the problem problem in bug JDK-8139237 is addressed. > > Thanks, > > -Joe > > diff -r dc3322ef23ff test/TEST.groups > --- a/test/TEST.groups Mon Dec 07 12:35:37 2015 +0100 > +++ b/test/TEST.groups Mon Dec 07 13:39:12 2015 -0800 > @@ -32,6 +32,7 @@ > :jdk_util \ > -java/util/WeakHashMap/GCDuringIteration.java \ > -java/util/concurrent/Phaser/Basic.java \ > + -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > com/sun/crypto/provider/Cipher \ > @@ -42,6 +43,7 @@ > java/util/zip/TestLocalTime.java \ > java/util/concurrent/Phaser/Basic.java \ > java/util/WeakHashMap/GCDuringIteration.java \ > + java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > :jdk_io \ > :jdk_nio \ > -sun/nio/cs/ISO8859x.java \ > diff -r dc3322ef23ff test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > --- a/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon Dec 07 12:35:37 2015 +0100 > +++ b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon Dec 07 13:39:12 2015 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2007, 2015, 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,10 @@ > * @test > * @bug 6450200 > * @summary Test proper handling of pool state changes > + * @library /lib/testlibrary/ > + * @build jdk.testlibrary.RandomFactory > * @run main/othervm ConfigChanges > + * @key randomness intermittent > * @author Martin Buchholz > */ > > @@ -42,11 +45,12 @@ > import java.util.concurrent.ThreadFactory; > import java.util.concurrent.ThreadPoolExecutor; > import java.util.concurrent.atomic.AtomicInteger; > +import jdk.testlibrary.RandomFactory; > > public class ConfigChanges { > static final ThreadGroup tg = new ThreadGroup("pool"); > > - static final Random rnd = new Random(); > + static final Random rnd = RandomFactory.getRandom(); > > static void report(ThreadPoolExecutor tpe) { > try { > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Mon Dec 7 22:07:59 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 7 Dec 2015 14:07:59 -0800 Subject: JDK 9 RFR of JDK-8144880: Instrument intermittently failing test ConfigChanges.java In-Reply-To: <5665FC99.4060806@oracle.com> References: <5665FC99.4060806@oracle.com> Message-ID: Thanks! I'm not seeing this fail recently. On Mon, Dec 7, 2015 at 1:39 PM, joe darcy wrote: > Hello, > > Please review the changes to address > > JDK-8144880: Instrument intermittently failing test ConfigChanges.java > > The test > > java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > > fails intermittently and uses randomness. In the patch below, It is marked > accordingly and downgraded from tier 1 to tier 2 until the problem problem > in bug JDK-8139237 is addressed. > > Thanks, > > -Joe > > diff -r dc3322ef23ff test/TEST.groups > --- a/test/TEST.groups Mon Dec 07 12:35:37 2015 +0100 > +++ b/test/TEST.groups Mon Dec 07 13:39:12 2015 -0800 > @@ -32,6 +32,7 @@ > :jdk_util \ > -java/util/WeakHashMap/GCDuringIteration.java \ > -java/util/concurrent/Phaser/Basic.java \ > + -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > com/sun/crypto/provider/Cipher \ > @@ -42,6 +43,7 @@ > java/util/zip/TestLocalTime.java \ > java/util/concurrent/Phaser/Basic.java \ > java/util/WeakHashMap/GCDuringIteration.java \ > + java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > :jdk_io \ > :jdk_nio \ > -sun/nio/cs/ISO8859x.java \ > diff -r dc3322ef23ff > test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java > --- a/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon > Dec 07 12:35:37 2015 +0100 > +++ b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon > Dec 07 13:39:12 2015 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2007, 2015, 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,10 @@ > * @test > * @bug 6450200 > * @summary Test proper handling of pool state changes > + * @library /lib/testlibrary/ > + * @build jdk.testlibrary.RandomFactory > * @run main/othervm ConfigChanges > + * @key randomness intermittent > * @author Martin Buchholz > */ > > @@ -42,11 +45,12 @@ > import java.util.concurrent.ThreadFactory; > import java.util.concurrent.ThreadPoolExecutor; > import java.util.concurrent.atomic.AtomicInteger; > +import jdk.testlibrary.RandomFactory; > > public class ConfigChanges { > static final ThreadGroup tg = new ThreadGroup("pool"); > > - static final Random rnd = new Random(); > + static final Random rnd = RandomFactory.getRandom(); > > static void report(ThreadPoolExecutor tpe) { > try { > From joe.darcy at oracle.com Mon Dec 7 22:14:19 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 7 Dec 2015 14:14:19 -0800 Subject: JDK 9 RFR of JDK-8144880: Instrument intermittently failing test ConfigChanges.java In-Reply-To: References: <5665FC99.4060806@oracle.com> Message-ID: <566604BB.5060604@oracle.com> Hi Martin, FYI, within the past month, we've seen this test fail at least once on 64-bit windows and at least once more on Solaris x64. Thanks for the review, -Joe On 12/7/2015 2:07 PM, Martin Buchholz wrote: > Thanks! > I'm not seeing this fail recently. > > On Mon, Dec 7, 2015 at 1:39 PM, joe darcy wrote: >> Hello, >> >> Please review the changes to address >> >> JDK-8144880: Instrument intermittently failing test ConfigChanges.java >> >> The test >> >> java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java >> >> fails intermittently and uses randomness. In the patch below, It is marked >> accordingly and downgraded from tier 1 to tier 2 until the problem problem >> in bug JDK-8139237 is addressed. >> >> Thanks, >> >> -Joe >> >> diff -r dc3322ef23ff test/TEST.groups >> --- a/test/TEST.groups Mon Dec 07 12:35:37 2015 +0100 >> +++ b/test/TEST.groups Mon Dec 07 13:39:12 2015 -0800 >> @@ -32,6 +32,7 @@ >> :jdk_util \ >> -java/util/WeakHashMap/GCDuringIteration.java \ >> -java/util/concurrent/Phaser/Basic.java \ >> + -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java >> sun/nio/cs/ISO8859x.java \ >> java/nio/Buffer \ >> com/sun/crypto/provider/Cipher \ >> @@ -42,6 +43,7 @@ >> java/util/zip/TestLocalTime.java \ >> java/util/concurrent/Phaser/Basic.java \ >> java/util/WeakHashMap/GCDuringIteration.java \ >> + java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ >> :jdk_io \ >> :jdk_nio \ >> -sun/nio/cs/ISO8859x.java \ >> diff -r dc3322ef23ff >> test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java >> --- a/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon >> Dec 07 12:35:37 2015 +0100 >> +++ b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java Mon >> Dec 07 13:39:12 2015 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2007, 2015, 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,10 @@ >> * @test >> * @bug 6450200 >> * @summary Test proper handling of pool state changes >> + * @library /lib/testlibrary/ >> + * @build jdk.testlibrary.RandomFactory >> * @run main/othervm ConfigChanges >> + * @key randomness intermittent >> * @author Martin Buchholz >> */ >> >> @@ -42,11 +45,12 @@ >> import java.util.concurrent.ThreadFactory; >> import java.util.concurrent.ThreadPoolExecutor; >> import java.util.concurrent.atomic.AtomicInteger; >> +import jdk.testlibrary.RandomFactory; >> >> public class ConfigChanges { >> static final ThreadGroup tg = new ThreadGroup("pool"); >> >> - static final Random rnd = new Random(); >> + static final Random rnd = RandomFactory.getRandom(); >> >> static void report(ThreadPoolExecutor tpe) { >> try { >> From chris.plummer at oracle.com Mon Dec 7 22:27:35 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 7 Dec 2015 14:27:35 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <5664CA4A.1090704@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> Message-ID: <566607D7.40909@oracle.com> Thanks David! Can I get a second reviewer please? thanks, Chris On 12/6/15 3:52 PM, David Holmes wrote: > Hi Chris, > > On 5/12/2015 7:00 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8144677 >> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >> >> Tested with JPRT with: >> ? "-testset hotspot" >> ? "-testset svc" >> ? "-testset chris" from the example custom testset provided in the >> CR. >> ? no testset specified > > Looks good! > >> BTW, if anyone knows of an "include" mechanism for jprt.properties, > > Properties files do not have an include mechanism. See: > > http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- > > > Thanks, > David > >> please let me know. Although that won't change the need for the above >> changes, it would make it possible to put custom testsets in a file >> rather than having to paste them in your ~/.jprt.properties file. >> >> thanks, >> >> Chris >> >> From mikael.vidstedt at oracle.com Mon Dec 7 23:22:24 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 7 Dec 2015 15:22:24 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <566607D7.40909@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> <566607D7.40909@oracle.com> Message-ID: <566614B0.8020809@oracle.com> Thumbs up! Cheers, Mikael On 2015-12-07 14:27, Chris Plummer wrote: > Thanks David! > > Can I get a second reviewer please? > > thanks, > > Chris > > On 12/6/15 3:52 PM, David Holmes wrote: >> Hi Chris, >> >> On 5/12/2015 7:00 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>> >>> Tested with JPRT with: >>> ? "-testset hotspot" >>> ? "-testset svc" >>> ? "-testset chris" from the example custom testset provided in >>> the CR. >>> ? no testset specified >> >> Looks good! >> >>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >> >> Properties files do not have an include mechanism. See: >> >> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- >> >> >> Thanks, >> David >> >>> please let me know. Although that won't change the need for the above >>> changes, it would make it possible to put custom testsets in a file >>> rather than having to paste them in your ~/.jprt.properties file. >>> >>> thanks, >>> >>> Chris >>> >>> > > From brian.burkhalter at oracle.com Tue Dec 8 00:11:26 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Dec 2015 16:11:26 -0800 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <56617A37.3070408@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56617A37.3070408@oracle.com> Message-ID: On Dec 4, 2015, at 3:34 AM, Alan Bateman wrote: > On 04/12/2015 00:23, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8143394 >> Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/ >> >> The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ?false? but before the variable ?buf? was dereferenced at line 87. The fix is to change close() to use the ?lock? variable as in the other methods. Similar problems were found to exist in CharArrayReader and StringReader. The test reliably reproduces the NPE in all three classes with the NPE in PushbackReader being reproduced frequently and the NPE in the other classes less so. >> > I suspect this is going to need a spec update to make it clear that close will now block when there is another thread blocking on the reader. Here is an updated version http://cr.openjdk.java.net/~bpb/8143394/webrev.01/ wherein the sentence "This method will block if there is another thread blocking on the reader.? is added to the specification of close() in each of the affected classes. Not sure whether this change requires CCC approval. Thanks, Brian From brian.burkhalter at oracle.com Tue Dec 8 00:11:39 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 7 Dec 2015 16:11:39 -0800 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <56615354.3080900@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56615354.3080900@oracle.com> Message-ID: On Dec 4, 2015, at 12:48 AM, Daniel Fuchs wrote: > The only other possible issue I spotted is in the test: > > Because readers[0] is set by one thread and read by both then using > an array without synchronization is not thread safe. I would > advise using an AtomicReference instead. The only point of the threads is to provoke a race condition so I don?t know that it matters in this case. Nonetheless I updated the test case per the suggestion and verified that it still provokes the failure in the build not containing the patch. Thanks, Brian From stuart.marks at oracle.com Tue Dec 8 00:19:54 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 7 Dec 2015 16:19:54 -0800 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5662122A.7020303@oracle.com> References: <565E590D.3090007@oracle.com> <5662122A.7020303@oracle.com> Message-ID: <5666222A.5070204@oracle.com> Hi Maurizio, Well, maybe we should add five more overloads to EnumSet.of()? (Only slightly joking here.) Setting aside the number of overloads, it would add N more overloads to Set.of(). I guess the erasure of > would be Enum, so there wouldn't be any overload ambiguity.... To me the question here is whether this adds sufficient value. The advantage is that one could write Set.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) instead of EnumSet.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) and get an optimized EnumSet instead of a Set that contains object references. Is it worth it? Presumably this would result in an instance of an immutable EnumSet. Does this case come up that often? s'marks On 12/4/15 2:22 PM, Maurizio Cimadamore wrote: > Hi Stuart > small question: I find it a bit odd that EnumSet has max 5 parameters, while Set > has more than that. > > Also, would it be possible, maybe to add overloads to Set that specifically > works on Enum constants? > > > of(Z z1, Z z2) { ... } > > This would give you a way to call Set.of and get different answers based on the > static type of the arguments passed in - and we could deprecate the of method in > EnumSet? > > Too subtle/magic? > > Maurizio > > On 02/12/15 02:35, Stuart Marks wrote: >> Hi all, >> >> Thanks for the previous round of review comments. Here's an updated API and >> implementation for review. >> >> I've run specdiff with the --hu ("hide unchanged") option, so only the bits of >> the specification that have changed are shown. As before, though, please >> ignore the spurious change to EnumSet caused by a javadoc bug. >> >> API changes: >> - add clarifying notes on immutability >> - remove wording that implied creation of new objects >> - add "value-based" disclaimers >> - add ordering specification for List and non-ordering disclaimers >> for Set and Map >> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, instead >> it extracts keys and values >> - Map.Entry instances returned from Map.entry() are *not* serializable >> >> Other: >> - markup cleanups >> - small implementation cleanups >> >> JEP: >> >> http://openjdk.java.net/jeps/269 >> >> API spec (basically List, Map, and Set): >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >> >> Thanks, >> >> s'marks > From stuart.marks at oracle.com Tue Dec 8 00:27:13 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 7 Dec 2015 16:27:13 -0800 Subject: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <56656DB4.9060702@oracle.com> References: <565E590D.3090007@oracle.com> <5660E518.4040705@oracle.com> <56656DB4.9060702@oracle.com> Message-ID: <566623E1.6030200@oracle.com> Hi Chris, Yes, absolutely, my plan is to introduce a serial proxy in a subsequent round of changes. The serial proxy will be the only new serial form introduced; the optimized implementations won't have a serial form of their own exposed. The skeleton implementations are in fact serializable but their serial forms aren't final. It didn't seem worthwhile to go to the extra effort to shut this off. I've asked the JCK team not to write serialization tests until the serial proxy stuff gets integrated. s'marks On 12/7/15 3:29 AM, Chris Hegarty wrote: > > 102 *

  • They are serializable if all elements are serializable. > > To avoid any ambiguity or "leaking", would it make sense to > have the serial form of these types be defined, in a similar > manner to what was done for Serializable types in the > java.time package [1]. > > This can be done as a follow up, so as to not block your > progress. > > -Chris. > > [1] https://docs.oracle.com/javase/8/docs/api/serialized-form.html#java.time.Ser. > > On 04/12/15 00:58, Stuart Marks wrote: >> ... >> >> I still need an official OpenJDK Reviewer. > >> API: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ >> >> Thanks, >> >> s'marks >> >> >> On 12/1/15 6:35 PM, Stuart Marks wrote: >>> Hi all, >>> >>> Thanks for the previous round of review comments. Here's an updated >>> API and >>> implementation for review. >>> >>> I've run specdiff with the --hu ("hide unchanged") option, so only the >>> bits of >>> the specification that have changed are shown. As before, though, >>> please ignore >>> the spurious change to EnumSet caused by a javadoc bug. >>> >>> API changes: >>> - add clarifying notes on immutability >>> - remove wording that implied creation of new objects >>> - add "value-based" disclaimers >>> - add ordering specification for List and non-ordering disclaimers >>> for Set and Map >>> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >>> instead >>> it extracts keys and values >>> - Map.Entry instances returned from Map.entry() are *not* serializable >>> >>> Other: >>> - markup cleanups >>> - small implementation cleanups >>> >>> JEP: >>> >>> http://openjdk.java.net/jeps/269 >>> >>> API spec (basically List, Map, and Set): >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >>> >>> Specdiff: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >>> >>> >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >>> >>> Thanks, >>> >>> s'marks From chris.plummer at oracle.com Tue Dec 8 01:06:34 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 7 Dec 2015 17:06:34 -0800 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <566614B0.8020809@oracle.com> References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com> <566607D7.40909@oracle.com> <566614B0.8020809@oracle.com> Message-ID: <56662D1A.7060205@oracle.com> Thanks Mikael! Chris On 12/7/15 3:22 PM, Mikael Vidstedt wrote: > > Thumbs up! > > Cheers, > Mikael > > On 2015-12-07 14:27, Chris Plummer wrote: >> Thanks David! >> >> Can I get a second reviewer please? >> >> thanks, >> >> Chris >> >> On 12/6/15 3:52 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 5/12/2015 7:00 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>>> >>>> Tested with JPRT with: >>>> ? "-testset hotspot" >>>> ? "-testset svc" >>>> ? "-testset chris" from the example custom testset provided in >>>> the CR. >>>> ? no testset specified >>> >>> Looks good! >>> >>>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>> >>> Properties files do not have an include mechanism. See: >>> >>> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- >>> >>> >>> Thanks, >>> David >>> >>>> please let me know. Although that won't change the need for the above >>>> changes, it would make it possible to put custom testsets in a file >>>> rather than having to paste them in your ~/.jprt.properties file. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >> >> > From bitterfoxc at gmail.com Tue Dec 8 03:13:32 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 8 Dec 2015 12:13:32 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: Message-ID: Hi, Another way have been found to satisfy the requirement(Thank you, @gakuzzzz). FYI, we can write it easy using toMap in this case: Map map = emps.stream() .collect(toMap(Employee::getDepartment, e -> e.getSalary() > 2000 ? 1L : 0L, Long::sum)); However, filtering is still necessary and useful for other situations. Regards, shinyafox(Shinya Yoshida) 2015-12-04 15:57 GMT+09:00 ShinyaYoshida : > Hi, core-libs-dev and Brian, Paul, > I'd like to propose adding filtering method to Collectors. > > When I consider the operation what is "grouping the number of employees > whose income is over 2000 by the depertment from employees", we have to > write following because there is no way to filter for Collector: > (Note: In this case, we need the entry which the value is 0) > > Map map = emps.stream() > .collect(groupingBy(Employee::getDepartment, > collectingAndThen(toList(), > es -> es.stream().filter(e -> e.getSalary() > 2000).count()))); > > When I add filtering like following to Collectors, we can write it easy, > and it would be more efficient. > public static > Collector filtering(Predicate filter, > Collector downstream) { > BiConsumer downstreamAccumulator = > downstream.accumulator(); > return new CollectorImpl<>(downstream.supplier(), > (r, t) -> { > if (filter.test(t)) { > downstreamAccumulator.accept(r, > t); > } > }, > downstream.combiner(), > downstream.finisher(), > downstream.characteristics()); > } > > Map map = emps.stream() > .collect(groupingBy(Employee::getDepartment, > filtering(e -> e.getSalary() > 2000, counting()))); > > Here is patch: > webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.00/ > bugs: https://bugs.openjdk.java.net/browse/JDK-8144675 > > Could you consider this patch and proposal? > > Regards, > shinyafox(Shinya Yoshida) > > > From david.holmes at oracle.com Tue Dec 8 03:49:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 13:49:02 +1000 Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets In-Reply-To: <56656FED.5050105@oracle.com> References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com> <56656B1B.2020107@oracle.com> <56656FED.5050105@oracle.com> Message-ID: <5666532E.1050205@oracle.com> On 7/12/2015 9:39 PM, Erik Joelsson wrote: > > > On 2015-12-07 12:18, David Holmes wrote: >> On 7/12/2015 6:33 PM, Erik Joelsson wrote: >>> >>> >>> On 2015-12-04 22:00, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8144677 >>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ >>>> >>>> Tested with JPRT with: >>>> ? "-testset hotspot" >>>> ? "-testset svc" >>>> ? "-testset chris" from the example custom testset provided in the >>>> CR. >>>> ? no testset specified >>>> >>>> BTW, if anyone knows of an "include" mechanism for jprt.properties, >>>> please let me know. Although that won't change the need for the above >>>> changes, it would make it possible to put custom testsets in a file >>>> rather than having to paste them in your ~/.jprt.properties file. >>>> >>> JPRT properties files are pretty special, but to my knowledge, there is >>> no include mechanism. I don't think it would be hard to implement >>> though. >> >> They aren't really special they just use Properties.loadFromStream (or >> something like that). To do an include mechanism you'd have to >> implement all the reading and parsing logic yourself. >> > They are special in that there are a lot of constructs not normal to > properties, like ${foo} expansion, weird conditionals and expanding > variants {foo|bar}. Yes but that is what JPRT does after loading the properties. It then post processes them to do expansion etc. > None of these are order dependent however, meaning, > it doesn't matter which order you put the properties in. The evaluation > of all those things happens when a property is read, not when it is > parsed. So the only reasonable implementation of include, at least as I > see it, would be to read a file like now, check a special "include-file" > property for new values and if so, read that file too. Yeah I guess that would work. Though there are some ordering issues as properties read from later files can override values read from earlier ones. In essence this would be a way to add another properties file to the set of files read (jprt distribution, repo, user). But if you want to do that its easier to just add a command-line arg to specify the additional file. Anyway this is going somewhat OT for Chris's change. If someone thinks allowing an additional custom properties file is useful then can file a RFE. Cheers, David > /Erik >> David >> >> >>> /Erik >>> > From david.holmes at oracle.com Tue Dec 8 05:06:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 15:06:12 +1000 Subject: Potential performance improvement for java.util.AbstractList? In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> Message-ID: <56666544.4040401@oracle.com> On 8/12/2015 1:39 AM, Rafael Winterhalter wrote: > In this case, one might consider: > > if (o instanceof java.util.RandomAccess && (List)o).size() != size()) > return false; You'd also have to check the type of 'this'. > Type checks are cheap, so the overhead of this additional statement should > not be too big. Yet, maybe many list comparisons in practice involve lists > of equal size. Otherwise, the contract of the List::equals method would > allow for such a short-wiring. These type of functions are generally already "optimal" for the range of cases they have to accommodate. Invariably you can't improve your case of interest without potentially impacting a lot of other cases. David ----- > 2015-12-07 16:31 GMT+01:00 C?dric Champeau : > >> I assume one reason it's done this way is that depending on the list >> implementation you are using, getting the size might involve iterating over >> all elements, so you would be iterating twice at worst case. >> >> 2015-12-07 16:28 GMT+01:00 Langer, Christoph : >> >>> Hi all, >>> >>> a Java application developer of our company has indicated that it might >>> yield some performance benefit to modify the coding of >>> java.util.AbstractList.equals() that it would first compare the size of >> the >>> lists before iterating the elements. It would for sure be better in cases >>> where one compares lists which don't have the same size. In case of >>> comparing "equal" lists it would add some minor cost, though. >>> >>> Currently the implementation is like this: >>> >>> public boolean equals(Object o) { >>> if (o == this) >>> return true; >>> if (!(o instanceof List)) >>> return false; >>> >>> ListIterator e1 = listIterator(); >>> ListIterator e2 = ((List) o).listIterator(); >>> while (e1.hasNext() && e2.hasNext()) { >>> E o1 = e1.next(); >>> Object o2 = e2.next(); >>> if (!(o1==null ? o2==null : o1.equals(o2))) >>> return false; >>> } >>> return !(e1.hasNext() || e2.hasNext()); >>> } >>> >>> One could do for instance: >>> >>> >>> public boolean equals(Object o) { >>> >>> if (o == this) >>> >>> return true; >>> >>> if (!(o instanceof List)) >>> >>> return false; >>> >>> if ((List)o).size() != size()) >>> >>> return false; >>> >>> >>> >>> ListIterator e1 = listIterator(); >>> >>> ListIterator e2 = ((List) o).listIterator(); >>> >>> while (e1.hasNext() && e2.hasNext()) { >>> >>> E o1 = e1.next(); >>> >>> Object o2 = e2.next(); >>> >>> if (!(o1==null ? o2==null : o1.equals(o2))) >>> >>> return false; >>> >>> } >>> >>> return !(e1.hasNext() || e2.hasNext()); >>> >>> } >>> >>> How would you assess this idea? Are there other drawbacks/showstoppers to >>> this which I don't see? >>> >>> Thanks in advance for comments. >>> >>> Best regards >>> Christoph >>> >>> >> From michael.hixson at gmail.com Tue Dec 8 07:08:52 2015 From: michael.hixson at gmail.com (Michael Hixson) Date: Mon, 7 Dec 2015 23:08:52 -0800 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5666222A.5070204@oracle.com> References: <565E590D.3090007@oracle.com> <5662122A.7020303@oracle.com> <5666222A.5070204@oracle.com> Message-ID: On Mon, Dec 7, 2015 at 4:19 PM, Stuart Marks wrote: > Hi Maurizio, > > Well, maybe we should add five more overloads to EnumSet.of()? (Only > slightly joking here.) > > Setting aside the number of overloads, it would add N more overloads to > Set.of(). I guess the erasure of > would be Enum, so there > wouldn't be any overload ambiguity.... > > To me the question here is whether this adds sufficient value. The advantage > is that one could write > > Set.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) > > instead of > > EnumSet.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) > > and get an optimized EnumSet instead of a Set that contains object > references. Is it worth it? > > Presumably this would result in an instance of an immutable EnumSet. Does > this case come up that often? Maybe the Guava devs would be willing/able to provide usage stats for their Sets.immutableEnumSet(...) compared to ImmutableSet.of(...). -Michael > > s'marks > > > > On 12/4/15 2:22 PM, Maurizio Cimadamore wrote: >> >> Hi Stuart >> small question: I find it a bit odd that EnumSet has max 5 parameters, >> while Set >> has more than that. >> >> Also, would it be possible, maybe to add overloads to Set that >> specifically >> works on Enum constants? >> >> > of(Z z1, Z z2) { ... } >> >> This would give you a way to call Set.of and get different answers based >> on the >> static type of the arguments passed in - and we could deprecate the of >> method in >> EnumSet? >> >> Too subtle/magic? >> >> Maurizio >> >> On 02/12/15 02:35, Stuart Marks wrote: >>> >>> Hi all, >>> >>> Thanks for the previous round of review comments. Here's an updated API >>> and >>> implementation for review. >>> >>> I've run specdiff with the --hu ("hide unchanged") option, so only the >>> bits of >>> the specification that have changed are shown. As before, though, please >>> ignore the spurious change to EnumSet caused by a javadoc bug. >>> >>> API changes: >>> - add clarifying notes on immutability >>> - remove wording that implied creation of new objects >>> - add "value-based" disclaimers >>> - add ordering specification for List and non-ordering disclaimers >>> for Set and Map >>> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >>> instead >>> it extracts keys and values >>> - Map.Entry instances returned from Map.entry() are *not* serializable >>> >>> Other: >>> - markup cleanups >>> - small implementation cleanups >>> >>> JEP: >>> >>> http://openjdk.java.net/jeps/269 >>> >>> API spec (basically List, Map, and Set): >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >>> >>> Specdiff: >>> >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >>> >>> Thanks, >>> >>> s'marks >> >> > From david.holmes at oracle.com Tue Dec 8 08:09:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 18:09:55 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5665D50E.3030606@oracle.com> References: <560D3F61.6040607@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> Message-ID: <56669053.1080404@oracle.com> Hi Roger, Sorry I had no choice but to look at this more closely ... and apologies as this is very late feedback ... I only looked at the API not the details of the implementation. On 8/12/2015 4:50 AM, Roger Riggs wrote: > Hi David, > > Thanks for the comments, > > Updated the javadoc and webrev with editorial changes. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Should cleaning and cleanables be mentioned as part of the package-doc for java.lang.ref? Else they seem to be an overlooked add-on not part of the core reference related functionality. Perhaps even state how they are preferred to use of finalization? Cleaner.Cleanable: It was unclear to me what the usage model was for this. I'm assuming that the intent is that rather than register a "thunk" (lets call it an "action") that can be invoked directly by user-code, the user should invoke the action via the call to clean(). In which case I think it should be explained somewhat more clearly - see below. I would describe the Cleanable class as: Cleanable: Represents an object that has been registered for cleanup by a Cleaner. The object can be cleaned directly, by a call to clean(), if it is no longer to be used, else it will be cleaned automatically when the object becomes phantom-reachable. Cleanable.clean: Unregisters this Cleanable and performs the cleanup action that was associated with it. If this Cleanable has already been unregistered nothing happens. The cleanup action is invoked at most once per registered Cleanable, regardless of the number of calls to clean(). --- Looking at Cleaner .... "Cleaner manages a set of object references and corresponding cleaning functions" I would say "cleaning actions" rather than functions as they yield no value. This change needs to be made throughout. "The most efficient use is to explicitly invoke the clean method when the object is closed or no longer needed. The cleaning function is a Runnable to be invoked at most once when the object is no longer reachable unless it has already been explicitly cleaned." To me this doesn't quite capture the need to not use the Runnable directly. I would rephrase: "In normal use a object should be cleaned up when no longer required, by invoking the clean() method of the associated Cleanable. This guarantees that the cleaning action will be performed at most once per object: either explicitly, or automatically if it becomes phantom-reachable. If cleaned explicitly the object should not be used again. Note that the cleaning action must not refer to the object ..." --- Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? --- The phrase "process the unreachable objects and to invoke cleaning functions" doesn't quite seem right to me. The objects themselves are never processed, or even touched - right? So really the thread is started to "invoke the cleanup actions for unreachable objects". create(): can also throw SecurityException if not allowed to create/start threads. register(Object obj, Runnable thunk): thunk -> action Thanks, David > > > On 12/6/15 7:46 PM, David Holmes wrote: >> Hi Roger, >> >> Sorry to be late here but was trying not to get involved :) >> >> It is already implicit that ThreadFactory.newThread should return >> unstarted threads - that is what a new Thread is - so I don't think >> IllegalThreadStateException needs to be documented here as it is >> documenting behaviour of a broken ThreadFactory (and a broken >> ThreadFactory could throw anything) . > It does seem that new is fairly well understood but one can read of > ThreadFactory is as a bit ambiguous, lacking a direct reference to the > Thread.State of the new thread > and since it allows various attributes of the thread to be modified > after the constructor. > Since the runnable is supplied as an argument it is ready to be started, > why not. > It seemed useful to reinforce the salient points. >> >> Also the no-arg cleaner() can also throw SecurityException. > The thread construction is done in doPriv so it should not throw. > Did I miss some edge case? >> >> Also this: >> >> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >> thread factory} >> 128 * should return a {@link Thread.State#NEW new thread} with >> an appropriate >> 129 * {@linkplain Thread#getContextClassLoader context class >> loader}, >> 130 * {@linkplain Thread#getName() name}, >> 131 * {@linkplain Thread#getPriority() priority}, >> 132 * permissions, etc. >> >> then begs the questions as to what is "appropriate". I think this can >> be said much more simply as: "The ThreadFactory must provide a Thread >> that is suitable for performing the cleaning work". Though even that >> raises questions. I'm not sure why a ThreadFactory is actually needed >> here ?? Special security context? If so that could be mentioned, but I >> don't think name or priority need to be discussed. > It was intended to prod the client to be deliberate about the > threadFactory. > Since the client is integrating the Cleaner and respective cleaning > functions > with the client code, the ThreadFactory makes it possible for the client to > initialize a suitable thread and the comments serve as a reminder. > I agree that the phrase 'suitable for performing the cleaning work' is > the operative one. > > Thanks, Roger >> >> Thanks, >> David >> > From david.holmes at oracle.com Tue Dec 8 08:22:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 18:22:32 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56669053.1080404@oracle.com> References: <560D3F61.6040607@Oracle.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> Message-ID: <56669348.7020603@oracle.com> Actually I'm having more doubts about this API. Library writers use finalize() as a last ditch cleanup mechanism in case the user doesn't explicitly call any "cleanup" method. So as a library writer I would think I am now expected to register my instances with a Cleaner and provide a Runnable that does what finalize() would have done. But in that usage pattern the end user of my objects never has any access to my Cleanables so can never call clean() themselves - instead they should be calling the cleanup function directly, just as they would previously. So the whole "invoke at most once" for the clean() method seems somewhat unnecessary; and the way we should write the cleanup method and the Runnable need to be more cleary explained as the idempotentcy of the cleanup needs to be handled in the library writers code not the Cleaner/Clenable implementation. David On 8/12/2015 6:09 PM, David Holmes wrote: > Hi Roger, > > Sorry I had no choice but to look at this more closely ... and apologies > as this is very late feedback ... I only looked at the API not the > details of the implementation. > > On 8/12/2015 4:50 AM, Roger Riggs wrote: >> Hi David, >> >> Thanks for the comments, >> >> Updated the javadoc and webrev with editorial changes. >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Should cleaning and cleanables be mentioned as part of the package-doc > for java.lang.ref? Else they seem to be an overlooked add-on not part of > the core reference related functionality. Perhaps even state how they > are preferred to use of finalization? > > Cleaner.Cleanable: > > It was unclear to me what the usage model was for this. I'm assuming > that the intent is that rather than register a "thunk" (lets call it an > "action") that can be invoked directly by user-code, the user should > invoke the action via the call to clean(). In which case I think it > should be explained somewhat more clearly - see below. > > I would describe the Cleanable class as: > > Cleanable: Represents an object that has been registered for cleanup by > a Cleaner. The object can be cleaned directly, by a call to clean(), if > it is no longer to be used, else it will be cleaned automatically when > the object becomes phantom-reachable. > > Cleanable.clean: Unregisters this Cleanable and performs the cleanup > action that was associated with it. If this Cleanable has already been > unregistered nothing happens. The cleanup action is invoked at most once > per registered Cleanable, regardless of the number of calls to clean(). > > --- > > Looking at Cleaner .... > > > "Cleaner manages a set of object references and corresponding cleaning > functions" > > I would say "cleaning actions" rather than functions as they yield no > value. This change needs to be made throughout. > > "The most efficient use is to explicitly invoke the clean method when > the object is closed or no longer needed. The cleaning function is a > Runnable to be invoked at most once when the object is no longer > reachable unless it has already been explicitly cleaned." > > To me this doesn't quite capture the need to not use the Runnable > directly. I would rephrase: > > "In normal use a object should be cleaned up when no longer required, by > invoking the clean() method of the associated Cleanable. This guarantees > that the cleaning action will be performed at most once per object: > either explicitly, or automatically if it becomes phantom-reachable. If > cleaned explicitly the object should not be used again. Note that the > cleaning action must not refer to the object ..." > > --- > > Question: what happens if an object is registered simultaneously with > multiple Cleaners? Do we need to warn the user against that? > > --- > > The phrase "process the unreachable objects and to invoke cleaning > functions" doesn't quite seem right to me. The objects themselves are > never processed, or even touched - right? So really the thread is > started to "invoke the cleanup actions for unreachable objects". > > create(): can also throw SecurityException if not allowed to > create/start threads. > > register(Object obj, Runnable thunk): thunk -> action > > Thanks, > David > > >> >> >> On 12/6/15 7:46 PM, David Holmes wrote: >>> Hi Roger, >>> >>> Sorry to be late here but was trying not to get involved :) >>> >>> It is already implicit that ThreadFactory.newThread should return >>> unstarted threads - that is what a new Thread is - so I don't think >>> IllegalThreadStateException needs to be documented here as it is >>> documenting behaviour of a broken ThreadFactory (and a broken >>> ThreadFactory could throw anything) . >> It does seem that new is fairly well understood but one can read of >> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >> Thread.State of the new thread >> and since it allows various attributes of the thread to be modified >> after the constructor. >> Since the runnable is supplied as an argument it is ready to be started, >> why not. >> It seemed useful to reinforce the salient points. >>> >>> Also the no-arg cleaner() can also throw SecurityException. >> The thread construction is done in doPriv so it should not throw. >> Did I miss some edge case? >>> >>> Also this: >>> >>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>> thread factory} >>> 128 * should return a {@link Thread.State#NEW new thread} with >>> an appropriate >>> 129 * {@linkplain Thread#getContextClassLoader context class >>> loader}, >>> 130 * {@linkplain Thread#getName() name}, >>> 131 * {@linkplain Thread#getPriority() priority}, >>> 132 * permissions, etc. >>> >>> then begs the questions as to what is "appropriate". I think this can >>> be said much more simply as: "The ThreadFactory must provide a Thread >>> that is suitable for performing the cleaning work". Though even that >>> raises questions. I'm not sure why a ThreadFactory is actually needed >>> here ?? Special security context? If so that could be mentioned, but I >>> don't think name or priority need to be discussed. >> It was intended to prod the client to be deliberate about the >> threadFactory. >> Since the client is integrating the Cleaner and respective cleaning >> functions >> with the client code, the ThreadFactory makes it possible for the >> client to >> initialize a suitable thread and the comments serve as a reminder. >> I agree that the phrase 'suitable for performing the cleaning work' is >> the operative one. >> >> Thanks, Roger >>> >>> Thanks, >>> David >>> >> From daniel.fuchs at oracle.com Tue Dec 8 08:46:49 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 8 Dec 2015 09:46:49 +0100 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56615354.3080900@oracle.com> Message-ID: <566698F9.7030809@oracle.com> On 12/8/15 1:11 AM, Brian Burkhalter wrote: > The only point of the threads is to provoke a race condition so I > don?t know that it matters in this case. Nonetheless I updated the > test case per the suggestion and verified that it still provokes the > failure in the build not containing the patch. > Thanks Brian, I've been bitten by things like that in the Logging and JMX tests, so now I've learned to keep an eye open for this ;-) best regards, -- daniel From paul.sandoz at oracle.com Tue Dec 8 09:27:46 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Dec 2015 10:27:46 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> Message-ID: <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> Hi, Looks good. Just minor comments. Would you mind limiting the text (not the example code) in the JavaDoc to the 80 limit? Collectors ? 455 * Adapts a {@code Collector} accepting elements of type {@code T} which is filtered by filtering predicate to 456 * each input element before accumulation. Suggest the following: Adapts a {@code Collector} to one accepting elements of the same type {@code T} by applying the predicate to each input element and only accumulating if the predicate returns {@code true} 462 * {@code Employee}, to accumulate the number of employee which is filtered the salaly in each department: Suggest the following: , to accumulate the number of employees in each department that have a salary above a certain threshold: Actually based on your latest email it might be clearer to replace counting() with toList()/toSet() to avoid the ambiguity with toMap and summation: For example, given a stream of {@code Employee}, to accumulate the employees in each department that have a salary above a certain threshold: Map> wellPaidEmployeesByDeparetment = employees.stream().collect(groupingBy(Employee::getDepartment, filtering(e -> e.getSalary() > 2000, toset()))); (Since we don?t specify the monetary units, it is left as an exercise to speculate whether this is well paid or not :-) ). 472 * @param filter a predicate to be applied to the input elements s/filter/predicate (and likewise for the method argument). Thanks, Paul. > On 7 Dec 2015, at 09:59, ShinyaYoshida wrote: > > Hi Paul, > Thank you for your answer. > > I've just updated my webrev to use 9: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.01/ > > Regards, > shinyafox(Shinya Yoshida) > > > 2015-12-07 17:31 GMT+09:00 Paul Sandoz : > >> On 7 Dec 2015, at 03:45, ShinyaYoshida wrote: >> >> Hi, >> I'd like to wait for the review, but I have a trivial question: >> >> Which @since is preferred, 1.9 or 9? >> > > @since 9 > > >> For ex, at Optional#or and stream, @since 9 is used. >> On the other hand, at Collectors#flatMap, @since 1.9 is used. >> > > Feel free to update that to 9. > > I started using @9 a little while ago in anticipation of the new version-string scheme (http://openjdk.java.net/jeps/223). I expect there will be a global sweep through the code updating @since tags. > > Paul. > > > From michael.haupt at oracle.com Tue Dec 8 09:37:22 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 8 Dec 2015 10:37:22 +0100 Subject: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests Message-ID: Dear all, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ The change removes the sun.invoke.anon package and one pertaining test. Thanks, Michael -- 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 is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Tue Dec 8 09:38:32 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 8 Dec 2015 10:38:32 +0100 Subject: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests In-Reply-To: References: Message-ID: <037DB3B4-EAC2-4918-9614-E940292CFBB6@oracle.com> (... please ignore the "and sponsor" part ...) > Am 08.12.2015 um 10:37 schrieb Michael Haupt : > > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ > > The change removes the sun.invoke.anon package and one pertaining test. > > Thanks, > > Michael -- 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 is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Tue Dec 8 09:41:31 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 8 Dec 2015 15:11:31 +0530 Subject: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests In-Reply-To: References: Message-ID: <5666A5CB.6060209@oracle.com> Looks good -Sundar On 12/8/2015 3:07 PM, Michael Haupt wrote: > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ > > The change removes the sun.invoke.anon package and one pertaining test. > > Thanks, > > Michael > From bitterfoxc at gmail.com Tue Dec 8 09:59:37 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 8 Dec 2015 18:59:37 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> Message-ID: Hi Paul, Thank you for your review. (Especially, about doc comment, it's very helpful for non-native speaker like me ;) ) 2015-12-08 18:27 GMT+09:00 Paul Sandoz : > Hi, > > Looks good. > > Just minor comments. > > Would you mind limiting the text (not the example code) in the JavaDoc to > the 80 limit? Oops, I've not minded, I'll be careful. I update my webrev to take your suggestions: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.02/ Regards, shinyafox(Shinya Yoshida) > Collectors > ? > > 455 * Adapts a {@code Collector} accepting elements of type {@code > T} which is filtered by filtering predicate to > 456 * each input element before accumulation. > > Suggest the following: > > Adapts a {@code Collector} to one accepting elements of the same type > {@code T} > by applying the predicate to each input element and only accumulating if > the predicate returns {@code true} > > > 462 * {@code Employee}, to accumulate the number of employee which > is filtered the salaly in each department: > > Suggest the following: > > , to accumulate the number of employees in each department > that have a salary above a certain threshold: > > Actually based on your latest email it might be clearer to replace > counting() with toList()/toSet() to avoid the ambiguity with toMap and > summation: > > For example, given a stream of {@code Employee}, to accumulate the > employees in > each department that have a salary above a certain threshold: > > Map> wellPaidEmployeesByDeparetment > = employees.stream().collect(groupingBy(Employee::getDepartment, > filtering(e -> > e.getSalary() > 2000, toset()))); > > > (Since we don?t specify the monetary units, it is left as an exercise to > speculate whether this is well paid or not :-) ). > > > 472 * @param filter a predicate to be applied to the input elements > > s/filter/predicate (and likewise for the method argument). > > > Thanks, > Paul. > > > On 7 Dec 2015, at 09:59, ShinyaYoshida wrote: > > > > Hi Paul, > > Thank you for your answer. > > > > I've just updated my webrev to use 9: > > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.01/ > > > > Regards, > > shinyafox(Shinya Yoshida) > > > > > > 2015-12-07 17:31 GMT+09:00 Paul Sandoz : > > > >> On 7 Dec 2015, at 03:45, ShinyaYoshida wrote: > >> > >> Hi, > >> I'd like to wait for the review, but I have a trivial question: > >> > >> Which @since is preferred, 1.9 or 9? > >> > > > > @since 9 > > > > > >> For ex, at Optional#or and stream, @since 9 is used. > >> On the other hand, at Collectors#flatMap, @since 1.9 is used. > >> > > > > Feel free to update that to 9. > > > > I started using @9 a little while ago in anticipation of the new > version-string scheme (http://openjdk.java.net/jeps/223). I expect there > will be a global sweep through the code updating @since tags. > > > > Paul. > > > > > > > > From jaromir.hamala at gmail.com Tue Dec 8 10:12:56 2015 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Tue, 8 Dec 2015 12:12:56 +0200 Subject: ConcurrentMap::compute clarification Message-ID: Hi, I stumbled upon an interesting issue with default implementation of `compute(K key, BiFunction remappingFunction)` in JDK8 `ConcurrentMap`. According to its contract the default method implementation assumes map implementations do not support null values. This is the begin of the default implementation: default V compute(K key, BiFunction remappingFunction) { Objects.requireNonNull(remappingFunction); V oldValue = get(key); for(;;) { V newValue = remappingFunction.apply(key, oldValue); if (newValue == null) { // delete mapping if (oldValue != null || containsKey(key)) { // something to remove if (remove(key, oldValue)) { [...] Let's say we have an empty map and 2 threads: T1 is calling the `compute('foo', someFunction)` T2 is concurrently calling calling `put('foo', 'bar');` so the T1 will get `oldValue = null`, but `containsKey()` will return `true` - because T2 already created the mapping `foo -> bar`. Hence T1 will call `remove('foo', null)` ! Contract of `remove()` says: `throws NullPointerException if the specified key or value is null, and this map does not permit null keys or values optional.` -> the T1 will throw NPE. Is it a bug in default method impl or do I understand it wrong? Cheers, Jaromir -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From sean.coffey at oracle.com Tue Dec 8 10:38:53 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 8 Dec 2015 10:38:53 +0000 Subject: RFR: JDK-8142508: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk In-Reply-To: <5665D814.8010201@oracle.com> References: <5643A368.7010207@oracle.com> <5665B91E.2010209@oracle.com> <5665D814.8010201@oracle.com> Message-ID: <5666B33D.8010300@oracle.com> Looks good Sherman. I'll look after the possible zerror enhancement as part of https://bugs.openjdk.java.net/browse/JDK-8144055 I think printing just the file name itself without path is safe. We could decide whether installation of a security manager should be a factor for such cases. Zip exceptions often come to us without a hint of which file was being worked on at time of exception. It'll certainly help to have this info. Regards, Sean. On 07/12/2015 19:03, Xueming Shen wrote: > Hi Sean, > > Thanks for the review. Webrev has been updated accordingly. The > only suggestion I did not follow is to append the file name into the > zip error/exception message. I would assume it might have vuln > concern if the file name is published in such exception. It might be > OK to only publish the "name" part (exclude the parent path) in such > scenario, but I would prefer to leave this to a separate rfe, if desired. > > http://cr.openjdk.java.net/~sherman/8142508/webrev > > Thanks, > Sherman > > On 12/07/2015 08:51 AM, Se?n Coffey wrote: >> Hi Sherman, >> >> Nice work. It'll certainly help protect the VM from bad application >> code. I've no major issues with the new code. Some comments below. >> >> src/java.base/share/classes/java/util/zip/ZipFile.java >> unused import : >>> import java.nio.file.Path; >> >> line 840 : This could be marked final >>> private Key key; >> >> line 914 : Same here (final) >> >>> private static HashMap files = new HashMap<>(); >> >> While in this class, could you also mark inflaterCache as final (line >> 451) >> >> >> - String prop = >> sun.misc.VM.getSavedProperty("sun.zip.disableMemoryMapping"); >> With this property removed, I think you'll need to update >> src/java.base/share/classes/sun/misc/VM.java line 278 also. It >> becomes redundant code. >> >> We'll also need to log a sub-task to track doc updates to highlight >> that this property is no longer relevant. >> >> ZipFile : line 195 : >> >> Objects.requireNonNull(charset, "charset"); >> >> You've changed the order of exception throwing here. To aid with a >> possible backport (and behaviour), could you consider moving the >> check to post the 'mode' checks ? If you can't, I'll just remember it >> when backporting! >> >> line 525 : >> >> byte[] cen = zsrc.cen; >> >> It might be no harm to insert a comment here saying that the caller >> method must check for 'ensureOpen' ? >> >> I think you need a ensureOpen check on the new initDataOffset() >> method. You could hit an NPE otherwise. E.g. : >>> ZipFile zf = new ZipFile(new File("/tmp/jtreg.zip")); >>> ZipEntry ze = zf.getEntry("jtreg/release"); >>> InputStream is = zf.getInputStream(ze); >>> zf.close(); >>> is.skip(1); >> >> There might be room for a small improvement on the zerror method. Could >> you pre-append the name of the File to each exception message via >> this method ? >> >> On the new test, are you planning to add this to the jtreg tests or >> will it be >> a manual stand alone ? It would have to be tuned down in terms of >> resources >> if added to the auto-test list. >> Regards, >> Sean. >> On 11/11/15 20:22, Xueming Shen wrote: >>> Hi >>> >>> Please help review the changes for JDK-8142508 (third try) >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 >>> webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev >>> >>> Mainly to address the issues in current j.u.z.ZipFile implementation >>> as listed >>> below >>> >>> (1) The ZIP file format support code is in native C (shared with the >>> VM via >>> ZipFile.c -> zip_util.c). Any entry lookup, creation operation >>> requires multiple >>> round-trips of expensive jni calls. >>> >>> (2) The native C implementation which uses mmap to map in the >>> central directory >>> table appears to be a big risk of vm crash when the underlying >>> jar file gets >>> overwritten with new contents while it is still being used by >>> other ZipFile. The >>> crash reports keep coming in even after we have introduced in >>> system flag >>> to disable it (sun.zip.disableMemoryMapping). >>> >>> (3) The use of "filename + lastModified()" cache (zip_util.c) >>> appears to be broken >>> if the timestamp is in low resolution/precision >>> (File.getModified() for example, >>> might only have "second" ersolution on solaris/linux), and/or >>> the file is being >>> overwritten. >>> >>> The clean solution appears to bring the ZIP format support code >>> completely from >>> native to Java to remove the jni invocation cost and the mmap risk. >>> Also to use >>> the fileKey and lastModified from >>> java.nio.file.attribute.BasicFileAttributes to have >>> better/correct cache matching. >>> >>> Benchmark: >>> >>> This simple jmh measurement suggests a big boost of the performance of >>> ZipFile.getEntry()/entries()/getStream() which are basically entry >>> related >>> accesses (the "open only" has some regression, which is expected as we >>> switched from the mmap to simply read the cen table in into a byte[]) >>> >>> http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java >>> >>> # JDK9 base >>> >>> Benchmark Mode Cnt Score Error Units >>> MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op >>> MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op >>> MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op >>> MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op >>> MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op >>> MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op >>> -------------------------------------------------------------------------------------- >>> >>> # JDK9 ZipFile without jni invocation >>> >>> Benchmark Mode Cnt Score Error Units >>> MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op >>> MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op >>> MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op >>> MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op >>> MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op >>> MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op >>> --------------------------------------------------------------------------------------- >>> >>> >>> Test: >>> http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html >>> >>> >>> Verified the new ZipFile runs as expected when the underlying >>> jar/zip file get >>> deleted/overwritten when the zip still be used. The "old" ZipFile >>> fails to continue >>> to work but no crash, and the "new" one works correctly on updated >>> zip file >>> without problem (The test runs a little long, have not decided if it >>> should be >>> checked in as unit test). >>> >>> -Sherman >>> >> > From paul.sandoz at oracle.com Tue Dec 8 11:25:03 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Dec 2015 12:25:03 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> Message-ID: <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> > On 8 Dec 2015, at 10:59, ShinyaYoshida wrote: > > Hi Paul, > Thank you for your review. > (Especially, about doc comment, it's very helpful for non-native speaker like me ;) ) > No problem. FWIW i am a native speaker and i find the documentation/specification the hardest part. > 2015-12-08 18:27 GMT+09:00 Paul Sandoz : > Hi, > > Looks good. > > Just minor comments. > > Would you mind limiting the text (not the example code) in the JavaDoc to the 80 limit? > > Oops, I've not minded, I'll be careful. > > I update my webrev to take your suggestions: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.02/ > Small thing i forgot to mention last time (and i often forget myself): CollectorsTest ? 76 * @bug 8071600 You need to include 8144675 in the above (space separated list) No need for another review. I will push this week along with Tagir?s patch as well. Many thanks, Paul. From bitterfoxc at gmail.com Tue Dec 8 12:04:45 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 8 Dec 2015 21:04:45 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> Message-ID: Thank you so much! I've updated in webrev.02. Best regard, shinyafox(Shinya Yoshida) 2015-12-08 20:25 GMT+09:00 Paul Sandoz : > > > On 8 Dec 2015, at 10:59, ShinyaYoshida wrote: > > > > Hi Paul, > > Thank you for your review. > > (Especially, about doc comment, it's very helpful for non-native speaker > like me ;) ) > > > > No problem. FWIW i am a native speaker and i find the > documentation/specification the hardest part. > > > > 2015-12-08 18:27 GMT+09:00 Paul Sandoz : > > Hi, > > > > Looks good. > > > > Just minor comments. > > > > Would you mind limiting the text (not the example code) in the JavaDoc > to the 80 limit? > > > > Oops, I've not minded, I'll be careful. > > > > I update my webrev to take your suggestions: > > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.02/ > > > > Small thing i forgot to mention last time (and i often forget myself): > > CollectorsTest > ? > > 76 * @bug 8071600 > > You need to include 8144675 in the above (space separated list) > > No need for another review. I will push this week along with Tagir?s patch > as well. > > Many thanks, > Paul. > From spliterator at gmail.com Tue Dec 8 12:08:16 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Tue, 8 Dec 2015 13:08:16 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> Message-ID: Hi shinyafox, minor typo in the code example: s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment Regards, Stefan 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : > Thank you so much! > I've updated in webrev.02. > > Best regard, > shinyafox(Shinya Yoshida) > From vitalyd at gmail.com Tue Dec 8 12:17:17 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Dec 2015 07:17:17 -0500 Subject: Potential performance improvement for java.util.AbstractList? In-Reply-To: <56666544.4040401@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F83543@DEWDFEMB12B.global.corp.sap> <56666544.4040401@oracle.com> Message-ID: sent from my phone On Dec 8, 2015 12:07 AM, "David Holmes" wrote: > > On 8/12/2015 1:39 AM, Rafael Winterhalter wrote: >> >> In this case, one might consider: >> >> if (o instanceof java.util.RandomAccess && (List)o).size() != size()) >> return false; > > > You'd also have to check the type of 'this'. Which also begs the question of why not override this in subclasses that have fast size(). Yes there may be some duplication but it's "simple" duplication Also, I don't think RandomAccess says anything about size() necessarily being constant time. Really, subclasses are in better position to determine this (short of another marker interface to indicate constant time size()). > > >> Type checks are cheap, so the overhead of this additional statement should >> not be too big. Yet, maybe many list comparisons in practice involve lists >> of equal size. Otherwise, the contract of the List::equals method would >> allow for such a short-wiring. > > > These type of functions are generally already "optimal" for the range of cases they have to accommodate. Invariably you can't improve your case of interest without potentially impacting a lot of other cases. > > David > ----- > > >> 2015-12-07 16:31 GMT+01:00 C?dric Champeau : >> >>> I assume one reason it's done this way is that depending on the list >>> implementation you are using, getting the size might involve iterating over >>> all elements, so you would be iterating twice at worst case. >>> >>> 2015-12-07 16:28 GMT+01:00 Langer, Christoph : >>> >>>> Hi all, >>>> >>>> a Java application developer of our company has indicated that it might >>>> yield some performance benefit to modify the coding of >>>> java.util.AbstractList.equals() that it would first compare the size of >>> >>> the >>>> >>>> lists before iterating the elements. It would for sure be better in cases >>>> where one compares lists which don't have the same size. In case of >>>> comparing "equal" lists it would add some minor cost, though. >>>> >>>> Currently the implementation is like this: >>>> >>>> public boolean equals(Object o) { >>>> if (o == this) >>>> return true; >>>> if (!(o instanceof List)) >>>> return false; >>>> >>>> ListIterator e1 = listIterator(); >>>> ListIterator e2 = ((List) o).listIterator(); >>>> while (e1.hasNext() && e2.hasNext()) { >>>> E o1 = e1.next(); >>>> Object o2 = e2.next(); >>>> if (!(o1==null ? o2==null : o1.equals(o2))) >>>> return false; >>>> } >>>> return !(e1.hasNext() || e2.hasNext()); >>>> } >>>> >>>> One could do for instance: >>>> >>>> >>>> public boolean equals(Object o) { >>>> >>>> if (o == this) >>>> >>>> return true; >>>> >>>> if (!(o instanceof List)) >>>> >>>> return false; >>>> >>>> if ((List)o).size() != size()) >>>> >>>> return false; >>>> >>>> >>>> >>>> ListIterator e1 = listIterator(); >>>> >>>> ListIterator e2 = ((List) o).listIterator(); >>>> >>>> while (e1.hasNext() && e2.hasNext()) { >>>> >>>> E o1 = e1.next(); >>>> >>>> Object o2 = e2.next(); >>>> >>>> if (!(o1==null ? o2==null : o1.equals(o2))) >>>> >>>> return false; >>>> >>>> } >>>> >>>> return !(e1.hasNext() || e2.hasNext()); >>>> >>>> } >>>> >>>> How would you assess this idea? Are there other drawbacks/showstoppers to >>>> this which I don't see? >>>> >>>> Thanks in advance for comments. >>>> >>>> Best regards >>>> Christoph >>>> >>>> >>> From bitterfoxc at gmail.com Tue Dec 8 12:21:35 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Tue, 8 Dec 2015 21:21:35 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> Message-ID: Hi Stefan, Thank you for pointing out. I've just updated: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.03/ Regards, shinyafox(Shinya Yoshida) 2015-12-08 21:08 GMT+09:00 Stefan Zobel : > Hi shinyafox, > > minor typo in the code example: > > > s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment > > > Regards, > Stefan > > > 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : > > Thank you so much! > > I've updated in webrev.02. > > > > Best regard, > > shinyafox(Shinya Yoshida) > > > From peter.levart at gmail.com Tue Dec 8 12:25:47 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Dec 2015 13:25:47 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56669348.7020603@oracle.com> References: <560D3F61.6040607@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> Message-ID: <5666CC4B.9020303@gmail.com> On 12/08/2015 09:22 AM, David Holmes wrote: > Actually I'm having more doubts about this API. > > Library writers use finalize() as a last ditch cleanup mechanism in > case the user doesn't explicitly call any "cleanup" method. So as a > library writer I would think I am now expected to register my > instances with a Cleaner and provide a Runnable that does what > finalize() would have done. But in that usage pattern the end user of > my objects never has any access to my Cleanables so can never call > clean() themselves - instead they should be calling the cleanup > function directly, just as they would previously. So the whole "invoke > at most once" for the clean() method seems somewhat unnecessary; and > the way we should write the cleanup method and the Runnable need to be > more cleary explained as the idempotentcy of the cleanup needs to be > handled in the library writers code not the Cleaner/Clenable > implementation. > > David Hi David, (once again for the list) I agree that an example would be most helpful. Here's how a normal finalizable object is typically coded: public class FinalizeExample implements AutoCloseable { private boolean closed; @Override public synchronized void close() { if (!closed) { closed = true; // cleanup actions accessing state of FinalizeExample, executed at most once } } @Override protected void finalize() throws Throwable { close(); } } Re-factoring to use Cleaner is a process that extracts the state representing native resource from the user-facing class into a private nested static class and makes the user-facing object just a facade that has access to the state object and is registered with a Cleaner. The Cleaner.Cleanable instance is also made accessible from the user-facing object, so it can provide the on-demand cleaning: public static class CleanerExample implements AutoCloseable { private static class State implements Runnable { @Override public void run() { // cleanup actions accessing State, executed at most once } } private static final Cleaner cleaner = Cleaner.create(); private final State state = new State(); private final Cleaner.Cleanable cleanable = cleaner.register(this, state); @Override public void close() { cleanable.clean(); } } Regards, Peter > > On 8/12/2015 6:09 PM, David Holmes wrote: >> Hi Roger, >> >> Sorry I had no choice but to look at this more closely ... and apologies >> as this is very late feedback ... I only looked at the API not the >> details of the implementation. >> >> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>> Hi David, >>> >>> Thanks for the comments, >>> >>> Updated the javadoc and webrev with editorial changes. >>> >>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> Should cleaning and cleanables be mentioned as part of the package-doc >> for java.lang.ref? Else they seem to be an overlooked add-on not part of >> the core reference related functionality. Perhaps even state how they >> are preferred to use of finalization? >> >> Cleaner.Cleanable: >> >> It was unclear to me what the usage model was for this. I'm assuming >> that the intent is that rather than register a "thunk" (lets call it an >> "action") that can be invoked directly by user-code, the user should >> invoke the action via the call to clean(). In which case I think it >> should be explained somewhat more clearly - see below. >> >> I would describe the Cleanable class as: >> >> Cleanable: Represents an object that has been registered for cleanup by >> a Cleaner. The object can be cleaned directly, by a call to clean(), if >> it is no longer to be used, else it will be cleaned automatically when >> the object becomes phantom-reachable. >> >> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >> action that was associated with it. If this Cleanable has already been >> unregistered nothing happens. The cleanup action is invoked at most once >> per registered Cleanable, regardless of the number of calls to clean(). >> >> --- >> >> Looking at Cleaner .... >> >> >> "Cleaner manages a set of object references and corresponding cleaning >> functions" >> >> I would say "cleaning actions" rather than functions as they yield no >> value. This change needs to be made throughout. >> >> "The most efficient use is to explicitly invoke the clean method when >> the object is closed or no longer needed. The cleaning function is a >> Runnable to be invoked at most once when the object is no longer >> reachable unless it has already been explicitly cleaned." >> >> To me this doesn't quite capture the need to not use the Runnable >> directly. I would rephrase: >> >> "In normal use a object should be cleaned up when no longer required, by >> invoking the clean() method of the associated Cleanable. This guarantees >> that the cleaning action will be performed at most once per object: >> either explicitly, or automatically if it becomes phantom-reachable. If >> cleaned explicitly the object should not be used again. Note that the >> cleaning action must not refer to the object ..." >> >> --- >> >> Question: what happens if an object is registered simultaneously with >> multiple Cleaners? Do we need to warn the user against that? >> >> --- >> >> The phrase "process the unreachable objects and to invoke cleaning >> functions" doesn't quite seem right to me. The objects themselves are >> never processed, or even touched - right? So really the thread is >> started to "invoke the cleanup actions for unreachable objects". >> >> create(): can also throw SecurityException if not allowed to >> create/start threads. >> >> register(Object obj, Runnable thunk): thunk -> action >> >> Thanks, >> David >> >> >>> >>> >>> On 12/6/15 7:46 PM, David Holmes wrote: >>>> Hi Roger, >>>> >>>> Sorry to be late here but was trying not to get involved :) >>>> >>>> It is already implicit that ThreadFactory.newThread should return >>>> unstarted threads - that is what a new Thread is - so I don't think >>>> IllegalThreadStateException needs to be documented here as it is >>>> documenting behaviour of a broken ThreadFactory (and a broken >>>> ThreadFactory could throw anything) . >>> It does seem that new is fairly well understood but one can read of >>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>> Thread.State of the new thread >>> and since it allows various attributes of the thread to be modified >>> after the constructor. >>> Since the runnable is supplied as an argument it is ready to be >>> started, >>> why not. >>> It seemed useful to reinforce the salient points. >>>> >>>> Also the no-arg cleaner() can also throw SecurityException. >>> The thread construction is done in doPriv so it should not throw. >>> Did I miss some edge case? >>>> >>>> Also this: >>>> >>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>> thread factory} >>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>> an appropriate >>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>> loader}, >>>> 130 * {@linkplain Thread#getName() name}, >>>> 131 * {@linkplain Thread#getPriority() priority}, >>>> 132 * permissions, etc. >>>> >>>> then begs the questions as to what is "appropriate". I think this can >>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>> that is suitable for performing the cleaning work". Though even that >>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>> here ?? Special security context? If so that could be mentioned, but I >>>> don't think name or priority need to be discussed. >>> It was intended to prod the client to be deliberate about the >>> threadFactory. >>> Since the client is integrating the Cleaner and respective cleaning >>> functions >>> with the client code, the ThreadFactory makes it possible for the >>> client to >>> initialize a suitable thread and the comments serve as a reminder. >>> I agree that the phrase 'suitable for performing the cleaning work' is >>> the operative one. >>> >>> Thanks, Roger >>>> >>>> Thanks, >>>> David >>>> >>> From david.holmes at oracle.com Tue Dec 8 12:29:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 22:29:33 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666CC4B.9020303@gmail.com> References: <560D3F61.6040607@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> Message-ID: <5666CD2D.3080402@oracle.com> On 8/12/2015 10:25 PM, Peter Levart wrote: > > > On 12/08/2015 09:22 AM, David Holmes wrote: >> Actually I'm having more doubts about this API. >> >> Library writers use finalize() as a last ditch cleanup mechanism in >> case the user doesn't explicitly call any "cleanup" method. So as a >> library writer I would think I am now expected to register my >> instances with a Cleaner and provide a Runnable that does what >> finalize() would have done. But in that usage pattern the end user of >> my objects never has any access to my Cleanables so can never call >> clean() themselves - instead they should be calling the cleanup >> function directly, just as they would previously. So the whole "invoke >> at most once" for the clean() method seems somewhat unnecessary; and >> the way we should write the cleanup method and the Runnable need to be >> more cleary explained as the idempotentcy of the cleanup needs to be >> handled in the library writers code not the Cleaner/Clenable >> implementation. >> >> David > > Hi David, (once again for the list) Thanks Peter! :) > I agree that an example would be most helpful. Here's how a normal > finalizable object is typically coded: > > public class FinalizeExample implements AutoCloseable { > > private boolean closed; > > @Override > public synchronized void close() { > if (!closed) { > closed = true; > // cleanup actions accessing state of FinalizeExample, > executed at most once > } > } > > @Override > protected void finalize() throws Throwable { > close(); > } > } > > > Re-factoring to use Cleaner is a process that extracts the state > representing native resource from the user-facing class into a private > nested static class and makes the user-facing object just a facade that > has access to the state object and is registered with a Cleaner. The > Cleaner.Cleanable instance is also made accessible from the user-facing > object, so it can provide the on-demand cleaning: > > public static class CleanerExample implements AutoCloseable { > > private static class State implements Runnable { > @Override > public void run() { > // cleanup actions accessing State, executed at most once > } > } > > private static final Cleaner cleaner = Cleaner.create(); > > private final State state = new State(); > private final Cleaner.Cleanable cleanable = > cleaner.register(this, state); > > @Override > public void close() { > cleanable.clean(); > } > } Thanks for clarifying that - the process is really quite different compared to using the finalize() approach. This certainly needs to be included in the documentation as an example, and also used to guide the javadoc descriptions. Thanks again, David > > Regards, Peter > >> >> On 8/12/2015 6:09 PM, David Holmes wrote: >>> Hi Roger, >>> >>> Sorry I had no choice but to look at this more closely ... and apologies >>> as this is very late feedback ... I only looked at the API not the >>> details of the implementation. >>> >>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>> Hi David, >>>> >>>> Thanks for the comments, >>>> >>>> Updated the javadoc and webrev with editorial changes. >>>> >>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> Should cleaning and cleanables be mentioned as part of the package-doc >>> for java.lang.ref? Else they seem to be an overlooked add-on not part of >>> the core reference related functionality. Perhaps even state how they >>> are preferred to use of finalization? >>> >>> Cleaner.Cleanable: >>> >>> It was unclear to me what the usage model was for this. I'm assuming >>> that the intent is that rather than register a "thunk" (lets call it an >>> "action") that can be invoked directly by user-code, the user should >>> invoke the action via the call to clean(). In which case I think it >>> should be explained somewhat more clearly - see below. >>> >>> I would describe the Cleanable class as: >>> >>> Cleanable: Represents an object that has been registered for cleanup by >>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>> it is no longer to be used, else it will be cleaned automatically when >>> the object becomes phantom-reachable. >>> >>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>> action that was associated with it. If this Cleanable has already been >>> unregistered nothing happens. The cleanup action is invoked at most once >>> per registered Cleanable, regardless of the number of calls to clean(). >>> >>> --- >>> >>> Looking at Cleaner .... >>> >>> >>> "Cleaner manages a set of object references and corresponding cleaning >>> functions" >>> >>> I would say "cleaning actions" rather than functions as they yield no >>> value. This change needs to be made throughout. >>> >>> "The most efficient use is to explicitly invoke the clean method when >>> the object is closed or no longer needed. The cleaning function is a >>> Runnable to be invoked at most once when the object is no longer >>> reachable unless it has already been explicitly cleaned." >>> >>> To me this doesn't quite capture the need to not use the Runnable >>> directly. I would rephrase: >>> >>> "In normal use a object should be cleaned up when no longer required, by >>> invoking the clean() method of the associated Cleanable. This guarantees >>> that the cleaning action will be performed at most once per object: >>> either explicitly, or automatically if it becomes phantom-reachable. If >>> cleaned explicitly the object should not be used again. Note that the >>> cleaning action must not refer to the object ..." >>> >>> --- >>> >>> Question: what happens if an object is registered simultaneously with >>> multiple Cleaners? Do we need to warn the user against that? >>> >>> --- >>> >>> The phrase "process the unreachable objects and to invoke cleaning >>> functions" doesn't quite seem right to me. The objects themselves are >>> never processed, or even touched - right? So really the thread is >>> started to "invoke the cleanup actions for unreachable objects". >>> >>> create(): can also throw SecurityException if not allowed to >>> create/start threads. >>> >>> register(Object obj, Runnable thunk): thunk -> action >>> >>> Thanks, >>> David >>> >>> >>>> >>>> >>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>> Hi Roger, >>>>> >>>>> Sorry to be late here but was trying not to get involved :) >>>>> >>>>> It is already implicit that ThreadFactory.newThread should return >>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>> IllegalThreadStateException needs to be documented here as it is >>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>> ThreadFactory could throw anything) . >>>> It does seem that new is fairly well understood but one can read of >>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>> Thread.State of the new thread >>>> and since it allows various attributes of the thread to be modified >>>> after the constructor. >>>> Since the runnable is supplied as an argument it is ready to be >>>> started, >>>> why not. >>>> It seemed useful to reinforce the salient points. >>>>> >>>>> Also the no-arg cleaner() can also throw SecurityException. >>>> The thread construction is done in doPriv so it should not throw. >>>> Did I miss some edge case? >>>>> >>>>> Also this: >>>>> >>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>> thread factory} >>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>> an appropriate >>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>> loader}, >>>>> 130 * {@linkplain Thread#getName() name}, >>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>> 132 * permissions, etc. >>>>> >>>>> then begs the questions as to what is "appropriate". I think this can >>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>> that is suitable for performing the cleaning work". Though even that >>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>> here ?? Special security context? If so that could be mentioned, but I >>>>> don't think name or priority need to be discussed. >>>> It was intended to prod the client to be deliberate about the >>>> threadFactory. >>>> Since the client is integrating the Cleaner and respective cleaning >>>> functions >>>> with the client code, the ThreadFactory makes it possible for the >>>> client to >>>> initialize a suitable thread and the comments serve as a reminder. >>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>> the operative one. >>>> >>>> Thanks, Roger >>>>> >>>>> Thanks, >>>>> David >>>>> >>>> > From david.holmes at oracle.com Tue Dec 8 12:44:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 22:44:35 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666CD2D.3080402@oracle.com> References: <560D3F61.6040607@Oracle.com> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> Message-ID: <5666D0B3.7070905@oracle.com> But thinking more on this approach this is simply not scalable. A Cleaner per cleanable-class could result in hundreds of threads being active! And this certainly does not seem easier to use than finalization. What exactly are the advantages over finalization again? Thanks, David On 8/12/2015 10:29 PM, David Holmes wrote: > On 8/12/2015 10:25 PM, Peter Levart wrote: >> >> >> On 12/08/2015 09:22 AM, David Holmes wrote: >>> Actually I'm having more doubts about this API. >>> >>> Library writers use finalize() as a last ditch cleanup mechanism in >>> case the user doesn't explicitly call any "cleanup" method. So as a >>> library writer I would think I am now expected to register my >>> instances with a Cleaner and provide a Runnable that does what >>> finalize() would have done. But in that usage pattern the end user of >>> my objects never has any access to my Cleanables so can never call >>> clean() themselves - instead they should be calling the cleanup >>> function directly, just as they would previously. So the whole "invoke >>> at most once" for the clean() method seems somewhat unnecessary; and >>> the way we should write the cleanup method and the Runnable need to be >>> more cleary explained as the idempotentcy of the cleanup needs to be >>> handled in the library writers code not the Cleaner/Clenable >>> implementation. >>> >>> David >> >> Hi David, (once again for the list) > > Thanks Peter! :) > >> I agree that an example would be most helpful. Here's how a normal >> finalizable object is typically coded: >> >> public class FinalizeExample implements AutoCloseable { >> >> private boolean closed; >> >> @Override >> public synchronized void close() { >> if (!closed) { >> closed = true; >> // cleanup actions accessing state of FinalizeExample, >> executed at most once >> } >> } >> >> @Override >> protected void finalize() throws Throwable { >> close(); >> } >> } >> >> >> Re-factoring to use Cleaner is a process that extracts the state >> representing native resource from the user-facing class into a private >> nested static class and makes the user-facing object just a facade that >> has access to the state object and is registered with a Cleaner. The >> Cleaner.Cleanable instance is also made accessible from the user-facing >> object, so it can provide the on-demand cleaning: >> >> public static class CleanerExample implements AutoCloseable { >> >> private static class State implements Runnable { >> @Override >> public void run() { >> // cleanup actions accessing State, executed at most >> once >> } >> } >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final State state = new State(); >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this, state); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } > > Thanks for clarifying that - the process is really quite different > compared to using the finalize() approach. This certainly needs to be > included in the documentation as an example, and also used to guide the > javadoc descriptions. > > Thanks again, > David > >> >> Regards, Peter >> >>> >>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>> Hi Roger, >>>> >>>> Sorry I had no choice but to look at this more closely ... and >>>> apologies >>>> as this is very late feedback ... I only looked at the API not the >>>> details of the implementation. >>>> >>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>> Hi David, >>>>> >>>>> Thanks for the comments, >>>>> >>>>> Updated the javadoc and webrev with editorial changes. >>>>> >>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>> >>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>> part of >>>> the core reference related functionality. Perhaps even state how they >>>> are preferred to use of finalization? >>>> >>>> Cleaner.Cleanable: >>>> >>>> It was unclear to me what the usage model was for this. I'm assuming >>>> that the intent is that rather than register a "thunk" (lets call it an >>>> "action") that can be invoked directly by user-code, the user should >>>> invoke the action via the call to clean(). In which case I think it >>>> should be explained somewhat more clearly - see below. >>>> >>>> I would describe the Cleanable class as: >>>> >>>> Cleanable: Represents an object that has been registered for cleanup by >>>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>>> it is no longer to be used, else it will be cleaned automatically when >>>> the object becomes phantom-reachable. >>>> >>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>> action that was associated with it. If this Cleanable has already been >>>> unregistered nothing happens. The cleanup action is invoked at most >>>> once >>>> per registered Cleanable, regardless of the number of calls to clean(). >>>> >>>> --- >>>> >>>> Looking at Cleaner .... >>>> >>>> >>>> "Cleaner manages a set of object references and corresponding cleaning >>>> functions" >>>> >>>> I would say "cleaning actions" rather than functions as they yield no >>>> value. This change needs to be made throughout. >>>> >>>> "The most efficient use is to explicitly invoke the clean method when >>>> the object is closed or no longer needed. The cleaning function is a >>>> Runnable to be invoked at most once when the object is no longer >>>> reachable unless it has already been explicitly cleaned." >>>> >>>> To me this doesn't quite capture the need to not use the Runnable >>>> directly. I would rephrase: >>>> >>>> "In normal use a object should be cleaned up when no longer >>>> required, by >>>> invoking the clean() method of the associated Cleanable. This >>>> guarantees >>>> that the cleaning action will be performed at most once per object: >>>> either explicitly, or automatically if it becomes phantom-reachable. If >>>> cleaned explicitly the object should not be used again. Note that the >>>> cleaning action must not refer to the object ..." >>>> >>>> --- >>>> >>>> Question: what happens if an object is registered simultaneously with >>>> multiple Cleaners? Do we need to warn the user against that? >>>> >>>> --- >>>> >>>> The phrase "process the unreachable objects and to invoke cleaning >>>> functions" doesn't quite seem right to me. The objects themselves are >>>> never processed, or even touched - right? So really the thread is >>>> started to "invoke the cleanup actions for unreachable objects". >>>> >>>> create(): can also throw SecurityException if not allowed to >>>> create/start threads. >>>> >>>> register(Object obj, Runnable thunk): thunk -> action >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> >>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Sorry to be late here but was trying not to get involved :) >>>>>> >>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>> ThreadFactory could throw anything) . >>>>> It does seem that new is fairly well understood but one can read of >>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>>> Thread.State of the new thread >>>>> and since it allows various attributes of the thread to be modified >>>>> after the constructor. >>>>> Since the runnable is supplied as an argument it is ready to be >>>>> started, >>>>> why not. >>>>> It seemed useful to reinforce the salient points. >>>>>> >>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>> The thread construction is done in doPriv so it should not throw. >>>>> Did I miss some edge case? >>>>>> >>>>>> Also this: >>>>>> >>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>> thread factory} >>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>> an appropriate >>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>> loader}, >>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>> 132 * permissions, etc. >>>>>> >>>>>> then begs the questions as to what is "appropriate". I think this can >>>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>>> that is suitable for performing the cleaning work". Though even that >>>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>>> here ?? Special security context? If so that could be mentioned, >>>>>> but I >>>>>> don't think name or priority need to be discussed. >>>>> It was intended to prod the client to be deliberate about the >>>>> threadFactory. >>>>> Since the client is integrating the Cleaner and respective cleaning >>>>> functions >>>>> with the client code, the ThreadFactory makes it possible for the >>>>> client to >>>>> initialize a suitable thread and the comments serve as a reminder. >>>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>>> the operative one. >>>>> >>>>> Thanks, Roger >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>> >> From david.lloyd at redhat.com Tue Dec 8 12:51:27 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 8 Dec 2015 06:51:27 -0600 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666D0B3.7070905@oracle.com> References: <560D3F61.6040607@Oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.7070905@oracle.com> Message-ID: <5666D24F.9060601@redhat.com> Yeah I think that replacing finalize is a bad example. With Reference.reachabilityFence() around the corner, if you want finalize you can (and should, I guess) just use finalize. IMO Cleaners are better when you do not want the instance of an object to be accessible at all before you clean it - because it corresponds to mapped memory, a file descriptor, or some other native resource, usually, and any invocation at all after it is cleaned would result in Major Problems. In this case you would put the FD, memory address/size/etc. on the cleaner, so that the clean method can do the cleanup. Also, one hopes that each framework/library/application would only register one cleaner for its usages, rather than (say) one per class... On 12/08/2015 06:44 AM, David Holmes wrote: > But thinking more on this approach this is simply not scalable. A > Cleaner per cleanable-class could result in hundreds of threads being > active! > > And this certainly does not seem easier to use than finalization. > > What exactly are the advantages over finalization again? > > Thanks, > David > > On 8/12/2015 10:29 PM, David Holmes wrote: >> On 8/12/2015 10:25 PM, Peter Levart wrote: >>> >>> >>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>> Actually I'm having more doubts about this API. >>>> >>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>> library writer I would think I am now expected to register my >>>> instances with a Cleaner and provide a Runnable that does what >>>> finalize() would have done. But in that usage pattern the end user of >>>> my objects never has any access to my Cleanables so can never call >>>> clean() themselves - instead they should be calling the cleanup >>>> function directly, just as they would previously. So the whole "invoke >>>> at most once" for the clean() method seems somewhat unnecessary; and >>>> the way we should write the cleanup method and the Runnable need to be >>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>> handled in the library writers code not the Cleaner/Clenable >>>> implementation. >>>> >>>> David >>> >>> Hi David, (once again for the list) >> >> Thanks Peter! :) >> >>> I agree that an example would be most helpful. Here's how a normal >>> finalizable object is typically coded: >>> >>> public class FinalizeExample implements AutoCloseable { >>> >>> private boolean closed; >>> >>> @Override >>> public synchronized void close() { >>> if (!closed) { >>> closed = true; >>> // cleanup actions accessing state of FinalizeExample, >>> executed at most once >>> } >>> } >>> >>> @Override >>> protected void finalize() throws Throwable { >>> close(); >>> } >>> } >>> >>> >>> Re-factoring to use Cleaner is a process that extracts the state >>> representing native resource from the user-facing class into a private >>> nested static class and makes the user-facing object just a facade that >>> has access to the state object and is registered with a Cleaner. The >>> Cleaner.Cleanable instance is also made accessible from the user-facing >>> object, so it can provide the on-demand cleaning: >>> >>> public static class CleanerExample implements AutoCloseable { >>> >>> private static class State implements Runnable { >>> @Override >>> public void run() { >>> // cleanup actions accessing State, executed at most >>> once >>> } >>> } >>> >>> private static final Cleaner cleaner = Cleaner.create(); >>> >>> private final State state = new State(); >>> private final Cleaner.Cleanable cleanable = >>> cleaner.register(this, state); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> } >> >> Thanks for clarifying that - the process is really quite different >> compared to using the finalize() approach. This certainly needs to be >> included in the documentation as an example, and also used to guide the >> javadoc descriptions. >> >> Thanks again, >> David >> >>> >>> Regards, Peter >>> >>>> >>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>> Hi Roger, >>>>> >>>>> Sorry I had no choice but to look at this more closely ... and >>>>> apologies >>>>> as this is very late feedback ... I only looked at the API not the >>>>> details of the implementation. >>>>> >>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for the comments, >>>>>> >>>>>> Updated the javadoc and webrev with editorial changes. >>>>>> >>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>> >>>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>> part of >>>>> the core reference related functionality. Perhaps even state how they >>>>> are preferred to use of finalization? >>>>> >>>>> Cleaner.Cleanable: >>>>> >>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>> that the intent is that rather than register a "thunk" (lets call >>>>> it an >>>>> "action") that can be invoked directly by user-code, the user should >>>>> invoke the action via the call to clean(). In which case I think it >>>>> should be explained somewhat more clearly - see below. >>>>> >>>>> I would describe the Cleanable class as: >>>>> >>>>> Cleanable: Represents an object that has been registered for >>>>> cleanup by >>>>> a Cleaner. The object can be cleaned directly, by a call to >>>>> clean(), if >>>>> it is no longer to be used, else it will be cleaned automatically when >>>>> the object becomes phantom-reachable. >>>>> >>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>> action that was associated with it. If this Cleanable has already been >>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>> once >>>>> per registered Cleanable, regardless of the number of calls to >>>>> clean(). >>>>> >>>>> --- >>>>> >>>>> Looking at Cleaner .... >>>>> >>>>> >>>>> "Cleaner manages a set of object references and corresponding cleaning >>>>> functions" >>>>> >>>>> I would say "cleaning actions" rather than functions as they yield no >>>>> value. This change needs to be made throughout. >>>>> >>>>> "The most efficient use is to explicitly invoke the clean method when >>>>> the object is closed or no longer needed. The cleaning function is a >>>>> Runnable to be invoked at most once when the object is no longer >>>>> reachable unless it has already been explicitly cleaned." >>>>> >>>>> To me this doesn't quite capture the need to not use the Runnable >>>>> directly. I would rephrase: >>>>> >>>>> "In normal use a object should be cleaned up when no longer >>>>> required, by >>>>> invoking the clean() method of the associated Cleanable. This >>>>> guarantees >>>>> that the cleaning action will be performed at most once per object: >>>>> either explicitly, or automatically if it becomes >>>>> phantom-reachable. If >>>>> cleaned explicitly the object should not be used again. Note that the >>>>> cleaning action must not refer to the object ..." >>>>> >>>>> --- >>>>> >>>>> Question: what happens if an object is registered simultaneously with >>>>> multiple Cleaners? Do we need to warn the user against that? >>>>> >>>>> --- >>>>> >>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>> never processed, or even touched - right? So really the thread is >>>>> started to "invoke the cleanup actions for unreachable objects". >>>>> >>>>> create(): can also throw SecurityException if not allowed to >>>>> create/start threads. >>>>> >>>>> register(Object obj, Runnable thunk): thunk -> action >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> >>>>>> >>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>> >>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>> ThreadFactory could throw anything) . >>>>>> It does seem that new is fairly well understood but one can read of >>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>> the >>>>>> Thread.State of the new thread >>>>>> and since it allows various attributes of the thread to be modified >>>>>> after the constructor. >>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>> started, >>>>>> why not. >>>>>> It seemed useful to reinforce the salient points. >>>>>>> >>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>> The thread construction is done in doPriv so it should not throw. >>>>>> Did I miss some edge case? >>>>>>> >>>>>>> Also this: >>>>>>> >>>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>>> thread factory} >>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>> an appropriate >>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>> loader}, >>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>> 132 * permissions, etc. >>>>>>> >>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>> can >>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>> Thread >>>>>>> that is suitable for performing the cleaning work". Though even that >>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>> needed >>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>> but I >>>>>>> don't think name or priority need to be discussed. >>>>>> It was intended to prod the client to be deliberate about the >>>>>> threadFactory. >>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>> functions >>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>> client to >>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>> I agree that the phrase 'suitable for performing the cleaning >>>>>> work' is >>>>>> the operative one. >>>>>> >>>>>> Thanks, Roger >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>> >>> -- - DML From Alan.Bateman at oracle.com Tue Dec 8 13:22:40 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 Dec 2015 13:22:40 +0000 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56617A37.3070408@oracle.com> Message-ID: <5666D9A0.5040705@oracle.com> On 08/12/2015 00:11, Brian Burkhalter wrote: > > : > > http://cr.openjdk.java.net/~bpb/8143394/webrev.01/ > > > wherein the sentence "This method will block if there is another > thread blocking on the reader.? is added to the specification of > close() in each of the affected classes. Not sure whether this change > requires CCC approval. > One suggestion is to use "while" rather than "if", otherwise looks okay I think. -Alan. From peter.levart at gmail.com Tue Dec 8 13:41:16 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Dec 2015 14:41:16 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666D24F.9060601@redhat.com> References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.7070905@oracle.com> <5666D24F.9060601@redhat.com> Message-ID: <5666DDFC.3070003@gmail.com> (once again, for the list - I can't seem to hit the right button :-) On 12/08/2015 01:51 PM, David M. Lloyd wrote: > Yeah I think that replacing finalize is a bad example. With > Reference.reachabilityFence() around the corner, if you want finalize > you can (and should, I guess) just use finalize. > > IMO Cleaners are better when you do not want the instance of an object > to be accessible at all before you clean it - because it corresponds > to mapped memory, a file descriptor, or some other native resource, > usually, and any invocation at all after it is cleaned would result in > Major Problems. In this case you would put the FD, memory > address/size/etc. on the cleaner, so that the clean method can do the > cleanup. Cleaners are also more efficient in that: - they register cleanup actions manually from java code after the referent is constructed. finalize() uses a call-back from VM into Java to register a Finalizer on finalizable referent construction. - they can invoke and de-register cleanup actions prematurely by user explicitly invoking Cleanable.clean() and therefore avoid being processed by reference processing machinery (in the VM and in Java). For example, FileInputStream, using this API instead of finalize(), would in majority of cases invoke and de-register the cleanup prematurely as most code makes sure it closes the file after use. finalize() OTOH has no premature de-registration feature. - with a fix for "8071507: (ref) Clear phantom reference as soft and weak references do", the opportunity for GC to collect the referent in the same phase as discovering it phantom-reachable opens up. Finalizer OTOH keeps the referent reachable in order to invoke finalize() on it and then clear()s the reference, delaying the collection of referent to the next GC round. > > Also, one hopes that each framework/library/application would only > register one cleaner for its usages, rather than (say) one per class... There was a debate about whether to provide a common cleaner instance: Cleaner.commonCleaner() (like ForkJoinPool.commonPool()). It could be created lazily, but then it would run forever... Regards, Peter > > On 12/08/2015 06:44 AM, David Holmes wrote: >> But thinking more on this approach this is simply not scalable. A >> Cleaner per cleanable-class could result in hundreds of threads being >> active! >> >> And this certainly does not seem easier to use than finalization. >> >> What exactly are the advantages over finalization again? >> >> Thanks, >> David >> >> On 8/12/2015 10:29 PM, David Holmes wrote: >>> On 8/12/2015 10:25 PM, Peter Levart wrote: >>>> >>>> >>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>> Actually I'm having more doubts about this API. >>>>> >>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>> library writer I would think I am now expected to register my >>>>> instances with a Cleaner and provide a Runnable that does what >>>>> finalize() would have done. But in that usage pattern the end user of >>>>> my objects never has any access to my Cleanables so can never call >>>>> clean() themselves - instead they should be calling the cleanup >>>>> function directly, just as they would previously. So the whole >>>>> "invoke >>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>> the way we should write the cleanup method and the Runnable need >>>>> to be >>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>> handled in the library writers code not the Cleaner/Clenable >>>>> implementation. >>>>> >>>>> David >>>> >>>> Hi David, (once again for the list) >>> >>> Thanks Peter! :) >>> >>>> I agree that an example would be most helpful. Here's how a normal >>>> finalizable object is typically coded: >>>> >>>> public class FinalizeExample implements AutoCloseable { >>>> >>>> private boolean closed; >>>> >>>> @Override >>>> public synchronized void close() { >>>> if (!closed) { >>>> closed = true; >>>> // cleanup actions accessing state of >>>> FinalizeExample, >>>> executed at most once >>>> } >>>> } >>>> >>>> @Override >>>> protected void finalize() throws Throwable { >>>> close(); >>>> } >>>> } >>>> >>>> >>>> Re-factoring to use Cleaner is a process that extracts the state >>>> representing native resource from the user-facing class into a private >>>> nested static class and makes the user-facing object just a facade >>>> that >>>> has access to the state object and is registered with a Cleaner. The >>>> Cleaner.Cleanable instance is also made accessible from the >>>> user-facing >>>> object, so it can provide the on-demand cleaning: >>>> >>>> public static class CleanerExample implements AutoCloseable { >>>> >>>> private static class State implements Runnable { >>>> @Override >>>> public void run() { >>>> // cleanup actions accessing State, executed at most >>>> once >>>> } >>>> } >>>> >>>> private static final Cleaner cleaner = Cleaner.create(); >>>> >>>> private final State state = new State(); >>>> private final Cleaner.Cleanable cleanable = >>>> cleaner.register(this, state); >>>> >>>> @Override >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> } >>> >>> Thanks for clarifying that - the process is really quite different >>> compared to using the finalize() approach. This certainly needs to be >>> included in the documentation as an example, and also used to guide the >>> javadoc descriptions. >>> >>> Thanks again, >>> David >>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>> apologies >>>>>> as this is very late feedback ... I only looked at the API not the >>>>>> details of the implementation. >>>>>> >>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for the comments, >>>>>>> >>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>> >>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>> >>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>> package-doc >>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>> part of >>>>>> the core reference related functionality. Perhaps even state how >>>>>> they >>>>>> are preferred to use of finalization? >>>>>> >>>>>> Cleaner.Cleanable: >>>>>> >>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>> that the intent is that rather than register a "thunk" (lets call >>>>>> it an >>>>>> "action") that can be invoked directly by user-code, the user should >>>>>> invoke the action via the call to clean(). In which case I think it >>>>>> should be explained somewhat more clearly - see below. >>>>>> >>>>>> I would describe the Cleanable class as: >>>>>> >>>>>> Cleanable: Represents an object that has been registered for >>>>>> cleanup by >>>>>> a Cleaner. The object can be cleaned directly, by a call to >>>>>> clean(), if >>>>>> it is no longer to be used, else it will be cleaned automatically >>>>>> when >>>>>> the object becomes phantom-reachable. >>>>>> >>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>> action that was associated with it. If this Cleanable has already >>>>>> been >>>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>>> once >>>>>> per registered Cleanable, regardless of the number of calls to >>>>>> clean(). >>>>>> >>>>>> --- >>>>>> >>>>>> Looking at Cleaner .... >>>>>> >>>>>> >>>>>> "Cleaner manages a set of object references and corresponding >>>>>> cleaning >>>>>> functions" >>>>>> >>>>>> I would say "cleaning actions" rather than functions as they >>>>>> yield no >>>>>> value. This change needs to be made throughout. >>>>>> >>>>>> "The most efficient use is to explicitly invoke the clean method >>>>>> when >>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>> Runnable to be invoked at most once when the object is no longer >>>>>> reachable unless it has already been explicitly cleaned." >>>>>> >>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>> directly. I would rephrase: >>>>>> >>>>>> "In normal use a object should be cleaned up when no longer >>>>>> required, by >>>>>> invoking the clean() method of the associated Cleanable. This >>>>>> guarantees >>>>>> that the cleaning action will be performed at most once per object: >>>>>> either explicitly, or automatically if it becomes >>>>>> phantom-reachable. If >>>>>> cleaned explicitly the object should not be used again. Note that >>>>>> the >>>>>> cleaning action must not refer to the object ..." >>>>>> >>>>>> --- >>>>>> >>>>>> Question: what happens if an object is registered simultaneously >>>>>> with >>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>> >>>>>> --- >>>>>> >>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>> functions" doesn't quite seem right to me. The objects themselves >>>>>> are >>>>>> never processed, or even touched - right? So really the thread is >>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>> >>>>>> create(): can also throw SecurityException if not allowed to >>>>>> create/start threads. >>>>>> >>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>> >>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>> unstarted threads - that is what a new Thread is - so I don't >>>>>>>> think >>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>> ThreadFactory could throw anything) . >>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>>> the >>>>>>> Thread.State of the new thread >>>>>>> and since it allows various attributes of the thread to be modified >>>>>>> after the constructor. >>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>> started, >>>>>>> why not. >>>>>>> It seemed useful to reinforce the salient points. >>>>>>>> >>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>> Did I miss some edge case? >>>>>>>> >>>>>>>> Also this: >>>>>>>> >>>>>>>> 127 * On each call the {@link >>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>> thread factory} >>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} >>>>>>>> with >>>>>>>> an appropriate >>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>> loader}, >>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>> 132 * permissions, etc. >>>>>>>> >>>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>>> can >>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>> Thread >>>>>>>> that is suitable for performing the cleaning work". Though even >>>>>>>> that >>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>> needed >>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>> but I >>>>>>>> don't think name or priority need to be discussed. >>>>>>> It was intended to prod the client to be deliberate about the >>>>>>> threadFactory. >>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>> functions >>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>> client to >>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>> I agree that the phrase 'suitable for performing the cleaning >>>>>>> work' is >>>>>>> the operative one. >>>>>>> >>>>>>> Thanks, Roger >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>> >>>> > From rob.mckenna at oracle.com Tue Dec 8 14:00:31 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 Dec 2015 14:00:31 +0000 Subject: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently Message-ID: <5666E27F.1080100@oracle.com> Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the failing subtest out into its own file and excluded it on the (intermittently) failing platforms. http://cr.openjdk.java.net/~robm/8141370/webrev.01/ -Rob From chris.hegarty at oracle.com Tue Dec 8 14:15:47 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Dec 2015 14:15:47 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals Message-ID: Many threads created by the platform are short lived and perform some simple async operation on behalf of the platform. These threads typically use/extend sun.misc.ManagedLocalsThread. This is a convenient internal API that can be used to create threads that do not wish to inherit initial values from inheritable thread-local variables. I'd like to propose an additional java.lang.Thread constructor that exposes the ability to explicitly "opt out" of inheriting these initial values ( from inheritable thread-local variables ). This seems like useful general functionality, given the amount of usage in the JDK of the internal API. This new public API can then be used to replace usages of the internal sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted the usage in the sources of the base module. Other modules can be done as a follow up. Webrev: http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8056152 From Roger.Riggs at oracle.com Tue Dec 8 14:33:08 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 09:33:08 -0500 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: Message-ID: <5666EA24.9040108@oracle.com> Hi Chris, Supporting the use case in Thread is a good addition. Adding an argument to the most flexible constructor of Thread bulks up an already heavy weight constructor. Look at the cases being replaced, none of them use all of the arguments. The stackSize, for example, is rarely used and is nearly useless due to its implementation dependencies. Would you consider using a static Factory method (aptly named) instead of a constructor? Roger On 12/08/2015 09:15 AM, Chris Hegarty wrote: > Many threads created by the platform are short lived and perform some > simple async operation on behalf of the platform. These threads typically > use/extend sun.misc.ManagedLocalsThread. This is a convenient internal > API that can be used to create threads that do not wish to inherit initial > values from inheritable thread-local variables. > > I'd like to propose an additional java.lang.Thread constructor that exposes > the ability to explicitly "opt out" of inheriting these initial values ( from > inheritable thread-local variables ). This seems like useful general > functionality, given the amount of usage in the JDK of the internal API. > > This new public API can then be used to replace usages of the internal > sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted > the usage in the sources of the base module. Other modules can be done > as a follow up. > > Webrev: > http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8056152 From david.lloyd at redhat.com Tue Dec 8 14:49:47 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 8 Dec 2015 08:49:47 -0600 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: Message-ID: <5666EE0B.7040703@redhat.com> Great! Now all we need is a way to tell threads to remove all thread locals on exit, and the scourge of ITL might be somewhat mitigated. :-) On 12/08/2015 08:15 AM, Chris Hegarty wrote: > Many threads created by the platform are short lived and perform some > simple async operation on behalf of the platform. These threads typically > use/extend sun.misc.ManagedLocalsThread. This is a convenient internal > API that can be used to create threads that do not wish to inherit initial > values from inheritable thread-local variables. > > I'd like to propose an additional java.lang.Thread constructor that exposes > the ability to explicitly "opt out" of inheriting these initial values ( from > inheritable thread-local variables ). This seems like useful general > functionality, given the amount of usage in the JDK of the internal API. > > This new public API can then be used to replace usages of the internal > sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted > the usage in the sources of the base module. Other modules can be done > as a follow up. > > Webrev: > http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8056152 > -- - DML From david.lloyd at redhat.com Tue Dec 8 14:50:15 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 8 Dec 2015 08:50:15 -0600 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <5666EA24.9040108@oracle.com> References: <5666EA24.9040108@oracle.com> Message-ID: <5666EE27.80900@redhat.com> Or perhaps a builder... On 12/08/2015 08:33 AM, Roger Riggs wrote: > Hi Chris, > > Supporting the use case in Thread is a good addition. > > Adding an argument to the most flexible constructor of Thread bulks up > an already heavy weight constructor. Look at the cases being replaced, > none of them use all of the arguments. The stackSize, for example, is > rarely > used and is nearly useless due to its implementation dependencies. > > Would you consider using a static Factory method (aptly named) instead > of a constructor? > > Roger > > > On 12/08/2015 09:15 AM, Chris Hegarty wrote: >> Many threads created by the platform are short lived and perform some >> simple async operation on behalf of the platform. These threads typically >> use/extend sun.misc.ManagedLocalsThread. This is a convenient internal >> API that can be used to create threads that do not wish to inherit >> initial >> values from inheritable thread-local variables. >> >> I'd like to propose an additional java.lang.Thread constructor that >> exposes >> the ability to explicitly "opt out" of inheriting these initial values >> ( from >> inheritable thread-local variables ). This seems like useful general >> functionality, given the amount of usage in the JDK of the internal API. >> >> This new public API can then be used to replace usages of the internal >> sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted >> the usage in the sources of the base module. Other modules can be done >> as a follow up. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8056152 > -- - DML From chris.hegarty at oracle.com Tue Dec 8 14:50:55 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Dec 2015 14:50:55 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <5666EA24.9040108@oracle.com> References: <5666EA24.9040108@oracle.com> Message-ID: <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> On 8 Dec 2015, at 14:33, Roger Riggs wrote: > Hi Chris, > > Supporting the use case in Thread is a good addition. Thanks. > Adding an argument to the most flexible constructor of Thread bulks up > an already heavy weight constructor. Look at the cases being replaced, > none of them use all of the arguments. The stackSize, for example, is rarely > used and is nearly useless due to its implementation dependencies. Right. The motivation for adding an additional constructor that accepts a superset of arguments is for maximum flexibility. Since this is targeted at the advanced user, then it should be ok, but I agree it looks a little unwieldy. > Would you consider using a static Factory method (aptly named) instead > of a constructor? Possibly, I went down the constructor route for consistency with what is already there. The usage pattern of extending Thread is also very common. -Chris. > Roger > > > On 12/08/2015 09:15 AM, Chris Hegarty wrote: >> Many threads created by the platform are short lived and perform some >> simple async operation on behalf of the platform. These threads typically >> use/extend sun.misc.ManagedLocalsThread. This is a convenient internal >> API that can be used to create threads that do not wish to inherit initial >> values from inheritable thread-local variables. >> >> I'd like to propose an additional java.lang.Thread constructor that exposes >> the ability to explicitly "opt out" of inheriting these initial values ( from >> inheritable thread-local variables ). This seems like useful general >> functionality, given the amount of usage in the JDK of the internal API. >> >> This new public API can then be used to replace usages of the internal >> sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted >> the usage in the sources of the base module. Other modules can be done >> as a follow up. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8056152 > From maurizio.cimadamore at oracle.com Tue Dec 8 14:58:27 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 8 Dec 2015 14:58:27 +0000 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5666222A.5070204@oracle.com> References: <565E590D.3090007@oracle.com> <5662122A.7020303@oracle.com> <5666222A.5070204@oracle.com> Message-ID: <5666F013.7090105@oracle.com> On 08/12/15 00:19, Stuart Marks wrote: > Hi Maurizio, > > Well, maybe we should add five more overloads to EnumSet.of()? (Only > slightly joking here.) > > Setting aside the number of overloads, it would add N more overloads > to Set.of(). I guess the erasure of > would be Enum, > so there wouldn't be any overload ambiguity.... right - no ambiguity > > To me the question here is whether this adds sufficient value. The > advantage is that one could write > > Set.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) > > instead of > > EnumSet.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE) > > and get an optimized EnumSet instead of a Set that contains object > references. Is it worth it? I'm not too worried about the fact that typing 'EnumSet' is more verbose than just 'Set', obviously; but it would seem reasonable to try (within reasonable bounds) to provide uniform way to create collections and a smooth user experience. I think with the current status quo, we have that: Set.of(A, B, C) != EnumSet.of(A, B, C) and that's surprising, IMHO. At the same time I notice that, even with the overload I suggest, they would still be different beasts, as one would be mutable, while the other would not. That said, I think we should aim for an API where such bad surprises are avoided (why is my enumset so slow? Ah - it's not an enumset because I used the wrong XYZ.of method); unfortunately I don't have a good suggestion on how to get there :-( (which might mean that what you did is correct :-) ) Maurizio > > Presumably this would result in an instance of an immutable EnumSet. > Does this case come up that often? > > s'marks > > > On 12/4/15 2:22 PM, Maurizio Cimadamore wrote: >> Hi Stuart >> small question: I find it a bit odd that EnumSet has max 5 >> parameters, while Set >> has more than that. >> >> Also, would it be possible, maybe to add overloads to Set that >> specifically >> works on Enum constants? >> >> > of(Z z1, Z z2) { ... } >> >> This would give you a way to call Set.of and get different answers >> based on the >> static type of the arguments passed in - and we could deprecate the >> of method in >> EnumSet? >> >> Too subtle/magic? >> >> Maurizio >> >> On 02/12/15 02:35, Stuart Marks wrote: >>> Hi all, >>> >>> Thanks for the previous round of review comments. Here's an updated >>> API and >>> implementation for review. >>> >>> I've run specdiff with the --hu ("hide unchanged") option, so only >>> the bits of >>> the specification that have changed are shown. As before, though, >>> please >>> ignore the spurious change to EnumSet caused by a javadoc bug. >>> >>> API changes: >>> - add clarifying notes on immutability >>> - remove wording that implied creation of new objects >>> - add "value-based" disclaimers >>> - add ordering specification for List and non-ordering disclaimers >>> for Set and Map >>> - clarify that Map.ofEntries() doesn't store the Map.Entry objects, >>> instead >>> it extracts keys and values >>> - Map.Entry instances returned from Map.entry() are *not* serializable >>> >>> Other: >>> - markup cleanups >>> - small implementation cleanups >>> >>> JEP: >>> >>> http://openjdk.java.net/jeps/269 >>> >>> API spec (basically List, Map, and Set): >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ >>> >>> Specdiff: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html >>> >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ >>> >>> Thanks, >>> >>> s'marks >> From Roger.Riggs at oracle.com Tue Dec 8 15:34:51 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 10:34:51 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666CC4B.9020303@gmail.com> References: <560D3F61.6040607@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> Message-ID: <5666F89B.7050001@oracle.com> Hi Peter, Thanks for the example and explanations. For simple cleanup of specific state values, I probably would have used lambda instead of an explicit inner class but both styles use the same mechanism. The point about using a shared cleaner can be reinforced in the example too. public static class CleanerExample implements AutoCloseable { FileDescriptor fd = ...; private static final Cleaner cleaner = Cleaner.create(); private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); @Override public void close() { cleanable.clean(); } } I'll work the example into the javadoc. Roger On 12/08/2015 07:25 AM, Peter Levart wrote: > > > On 12/08/2015 09:22 AM, David Holmes wrote: >> Actually I'm having more doubts about this API. >> >> Library writers use finalize() as a last ditch cleanup mechanism in >> case the user doesn't explicitly call any "cleanup" method. So as a >> library writer I would think I am now expected to register my >> instances with a Cleaner and provide a Runnable that does what >> finalize() would have done. But in that usage pattern the end user of >> my objects never has any access to my Cleanables so can never call >> clean() themselves - instead they should be calling the cleanup >> function directly, just as they would previously. So the whole "invoke >> at most once" for the clean() method seems somewhat unnecessary; and >> the way we should write the cleanup method and the Runnable need to be >> more cleary explained as the idempotentcy of the cleanup needs to be >> handled in the library writers code not the Cleaner/Clenable >> implementation. >> >> David > > Hi David, (once again for the list) > > I agree that an example would be most helpful. Here's how a normal > finalizable object is typically coded: > > public class FinalizeExample implements AutoCloseable { > > private boolean closed; > > @Override > public synchronized void close() { > if (!closed) { > closed = true; > // cleanup actions accessing state of FinalizeExample, > executed at most once > } > } > > @Override > protected void finalize() throws Throwable { > close(); > } > } > > > Re-factoring to use Cleaner is a process that extracts the state > representing native resource from the user-facing class into a private > nested static class and makes the user-facing object just a facade > that has access to the state object and is registered with a Cleaner. > The Cleaner.Cleanable instance is also made accessible from the > user-facing object, so it can provide the on-demand cleaning: > > public static class CleanerExample implements AutoCloseable { > > private static class State implements Runnable { > @Override > public void run() { > // cleanup actions accessing State, executed at most once > } > } > > private static final Cleaner cleaner = Cleaner.create(); > > private final State state = new State(); > private final Cleaner.Cleanable cleanable = > cleaner.register(this, state); > > @Override > public void close() { > cleanable.clean(); > } > } > > > Regards, Peter > >> >> On 8/12/2015 6:09 PM, David Holmes wrote: >>> Hi Roger, >>> >>> Sorry I had no choice but to look at this more closely ... and >>> apologies >>> as this is very late feedback ... I only looked at the API not the >>> details of the implementation. >>> >>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>> Hi David, >>>> >>>> Thanks for the comments, >>>> >>>> Updated the javadoc and webrev with editorial changes. >>>> >>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> Should cleaning and cleanables be mentioned as part of the package-doc >>> for java.lang.ref? Else they seem to be an overlooked add-on not >>> part of >>> the core reference related functionality. Perhaps even state how they >>> are preferred to use of finalization? >>> >>> Cleaner.Cleanable: >>> >>> It was unclear to me what the usage model was for this. I'm assuming >>> that the intent is that rather than register a "thunk" (lets call it an >>> "action") that can be invoked directly by user-code, the user should >>> invoke the action via the call to clean(). In which case I think it >>> should be explained somewhat more clearly - see below. >>> >>> I would describe the Cleanable class as: >>> >>> Cleanable: Represents an object that has been registered for cleanup by >>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>> it is no longer to be used, else it will be cleaned automatically when >>> the object becomes phantom-reachable. >>> >>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>> action that was associated with it. If this Cleanable has already been >>> unregistered nothing happens. The cleanup action is invoked at most >>> once >>> per registered Cleanable, regardless of the number of calls to clean(). >>> >>> --- >>> >>> Looking at Cleaner .... >>> >>> >>> "Cleaner manages a set of object references and corresponding cleaning >>> functions" >>> >>> I would say "cleaning actions" rather than functions as they yield no >>> value. This change needs to be made throughout. >>> >>> "The most efficient use is to explicitly invoke the clean method when >>> the object is closed or no longer needed. The cleaning function is a >>> Runnable to be invoked at most once when the object is no longer >>> reachable unless it has already been explicitly cleaned." >>> >>> To me this doesn't quite capture the need to not use the Runnable >>> directly. I would rephrase: >>> >>> "In normal use a object should be cleaned up when no longer >>> required, by >>> invoking the clean() method of the associated Cleanable. This >>> guarantees >>> that the cleaning action will be performed at most once per object: >>> either explicitly, or automatically if it becomes phantom-reachable. If >>> cleaned explicitly the object should not be used again. Note that the >>> cleaning action must not refer to the object ..." >>> >>> --- >>> >>> Question: what happens if an object is registered simultaneously with >>> multiple Cleaners? Do we need to warn the user against that? >>> >>> --- >>> >>> The phrase "process the unreachable objects and to invoke cleaning >>> functions" doesn't quite seem right to me. The objects themselves are >>> never processed, or even touched - right? So really the thread is >>> started to "invoke the cleanup actions for unreachable objects". >>> >>> create(): can also throw SecurityException if not allowed to >>> create/start threads. >>> >>> register(Object obj, Runnable thunk): thunk -> action >>> >>> Thanks, >>> David >>> >>> >>>> >>>> >>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>> Hi Roger, >>>>> >>>>> Sorry to be late here but was trying not to get involved :) >>>>> >>>>> It is already implicit that ThreadFactory.newThread should return >>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>> IllegalThreadStateException needs to be documented here as it is >>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>> ThreadFactory could throw anything) . >>>> It does seem that new is fairly well understood but one can read of >>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>> Thread.State of the new thread >>>> and since it allows various attributes of the thread to be modified >>>> after the constructor. >>>> Since the runnable is supplied as an argument it is ready to be >>>> started, >>>> why not. >>>> It seemed useful to reinforce the salient points. >>>>> >>>>> Also the no-arg cleaner() can also throw SecurityException. >>>> The thread construction is done in doPriv so it should not throw. >>>> Did I miss some edge case? >>>>> >>>>> Also this: >>>>> >>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>> thread factory} >>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>> an appropriate >>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>> loader}, >>>>> 130 * {@linkplain Thread#getName() name}, >>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>> 132 * permissions, etc. >>>>> >>>>> then begs the questions as to what is "appropriate". I think this can >>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>> that is suitable for performing the cleaning work". Though even that >>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>> here ?? Special security context? If so that could be mentioned, >>>>> but I >>>>> don't think name or priority need to be discussed. >>>> It was intended to prod the client to be deliberate about the >>>> threadFactory. >>>> Since the client is integrating the Cleaner and respective cleaning >>>> functions >>>> with the client code, the ThreadFactory makes it possible for the >>>> client to >>>> initialize a suitable thread and the comments serve as a reminder. >>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>> the operative one. >>>> >>>> Thanks, Roger >>>>> >>>>> Thanks, >>>>> David >>>>> >>>> > From daniel.fuchs at oracle.com Tue Dec 8 15:45:50 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 8 Dec 2015 16:45:50 +0100 Subject: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently In-Reply-To: <5666E27F.1080100@oracle.com> References: <5666E27F.1080100@oracle.com> Message-ID: <5666FB2E.7010304@oracle.com> Hey Rob, The @run line seems to be wrong in the new test file: 26 * @run main/othervm LdapTimeoutTest cheers, -- daniel On 08/12/15 15:00, Rob McKenna wrote: > Hi folks, > > Hopefully this fix puts this tests' failures to bed. (mind you I've > thought that before) > > Basically I've separated the failing subtest out into its own file and > excluded it on the (intermittently) failing platforms. > > http://cr.openjdk.java.net/~robm/8141370/webrev.01/ > > -Rob From Roger.Riggs at oracle.com Tue Dec 8 15:47:29 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 10:47:29 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666DDFC.3070003@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.7070905@oracle.com> <5666D24F.9060601@redhat.com> <5666DDFC.3070003@gmail.com> Message-ID: <5666FB91.3080702@oracle.com> Hi, On 12/08/2015 08:41 AM, Peter Levart wrote: > (once again, for the list - I can't seem to hit the right button :-) > > On 12/08/2015 01:51 PM, David M. Lloyd wrote: >> Yeah I think that replacing finalize is a bad example. With >> Reference.reachabilityFence() around the corner, if you want finalize >> you can (and should, I guess) just use finalize. >> >> IMO Cleaners are better when you do not want the instance of an >> object to be accessible at all before you clean it - because it >> corresponds to mapped memory, a file descriptor, or some other native >> resource, usually, and any invocation at all after it is cleaned >> would result in Major Problems. In this case you would put the FD, >> memory address/size/etc. on the cleaner, so that the clean method can >> do the cleanup. > > Cleaners are also more efficient in that: > > - they register cleanup actions manually from java code after the > referent is constructed. finalize() uses a call-back from VM into Java > to register a Finalizer on finalizable referent construction. > - they can invoke and de-register cleanup actions prematurely by user > explicitly invoking Cleanable.clean() and therefore avoid being > processed by reference processing machinery (in the VM and in Java). > For example, FileInputStream, using this API instead of finalize(), > would in majority of cases invoke and de-register the cleanup > prematurely as most code makes sure it closes the file after use. > finalize() OTOH has no premature de-registration feature. > - with a fix for "8071507: (ref) Clear phantom reference as soft and > weak references do", the opportunity for GC to collect the referent in > the same phase as discovering it phantom-reachable opens up. Finalizer > OTOH keeps the referent reachable in order to invoke finalize() on it > and then clear()s the reference, delaying the collection of referent > to the next GC round. +3 Removing the reliance on finalizers reduces the overhead the VM incurs to maintain and process finalized objects. It removes the possibility of resurrecting references to objects that have been finalized, most likely in an unusable state, etc. Cleaners are not the best tool for every cleanup, but are preferable in most cases. >> >> Also, one hopes that each framework/library/application would only >> register one cleaner for its usages, rather than (say) one per class... > > There was a debate about whether to provide a common cleaner instance: > Cleaner.commonCleaner() (like ForkJoinPool.commonPool()). It could be > created lazily, but then it would run forever... I'll file a separate issue for a common cleaner. If the common cleaner reference were kept has a weak reference then it would stay alive only as long as any client package/class had a strong reference/use for it, so not necessarily forever. Roger > > Regards, Peter > >> >> On 12/08/2015 06:44 AM, David Holmes wrote: >>> But thinking more on this approach this is simply not scalable. A >>> Cleaner per cleanable-class could result in hundreds of threads being >>> active! >>> >>> And this certainly does not seem easier to use than finalization. >>> >>> What exactly are the advantages over finalization again? >>> >>> Thanks, >>> David >>> >>> On 8/12/2015 10:29 PM, David Holmes wrote: >>>> On 8/12/2015 10:25 PM, Peter Levart wrote: >>>>> >>>>> >>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>>> Actually I'm having more doubts about this API. >>>>>> >>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>> library writer I would think I am now expected to register my >>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>> finalize() would have done. But in that usage pattern the end >>>>>> user of >>>>>> my objects never has any access to my Cleanables so can never call >>>>>> clean() themselves - instead they should be calling the cleanup >>>>>> function directly, just as they would previously. So the whole >>>>>> "invoke >>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>> the way we should write the cleanup method and the Runnable need >>>>>> to be >>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>> implementation. >>>>>> >>>>>> David >>>>> >>>>> Hi David, (once again for the list) >>>> >>>> Thanks Peter! :) >>>> >>>>> I agree that an example would be most helpful. Here's how a normal >>>>> finalizable object is typically coded: >>>>> >>>>> public class FinalizeExample implements AutoCloseable { >>>>> >>>>> private boolean closed; >>>>> >>>>> @Override >>>>> public synchronized void close() { >>>>> if (!closed) { >>>>> closed = true; >>>>> // cleanup actions accessing state of >>>>> FinalizeExample, >>>>> executed at most once >>>>> } >>>>> } >>>>> >>>>> @Override >>>>> protected void finalize() throws Throwable { >>>>> close(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Re-factoring to use Cleaner is a process that extracts the state >>>>> representing native resource from the user-facing class into a >>>>> private >>>>> nested static class and makes the user-facing object just a facade >>>>> that >>>>> has access to the state object and is registered with a Cleaner. The >>>>> Cleaner.Cleanable instance is also made accessible from the >>>>> user-facing >>>>> object, so it can provide the on-demand cleaning: >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static class State implements Runnable { >>>>> @Override >>>>> public void run() { >>>>> // cleanup actions accessing State, executed at most >>>>> once >>>>> } >>>>> } >>>>> >>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>> >>>>> private final State state = new State(); >>>>> private final Cleaner.Cleanable cleanable = >>>>> cleaner.register(this, state); >>>>> >>>>> @Override >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> } >>>> >>>> Thanks for clarifying that - the process is really quite different >>>> compared to using the finalize() approach. This certainly needs to be >>>> included in the documentation as an example, and also used to guide >>>> the >>>> javadoc descriptions. >>>> >>>> Thanks again, >>>> David >>>> >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>>> apologies >>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>> details of the implementation. >>>>>>> >>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for the comments, >>>>>>>> >>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>> >>>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>>> package-doc >>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>>> part of >>>>>>> the core reference related functionality. Perhaps even state how >>>>>>> they >>>>>>> are preferred to use of finalization? >>>>>>> >>>>>>> Cleaner.Cleanable: >>>>>>> >>>>>>> It was unclear to me what the usage model was for this. I'm >>>>>>> assuming >>>>>>> that the intent is that rather than register a "thunk" (lets call >>>>>>> it an >>>>>>> "action") that can be invoked directly by user-code, the user >>>>>>> should >>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>> should be explained somewhat more clearly - see below. >>>>>>> >>>>>>> I would describe the Cleanable class as: >>>>>>> >>>>>>> Cleanable: Represents an object that has been registered for >>>>>>> cleanup by >>>>>>> a Cleaner. The object can be cleaned directly, by a call to >>>>>>> clean(), if >>>>>>> it is no longer to be used, else it will be cleaned >>>>>>> automatically when >>>>>>> the object becomes phantom-reachable. >>>>>>> >>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the >>>>>>> cleanup >>>>>>> action that was associated with it. If this Cleanable has >>>>>>> already been >>>>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>>>> once >>>>>>> per registered Cleanable, regardless of the number of calls to >>>>>>> clean(). >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Looking at Cleaner .... >>>>>>> >>>>>>> >>>>>>> "Cleaner manages a set of object references and corresponding >>>>>>> cleaning >>>>>>> functions" >>>>>>> >>>>>>> I would say "cleaning actions" rather than functions as they >>>>>>> yield no >>>>>>> value. This change needs to be made throughout. >>>>>>> >>>>>>> "The most efficient use is to explicitly invoke the clean method >>>>>>> when >>>>>>> the object is closed or no longer needed. The cleaning function >>>>>>> is a >>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>> >>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>> directly. I would rephrase: >>>>>>> >>>>>>> "In normal use a object should be cleaned up when no longer >>>>>>> required, by >>>>>>> invoking the clean() method of the associated Cleanable. This >>>>>>> guarantees >>>>>>> that the cleaning action will be performed at most once per object: >>>>>>> either explicitly, or automatically if it becomes >>>>>>> phantom-reachable. If >>>>>>> cleaned explicitly the object should not be used again. Note >>>>>>> that the >>>>>>> cleaning action must not refer to the object ..." >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Question: what happens if an object is registered simultaneously >>>>>>> with >>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>> functions" doesn't quite seem right to me. The objects >>>>>>> themselves are >>>>>>> never processed, or even touched - right? So really the thread is >>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>> >>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>> create/start threads. >>>>>>> >>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>> >>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>> unstarted threads - that is what a new Thread is - so I don't >>>>>>>>> think >>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>> ThreadFactory could throw anything) . >>>>>>>> It does seem that new is fairly well understood but one can >>>>>>>> read of >>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>>>> the >>>>>>>> Thread.State of the new thread >>>>>>>> and since it allows various attributes of the thread to be >>>>>>>> modified >>>>>>>> after the constructor. >>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>> started, >>>>>>>> why not. >>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>>> >>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>> Did I miss some edge case? >>>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> 127 * On each call the {@link >>>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>>> thread factory} >>>>>>>>> 128 * should return a {@link Thread.State#NEW new >>>>>>>>> thread} with >>>>>>>>> an appropriate >>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context >>>>>>>>> class >>>>>>>>> loader}, >>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>> 132 * permissions, etc. >>>>>>>>> >>>>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>>>> can >>>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>>> Thread >>>>>>>>> that is suitable for performing the cleaning work". Though >>>>>>>>> even that >>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>>> needed >>>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>>> but I >>>>>>>>> don't think name or priority need to be discussed. >>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>> threadFactory. >>>>>>>> Since the client is integrating the Cleaner and respective >>>>>>>> cleaning >>>>>>>> functions >>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>> client to >>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>> I agree that the phrase 'suitable for performing the cleaning >>>>>>>> work' is >>>>>>>> the operative one. >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>> >>>>> >> > From david.lloyd at redhat.com Tue Dec 8 15:50:16 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 8 Dec 2015 09:50:16 -0600 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666DDFC.3070003@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.7070905@oracle.com> <5666D24F.9060601@redhat.com> <5666DDFC.3070003@gmail.com> Message-ID: <5666FC38.5020200@redhat.com> On 12/08/2015 07:41 AM, Peter Levart wrote: > (once again, for the list - I can't seem to hit the right button :-) > > On 12/08/2015 01:51 PM, David M. Lloyd wrote: >> Yeah I think that replacing finalize is a bad example. With >> Reference.reachabilityFence() around the corner, if you want finalize >> you can (and should, I guess) just use finalize. >> >> IMO Cleaners are better when you do not want the instance of an object >> to be accessible at all before you clean it - because it corresponds >> to mapped memory, a file descriptor, or some other native resource, >> usually, and any invocation at all after it is cleaned would result in >> Major Problems. In this case you would put the FD, memory >> address/size/etc. on the cleaner, so that the clean method can do the >> cleanup. > > Cleaners are also more efficient in that: > > - they register cleanup actions manually from java code after the > referent is constructed. finalize() uses a call-back from VM into Java > to register a Finalizer on finalizable referent construction. Interesting, I didn't know that. I always assumed that finalization used a reference queue. > - they can invoke and de-register cleanup actions prematurely by user > explicitly invoking Cleanable.clean() and therefore avoid being > processed by reference processing machinery (in the VM and in Java). For > example, FileInputStream, using this API instead of finalize(), would in > majority of cases invoke and de-register the cleanup prematurely as most > code makes sure it closes the file after use. finalize() OTOH has no > premature de-registration feature. Yeah, I guess I see this argument, though in the native resource case you often want to take one action on close (like dup2 a dead FD into the FD slot, or change the state of mapped memory somehow) and a different action on GC (release the FD number or unmap memory). Otherwise you have to (somehow) synchronize all operations against the closed state (it's usually not enough to check it on method entry in such cases). > - with a fix for "8071507: (ref) Clear phantom reference as soft and > weak references do", the opportunity for GC to collect the referent in > the same phase as discovering it phantom-reachable opens up. Finalizer > OTOH keeps the referent reachable in order to invoke finalize() on it > and then clear()s the reference, delaying the collection of referent to > the next GC round. True, but this comes back to the question: do I need "this" do perform the cleanup action, or not? If yes, finalize(), if no, cleaner/PhantomReference. >> Also, one hopes that each framework/library/application would only >> register one cleaner for its usages, rather than (say) one per class... > > There was a debate about whether to provide a common cleaner instance: > Cleaner.commonCleaner() (like ForkJoinPool.commonPool()). It could be > created lazily, but then it would run forever... No opinion on this. -- - DML From rob.mckenna at oracle.com Tue Dec 8 16:11:12 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 Dec 2015 16:11:12 +0000 Subject: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently In-Reply-To: <5666FB2E.7010304@oracle.com> References: <5666E27F.1080100@oracle.com> <5666FB2E.7010304@oracle.com> Message-ID: <56670120.3010603@oracle.com> Thanks, just spotted that myself after attempting to run it in a loop via jtreg. (in case jtreg is somehow involved in causing the intermittent failure) Will be corrected pre-push. -Rob On 08/12/15 15:45, Daniel Fuchs wrote: > Hey Rob, > > The @run line seems to be wrong in the new test file: > > 26 * @run main/othervm LdapTimeoutTest > > cheers, > > -- daniel > > On 08/12/15 15:00, Rob McKenna wrote: >> Hi folks, >> >> Hopefully this fix puts this tests' failures to bed. (mind you I've >> thought that before) >> >> Basically I've separated the failing subtest out into its own file and >> excluded it on the (intermittently) failing platforms. >> >> http://cr.openjdk.java.net/~robm/8141370/webrev.01/ >> >> -Rob > From mandy.chung at oracle.com Tue Dec 8 17:03:25 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Dec 2015 09:03:25 -0800 Subject: RFR(XS): 8081512: Remove sun.invoke.anon classes, or move / co-locate them with tests In-Reply-To: References: Message-ID: > On Dec 8, 2015, at 1:37 AM, Michael Haupt wrote: > > Dear all, > > please review and sponsor this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8081512 > Webrev: http://cr.openjdk.java.net/~mhaupt/8081512/webrev.00/ +1 Mandy From brian.burkhalter at oracle.com Tue Dec 8 17:22:20 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 8 Dec 2015 09:22:20 -0800 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: <5666D9A0.5040705@oracle.com> References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56617A37.3070408@oracle.com> <5666D9A0.5040705@oracle.com> Message-ID: On Dec 8, 2015, at 5:22 AM, Alan Bateman wrote: >> Not sure whether this change requires CCC approval. >> > One suggestion is to use "while" rather than "if", otherwise looks okay I think. An updated version with ?while? instead of ?if? is here: http://cr.openjdk.java.net/~bpb/8143394/webrev.02/ Thanks, Brian From kim.barrett at oracle.com Tue Dec 8 18:25:00 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 13:25:00 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56669053.1080404@oracle.com> References: <560D3F61.6040607@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> Message-ID: <38E0777B-0081-4176-B158-49CC404200F8@oracle.com> On Dec 8, 2015, at 3:09 AM, David Holmes wrote: > > Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? Aside: I like David's suggested "action" terminology. > Question: what happens if an object is registered simultaneously with > multiple Cleaners? Do we need to warn the user against that? Registering an object with multiple Cleaners, or even the same Cleaner multiple times, is not a problem, so long as the various cleanup actions can cope with that. This is even expected to occur in practice. Consider the conversion of a class hierarchy away from using finalize() to instead using Cleaners. A base class may register a cleanup action for the state associated with that (base) class. A derived class may independently register a cleanup action for the additional state associated with that derived class. The derived class's cleanup action might be registered with the same or a different Cleaner than that used by the base class. From kim.barrett at oracle.com Tue Dec 8 18:44:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 13:44:59 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666D0B3.7070905@oracle.com> References: <560D3F61.6040607@Oracle.com> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.707090! 5@oracle.com> Message-ID: On Dec 8, 2015, at 7:44 AM, David Holmes wrote: > But thinking more on this approach this is simply not scalable. A > Cleaner per cleanable-class could result in hundreds of threads being > active! That would indeed be awful. However, the scope of a Cleaner should not usually be a class. More typically it would be a subsystem, module, plugin, or some other sensible unit of sharing. I assume Peter's example had a class-scoped Cleaner for simplicity of presentation. A class-scoped Cleaner probably should be treated as a canonical anti-pattern for Cleaner usage; appropriate in rare circumstances, but usually a mistake. > What exactly are the advantages over finalization again? The same as PhantomReference-based cleanup vs finalization. - Performance (especially after JDK-8071507). - Semantic simplicity, avoiding the need to deal with resurrection of objects, and objects not needing to protect themselves from some kinds of post-cleanup misuse. From peter.levart at gmail.com Tue Dec 8 18:51:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Dec 2015 19:51:22 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5666F89B.7050001@oracle.com> References: <560D3F61.6040607@Oracle.com> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> Message-ID: <566726AA.7070005@gmail.com> On 12/08/2015 04:34 PM, Roger Riggs wrote: > Hi Peter, > > Thanks for the example and explanations. > > For simple cleanup of specific state values, I probably would have > used lambda instead of an explicit > inner class but both styles use the same mechanism. > The point about using a shared cleaner can be reinforced in the > example too. > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = > cleaner.register(this, () -> fd.close()); > > @Override > public void close() { > cleanable.clean(); > } > } > Sorry Roger, but this example is flawed. This is tricky! The lambda "() -> fd.close()" captures 'this', not only 'fd' as can be seen by running the following example: public class Test { int x = 0; final IntSupplier xSupplier = () -> x; public static void main(String[] args) { Test t = new Test(); System.out.println(t.xSupplier.getAsInt()); t.x = 12; System.out.println(t.xSupplier.getAsInt()); } } ...which prints: 0 12 To correct that, but still use lambda, you would have to capture a local variable, like: public class Test { int x = 0; final IntSupplier xSupplier; { int xValue = x; xSupplier = () -> xValue; } public static void main(String[] args) { Test t = new Test(); System.out.println(t.xSupplier.getAsInt()); t.x = 12; System.out.println(t.xSupplier.getAsInt()); } } ...now prints: 0 0 Regards, Peter > > I'll work the example into the javadoc. > > Roger > > > On 12/08/2015 07:25 AM, Peter Levart wrote: >> >> >> On 12/08/2015 09:22 AM, David Holmes wrote: >>> Actually I'm having more doubts about this API. >>> >>> Library writers use finalize() as a last ditch cleanup mechanism in >>> case the user doesn't explicitly call any "cleanup" method. So as a >>> library writer I would think I am now expected to register my >>> instances with a Cleaner and provide a Runnable that does what >>> finalize() would have done. But in that usage pattern the end user of >>> my objects never has any access to my Cleanables so can never call >>> clean() themselves - instead they should be calling the cleanup >>> function directly, just as they would previously. So the whole "invoke >>> at most once" for the clean() method seems somewhat unnecessary; and >>> the way we should write the cleanup method and the Runnable need to be >>> more cleary explained as the idempotentcy of the cleanup needs to be >>> handled in the library writers code not the Cleaner/Clenable >>> implementation. >>> >>> David >> >> Hi David, (once again for the list) >> >> I agree that an example would be most helpful. Here's how a normal >> finalizable object is typically coded: >> >> public class FinalizeExample implements AutoCloseable { >> >> private boolean closed; >> >> @Override >> public synchronized void close() { >> if (!closed) { >> closed = true; >> // cleanup actions accessing state of >> FinalizeExample, executed at most once >> } >> } >> >> @Override >> protected void finalize() throws Throwable { >> close(); >> } >> } >> >> >> Re-factoring to use Cleaner is a process that extracts the state >> representing native resource from the user-facing class into a >> private nested static class and makes the user-facing object just a >> facade that has access to the state object and is registered with a >> Cleaner. The Cleaner.Cleanable instance is also made accessible from >> the user-facing object, so it can provide the on-demand cleaning: >> >> public static class CleanerExample implements AutoCloseable { >> >> private static class State implements Runnable { >> @Override >> public void run() { >> // cleanup actions accessing State, executed at most >> once >> } >> } >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final State state = new State(); >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this, state); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } >> >> >> Regards, Peter >> >>> >>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>> Hi Roger, >>>> >>>> Sorry I had no choice but to look at this more closely ... and >>>> apologies >>>> as this is very late feedback ... I only looked at the API not the >>>> details of the implementation. >>>> >>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>> Hi David, >>>>> >>>>> Thanks for the comments, >>>>> >>>>> Updated the javadoc and webrev with editorial changes. >>>>> >>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>> >>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>> part of >>>> the core reference related functionality. Perhaps even state how they >>>> are preferred to use of finalization? >>>> >>>> Cleaner.Cleanable: >>>> >>>> It was unclear to me what the usage model was for this. I'm assuming >>>> that the intent is that rather than register a "thunk" (lets call >>>> it an >>>> "action") that can be invoked directly by user-code, the user should >>>> invoke the action via the call to clean(). In which case I think it >>>> should be explained somewhat more clearly - see below. >>>> >>>> I would describe the Cleanable class as: >>>> >>>> Cleanable: Represents an object that has been registered for >>>> cleanup by >>>> a Cleaner. The object can be cleaned directly, by a call to >>>> clean(), if >>>> it is no longer to be used, else it will be cleaned automatically when >>>> the object becomes phantom-reachable. >>>> >>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>> action that was associated with it. If this Cleanable has already been >>>> unregistered nothing happens. The cleanup action is invoked at most >>>> once >>>> per registered Cleanable, regardless of the number of calls to >>>> clean(). >>>> >>>> --- >>>> >>>> Looking at Cleaner .... >>>> >>>> >>>> "Cleaner manages a set of object references and corresponding cleaning >>>> functions" >>>> >>>> I would say "cleaning actions" rather than functions as they yield no >>>> value. This change needs to be made throughout. >>>> >>>> "The most efficient use is to explicitly invoke the clean method when >>>> the object is closed or no longer needed. The cleaning function is a >>>> Runnable to be invoked at most once when the object is no longer >>>> reachable unless it has already been explicitly cleaned." >>>> >>>> To me this doesn't quite capture the need to not use the Runnable >>>> directly. I would rephrase: >>>> >>>> "In normal use a object should be cleaned up when no longer >>>> required, by >>>> invoking the clean() method of the associated Cleanable. This >>>> guarantees >>>> that the cleaning action will be performed at most once per object: >>>> either explicitly, or automatically if it becomes >>>> phantom-reachable. If >>>> cleaned explicitly the object should not be used again. Note that the >>>> cleaning action must not refer to the object ..." >>>> >>>> --- >>>> >>>> Question: what happens if an object is registered simultaneously with >>>> multiple Cleaners? Do we need to warn the user against that? >>>> >>>> --- >>>> >>>> The phrase "process the unreachable objects and to invoke cleaning >>>> functions" doesn't quite seem right to me. The objects themselves are >>>> never processed, or even touched - right? So really the thread is >>>> started to "invoke the cleanup actions for unreachable objects". >>>> >>>> create(): can also throw SecurityException if not allowed to >>>> create/start threads. >>>> >>>> register(Object obj, Runnable thunk): thunk -> action >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> >>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Sorry to be late here but was trying not to get involved :) >>>>>> >>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>> ThreadFactory could throw anything) . >>>>> It does seem that new is fairly well understood but one can read of >>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>> the >>>>> Thread.State of the new thread >>>>> and since it allows various attributes of the thread to be modified >>>>> after the constructor. >>>>> Since the runnable is supplied as an argument it is ready to be >>>>> started, >>>>> why not. >>>>> It seemed useful to reinforce the salient points. >>>>>> >>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>> The thread construction is done in doPriv so it should not throw. >>>>> Did I miss some edge case? >>>>>> >>>>>> Also this: >>>>>> >>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>> thread factory} >>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>> an appropriate >>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>> loader}, >>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>> 132 * permissions, etc. >>>>>> >>>>>> then begs the questions as to what is "appropriate". I think this >>>>>> can >>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>> Thread >>>>>> that is suitable for performing the cleaning work". Though even that >>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>> needed >>>>>> here ?? Special security context? If so that could be mentioned, >>>>>> but I >>>>>> don't think name or priority need to be discussed. >>>>> It was intended to prod the client to be deliberate about the >>>>> threadFactory. >>>>> Since the client is integrating the Cleaner and respective cleaning >>>>> functions >>>>> with the client code, the ThreadFactory makes it possible for the >>>>> client to >>>>> initialize a suitable thread and the comments serve as a reminder. >>>>> I agree that the phrase 'suitable for performing the cleaning >>>>> work' is >>>>> the operative one. >>>>> >>>>> Thanks, Roger >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>> >> > From stevenschlansker at gmail.com Tue Dec 8 19:08:57 2015 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Tue, 8 Dec 2015 11:08:57 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566726AA.7070005@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> Message-ID: <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: > On 12/08/2015 04:34 PM, Roger Riggs wrote: >> >> private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); > > Sorry Roger, but this example is flawed. This is tricky! The lambda "() -> fd.close()" captures 'this', not only 'fd' as can be seen by running the following example: > To correct that, but still use lambda, you would have to capture a local variable It looks like using "fd::close" might also work, and is more concise: IntSupplier x = () -> 10; IntSupplier xS = x::getAsInt; @Test public void test() { System.out.println(xS.getAsInt()); x = () -> 15; System.out.println(xS.getAsInt()); } 10 10 > >> >> I'll work the example into the javadoc. >> >> Roger >> >> >> On 12/08/2015 07:25 AM, Peter Levart wrote: >>> >>> >>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>> Actually I'm having more doubts about this API. >>>> >>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>> library writer I would think I am now expected to register my >>>> instances with a Cleaner and provide a Runnable that does what >>>> finalize() would have done. But in that usage pattern the end user of >>>> my objects never has any access to my Cleanables so can never call >>>> clean() themselves - instead they should be calling the cleanup >>>> function directly, just as they would previously. So the whole "invoke >>>> at most once" for the clean() method seems somewhat unnecessary; and >>>> the way we should write the cleanup method and the Runnable need to be >>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>> handled in the library writers code not the Cleaner/Clenable >>>> implementation. >>>> >>>> David >>> >>> Hi David, (once again for the list) >>> >>> I agree that an example would be most helpful. Here's how a normal finalizable object is typically coded: >>> >>> public class FinalizeExample implements AutoCloseable { >>> >>> private boolean closed; >>> >>> @Override >>> public synchronized void close() { >>> if (!closed) { >>> closed = true; >>> // cleanup actions accessing state of FinalizeExample, executed at most once >>> } >>> } >>> >>> @Override >>> protected void finalize() throws Throwable { >>> close(); >>> } >>> } >>> >>> >>> Re-factoring to use Cleaner is a process that extracts the state representing native resource from the user-facing class into a private nested static class and makes the user-facing object just a facade that has access to the state object and is registered with a Cleaner. The Cleaner.Cleanable instance is also made accessible from the user-facing object, so it can provide the on-demand cleaning: >>> >>> public static class CleanerExample implements AutoCloseable { >>> >>> private static class State implements Runnable { >>> @Override >>> public void run() { >>> // cleanup actions accessing State, executed at most once >>> } >>> } >>> >>> private static final Cleaner cleaner = Cleaner.create(); >>> >>> private final State state = new State(); >>> private final Cleaner.Cleanable cleanable = cleaner.register(this, state); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> } >>> >>> >>> Regards, Peter >>> >>>> >>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>> Hi Roger, >>>>> >>>>> Sorry I had no choice but to look at this more closely ... and apologies >>>>> as this is very late feedback ... I only looked at the API not the >>>>> details of the implementation. >>>>> >>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for the comments, >>>>>> >>>>>> Updated the javadoc and webrev with editorial changes. >>>>>> >>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>> >>>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>>> for java.lang.ref? Else they seem to be an overlooked add-on not part of >>>>> the core reference related functionality. Perhaps even state how they >>>>> are preferred to use of finalization? >>>>> >>>>> Cleaner.Cleanable: >>>>> >>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>> that the intent is that rather than register a "thunk" (lets call it an >>>>> "action") that can be invoked directly by user-code, the user should >>>>> invoke the action via the call to clean(). In which case I think it >>>>> should be explained somewhat more clearly - see below. >>>>> >>>>> I would describe the Cleanable class as: >>>>> >>>>> Cleanable: Represents an object that has been registered for cleanup by >>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>>>> it is no longer to be used, else it will be cleaned automatically when >>>>> the object becomes phantom-reachable. >>>>> >>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>> action that was associated with it. If this Cleanable has already been >>>>> unregistered nothing happens. The cleanup action is invoked at most once >>>>> per registered Cleanable, regardless of the number of calls to clean(). >>>>> >>>>> --- >>>>> >>>>> Looking at Cleaner .... >>>>> >>>>> >>>>> "Cleaner manages a set of object references and corresponding cleaning >>>>> functions" >>>>> >>>>> I would say "cleaning actions" rather than functions as they yield no >>>>> value. This change needs to be made throughout. >>>>> >>>>> "The most efficient use is to explicitly invoke the clean method when >>>>> the object is closed or no longer needed. The cleaning function is a >>>>> Runnable to be invoked at most once when the object is no longer >>>>> reachable unless it has already been explicitly cleaned." >>>>> >>>>> To me this doesn't quite capture the need to not use the Runnable >>>>> directly. I would rephrase: >>>>> >>>>> "In normal use a object should be cleaned up when no longer required, by >>>>> invoking the clean() method of the associated Cleanable. This guarantees >>>>> that the cleaning action will be performed at most once per object: >>>>> either explicitly, or automatically if it becomes phantom-reachable. If >>>>> cleaned explicitly the object should not be used again. Note that the >>>>> cleaning action must not refer to the object ..." >>>>> >>>>> --- >>>>> >>>>> Question: what happens if an object is registered simultaneously with >>>>> multiple Cleaners? Do we need to warn the user against that? >>>>> >>>>> --- >>>>> >>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>> never processed, or even touched - right? So really the thread is >>>>> started to "invoke the cleanup actions for unreachable objects". >>>>> >>>>> create(): can also throw SecurityException if not allowed to >>>>> create/start threads. >>>>> >>>>> register(Object obj, Runnable thunk): thunk -> action >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> >>>>>> >>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>> >>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>> ThreadFactory could throw anything) . >>>>>> It does seem that new is fairly well understood but one can read of >>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>>>> Thread.State of the new thread >>>>>> and since it allows various attributes of the thread to be modified >>>>>> after the constructor. >>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>> started, >>>>>> why not. >>>>>> It seemed useful to reinforce the salient points. >>>>>>> >>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>> The thread construction is done in doPriv so it should not throw. >>>>>> Did I miss some edge case? >>>>>>> >>>>>>> Also this: >>>>>>> >>>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>>> thread factory} >>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>> an appropriate >>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>> loader}, >>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>> 132 * permissions, etc. >>>>>>> >>>>>>> then begs the questions as to what is "appropriate". I think this can >>>>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>>>> that is suitable for performing the cleaning work". Though even that >>>>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>>>> here ?? Special security context? If so that could be mentioned, but I >>>>>>> don't think name or priority need to be discussed. >>>>>> It was intended to prod the client to be deliberate about the >>>>>> threadFactory. >>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>> functions >>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>> client to >>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>>>> the operative one. >>>>>> >>>>>> Thanks, Roger >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>> >>> >> > From peter.levart at gmail.com Tue Dec 8 19:26:17 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Dec 2015 20:26:17 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <38E0777B-0081-4176-B158-49CC404200F8@oracle.com> References: <560D3F61.6040607@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <38E0777B-0081-4176-B158-49CC404200F8@oracle.com> Message-ID: <56672ED9.9030103@gmail.com> On 12/08/2015 07:25 PM, Kim Barrett wrote: > On Dec 8, 2015, at 3:09 AM, David Holmes wrote: >> Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? > Aside: I like David's suggested "action" terminology. > >> Question: what happens if an object is registered simultaneously with >> multiple Cleaners? Do we need to warn the user against that? > Registering an object with multiple Cleaners, or even the same Cleaner > multiple times, is not a problem, so long as the various cleanup > actions can cope with that. This is even expected to occur in > practice. Consider the conversion of a class hierarchy away from > using finalize() to instead using Cleaners. A base class may register > a cleanup action for the state associated with that (base) class. A > derived class may independently register a cleanup action for the > additional state associated with that derived class. The derived > class's cleanup action might be registered with the same or a > different Cleaner than that used by the base class. > One thing to note is that independent actions registered on the same referent may execute in arbitrary order (each registration is a separate PhantomReference). If order is important then something like the following will be required: public class BasicClass implements AutoCloseable { protected static class BasicState implements Runnable { @Override public void run() { // cleanup actions that access 'BasicState' } } protected BasicState createState() { return new BasicState(); } private final BasicState state = createState(); private final Cleaner.Cleanable cleanable = Cleaner.commonCleaner().register(this, state); @Override public void close() throws Exception { cleanable.clean(); } } public class DerivedClass extends BasicClass { protected static class DerivedState extends BasicState { @Override public void run() { super.run(); // BasicState cleanup... // DerivedState cleanup... } } @Override protected BasicState createState() { return new DerivedState(); } } ...this is not so simple as with finalize() any more, but doable. It's unfortunate that the "more complicated" PhantomCleanable API did not make it as it would not be much more complicated for such scenarios: public class BasicClass implements AutoCloseable { protected static class BasicCleanableState extends CleanerImpl.PhantomCleanable { public BasicCleanableState(BasicClass referent, Cleaner cleaner) { super(referent, cleaner); } @Override protected void performCleanup() { // cleanup actions that access 'BasicCleanableState' } } protected BasicCleanableState createState(Cleaner cleaner) { return new BasicCleanableState(this, cleaner); } private final BasicCleanableState cleanableState = createState(Cleaner.commonCleaner()); @Override public void close() throws Exception { cleanableState.clean(); } } public class DerivedClass extends BasicClass { protected static class DerivedCleanableState extends BasicCleanableState { public DerivedCleanableState(BasicClass referent, Cleaner cleaner) { super(referent, cleaner); } @Override protected void performCleanup() { super.performCleanup(); // BasicCleanableState cleanup // DerivedCleanableState cleanup } } @Override protected BasicCleanableState createState(Cleaner cleaner) { return new DerivedCleanableState(this, cleaner); } } Regards, Peter From Roger.Riggs at oracle.com Tue Dec 8 20:01:17 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 15:01:17 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566726AA.7070005@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> Message-ID: <5667370D.9020807@oracle.com> Hi Peter, Tricky indeed, the visibility of what is captured is too subtle. Even if the field is final, it captures this, not the value. I suppose it is more efficient not to copy field values. But other than recommending capturing only local variables and arguments, is there any other relevant advice? I added examples of both nested class based and lambda based cleaners to the Cleaner javadoc in the @apiNote. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger On 12/08/2015 01:51 PM, Peter Levart wrote: > > > On 12/08/2015 04:34 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for the example and explanations. >> >> For simple cleanup of specific state values, I probably would have >> used lambda instead of an explicit >> inner class but both styles use the same mechanism. >> The point about using a shared cleaner can be reinforced in the >> example too. >> >> public static class CleanerExample implements AutoCloseable { >> >> FileDescriptor fd = ...; >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this, () -> fd.close()); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } >> > > Sorry Roger, but this example is flawed. This is tricky! The lambda > "() -> fd.close()" captures 'this', not only 'fd' as can be seen by > running the following example: > > public class Test { > > int x = 0; > > final IntSupplier xSupplier = () -> x; > > public static void main(String[] args) { > Test t = new Test(); > System.out.println(t.xSupplier.getAsInt()); > t.x = 12; > System.out.println(t.xSupplier.getAsInt()); > } > } > > ...which prints: > > 0 > 12 > > > To correct that, but still use lambda, you would have to capture a > local variable, like: > > public class Test { > > int x = 0; > > final IntSupplier xSupplier; > > { > int xValue = x; > xSupplier = () -> xValue; > } > > public static void main(String[] args) { > Test t = new Test(); > System.out.println(t.xSupplier.getAsInt()); > t.x = 12; > System.out.println(t.xSupplier.getAsInt()); > } > } > > > ...now prints: > > 0 > 0 > > > Regards, Peter > >> From mandy.chung at oracle.com Tue Dec 8 20:19:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Dec 2015 12:19:02 -0800 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> Message-ID: <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> > On Dec 8, 2015, at 6:50 AM, Chris Hegarty wrote: > > > On 8 Dec 2015, at 14:33, Roger Riggs wrote: >> Adding an argument to the most flexible constructor of Thread bulks up >> an already heavy weight constructor. Look at the cases being replaced, >> none of them use all of the arguments. The stackSize, for example, is rarely >> used and is nearly useless due to its implementation dependencies. > > Right. The motivation for adding an additional constructor that accepts a > superset of arguments is for maximum flexibility. Since this is targeted at > the advanced user, then it should be ok, but I agree it looks a little unwieldy. > >> Would you consider using a static Factory method (aptly named) instead >> of a constructor? > > Possibly, I went down the constructor route for consistency with what is > already there. The usage pattern of extending Thread is also very common. Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? Mandy From kim.barrett at oracle.com Tue Dec 8 20:22:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2015 15:22:36 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56672ED9.9030103@gmail.com> References: <560D3F61.6040607@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <38E0777B-0081-4176-B158-49CC404200F8@oracle.com> <56672ED! 9.9030103@gmail.com> Message-ID: <317BE43F-B4E7-4A5B-87B7-96D25CDD620D@oracle.com> On Dec 8, 2015, at 2:26 PM, Peter Levart wrote: > > On 12/08/2015 07:25 PM, Kim Barrett wrote: >> On Dec 8, 2015, at 3:09 AM, David Holmes >> wrote: >> >>> Question: what happens if an object is registered simultaneously with multiple Cleaners? Do we need to warn the user against that? >>> >> Aside: I like David's suggested "action" terminology. >> >> >>> Question: what happens if an object is registered simultaneously with >>> multiple Cleaners? Do we need to warn the user against that? >>> >> Registering an object with multiple Cleaners, or even the same Cleaner >> multiple times, is not a problem, so long as the various cleanup >> actions can cope with that. This is even expected to occur in >> practice. Consider the conversion of a class hierarchy away from >> using finalize() to instead using Cleaners. A base class may register >> a cleanup action for the state associated with that (base) class. A >> derived class may independently register a cleanup action for the >> additional state associated with that derived class. The derived >> class's cleanup action might be registered with the same or a >> different Cleaner than that used by the base class. >> >> > > One thing to note is that independent actions registered on the same referent may execute in arbitrary order (each registration is a separate PhantomReference). If order is important then something like the following will be required: Yes, although I think such interactions will turn out to be quite rare in practice, once the different cleanups no longer need to take into consideration the registered object. From chris.hegarty at oracle.com Tue Dec 8 20:28:03 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 8 Dec 2015 20:28:03 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> Message-ID: > On 8 Dec 2015, at 8:19 p.m., Mandy Chung wrote: > > >> On Dec 8, 2015, at 6:50 AM, Chris Hegarty wrote: >> >> >>> On 8 Dec 2015, at 14:33, Roger Riggs wrote: >>> Adding an argument to the most flexible constructor of Thread bulks up >>> an already heavy weight constructor. Look at the cases being replaced, >>> none of them use all of the arguments. The stackSize, for example, is rarely >>> used and is nearly useless due to its implementation dependencies. >> >> Right. The motivation for adding an additional constructor that accepts a >> superset of arguments is for maximum flexibility. Since this is targeted at >> the advanced user, then it should be ok, but I agree it looks a little unwieldy. >> >>> Would you consider using a static Factory method (aptly named) instead >>> of a constructor? >> >> Possibly, I went down the constructor route for consistency with what is >> already there. The usage pattern of extending Thread is also very common. > > > Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently? -Chris. From mandy.chung at oracle.com Tue Dec 8 20:53:47 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Dec 2015 12:53:47 -0800 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> Message-ID: <028AB270-89CE-41EE-810E-7E04D84BA585@oracle.com> > On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: > >> >> Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? > > I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently? I am not thinking of any new thread-local related operation. The boolean inheritThreadLocals argument is added to one single constructor that forces the caller to pass the null/zero or other default value is not ideal. Since the audience of this API would be small, defining a new class with the appropriate constructors (perhaps no stackSize) is a good alternative. The change would still be simple. Mandy From paul.sandoz at oracle.com Tue Dec 8 21:01:57 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 8 Dec 2015 22:01:57 +0100 Subject: Reference.reachabilityFence In-Reply-To: <20151207095825.952677@eggemoggin.niobe.net> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> Message-ID: <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> > On 7 Dec 2015, at 18:58, mark.reinhold at oracle.com wrote: > > 2015/12/4 5:47 -0800, paul.sandoz at oracle.com: >>> On 3 Dec 2015, at 22:33, Mandy Chung wrote: >>>> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/ >>>> >>>> There is now more documentation on Reference (copied and suitable >>>> rearranged from 166 Fences.java). The method name remains the same. >>> >>> I think the addition to the Reference class specification should >>> belong to the reachabilityFence method specification. Any reason why >>> not? >> >> I thought it would be more visible in the JavaDoc, as it?s there >> upfront. The api note may get larger if we include some additional >> real world examples. I don?t have a strong opinion on this, if yours >> is stronger i will move it :-) > > I agree with Mandy -- the new text about fences belongs in the method > doc, not the class doc. Thanks, moved. > > Further comments, mostly minor: > > - In the opening sentence, s/strongly reachability/strong reachability/. > > - I'd remove the phrase "As illustrated in the sample usages of the > api note below" from the normative text. The API note follows > immediately; there's no need to point to it. > > - s/a Java Virtual Machine/the virtual machine/ > > - s/A garbage collector/The garbage collector/ > > - s/call to/invocation of/ > > - s/ for example /, for example,/ > > - s/if it were OK/if it were acceptable/ ("OK" is a bit too informal) > > - s!in general!, in general,! > > - s/Fences.reachabilityFence/Reference.reachabilityFence/ in the examples > Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html I think there is an opportunity to add further examples, but i would like to take a swing at that later on. > - I now agree with you and Doug about calling this a "fence". Can we > just name it "fence" rather than the wordier "reachabilityFence"? > Looking at a typical invocation, > > Reference.reachabilityFence(); > > seems a bit redundant while > > Reference.fence(); > > reads quite nicely. Is there, or will there ever be, any other kind > of reference-related fence? > I doubt there will be another kind of reference fence, but it could be used in conjunction with other memory fences (currently on VarHandles) and if static imports are used it might look rather out of place as to what fence ?fence? actually refers to. That is why i prefer the longer more descriptive name. Paul. From Roger.Riggs at oracle.com Tue Dec 8 21:08:25 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 16:08:25 -0500 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <028AB270-89CE-41EE-810E-7E04D84BA585@oracle.com> References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> <028AB270-89CE-41EE-810E-7E04D84BA585@oracle.com> Message-ID: <566746C9.9040006@oracle.com> Hi, Using a static factory method, in Thread, would I think be preferable to creating a whole new class and provide the opportunity to name it intuitively. $.02, Roger On 12/08/2015 03:53 PM, Mandy Chung wrote: >> On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: >> >>> Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? >> I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently? > I am not thinking of any new thread-local related operation. The boolean inheritThreadLocals argument is added to one single constructor that forces the caller to pass the null/zero or other default value is not ideal. > > Since the audience of this API would be small, defining a new class with the appropriate constructors (perhaps no stackSize) is a good alternative. The change would still be simple. > > Mandy From peter.levart at gmail.com Tue Dec 8 21:24:16 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 8 Dec 2015 22:24:16 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> Message-ID: <56674A80.6070906@gmail.com> On 12/08/2015 08:08 PM, Steven Schlansker wrote: > On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: >> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>> private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); >> Sorry Roger, but this example is flawed. This is tricky! The lambda "() -> fd.close()" captures 'this', not only 'fd' as can be seen by running the following example: >> To correct that, but still use lambda, you would have to capture a local variable > It looks like using "fd::close" might also work, and is more concise: > > IntSupplier x = () -> 10; > IntSupplier xS = x::getAsInt; > > @Test > public void test() { > System.out.println(xS.getAsInt()); > x = () -> 15; > System.out.println(xS.getAsInt()); > } > > 10 > 10 Yes, good idea. This is a pre-bound method reference (the part on the left of '::' is evaluated immediately). Contrast to lambda, where "fd.close()" is an expression in the lambda body which is evaluated when lambda is invoked and that expression is composed of a field get + method invocation. In order to get an instance field, the object containing it must be captured. So for Roger's example, this will work: public static class CleanerExample implements AutoCloseable { FileDescriptor fd = ...; private static final Cleaner cleaner = Cleaner.create(); private final Cleaner.Cleanable cleanable = cleaner.register(this, fd::close); @Override public void close() { cleanable.clean(); } } ...if FileDescriptor.close() is an instance method with no arguments and doesn't throw any checked exceptions. Regards, Peter > >>> I'll work the example into the javadoc. >>> >>> Roger >>> >>> >>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>> Actually I'm having more doubts about this API. >>>>> >>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>> library writer I would think I am now expected to register my >>>>> instances with a Cleaner and provide a Runnable that does what >>>>> finalize() would have done. But in that usage pattern the end user of >>>>> my objects never has any access to my Cleanables so can never call >>>>> clean() themselves - instead they should be calling the cleanup >>>>> function directly, just as they would previously. So the whole "invoke >>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>> the way we should write the cleanup method and the Runnable need to be >>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>> handled in the library writers code not the Cleaner/Clenable >>>>> implementation. >>>>> >>>>> David >>>> Hi David, (once again for the list) >>>> >>>> I agree that an example would be most helpful. Here's how a normal finalizable object is typically coded: >>>> >>>> public class FinalizeExample implements AutoCloseable { >>>> >>>> private boolean closed; >>>> >>>> @Override >>>> public synchronized void close() { >>>> if (!closed) { >>>> closed = true; >>>> // cleanup actions accessing state of FinalizeExample, executed at most once >>>> } >>>> } >>>> >>>> @Override >>>> protected void finalize() throws Throwable { >>>> close(); >>>> } >>>> } >>>> >>>> >>>> Re-factoring to use Cleaner is a process that extracts the state representing native resource from the user-facing class into a private nested static class and makes the user-facing object just a facade that has access to the state object and is registered with a Cleaner. The Cleaner.Cleanable instance is also made accessible from the user-facing object, so it can provide the on-demand cleaning: >>>> >>>> public static class CleanerExample implements AutoCloseable { >>>> >>>> private static class State implements Runnable { >>>> @Override >>>> public void run() { >>>> // cleanup actions accessing State, executed at most once >>>> } >>>> } >>>> >>>> private static final Cleaner cleaner = Cleaner.create(); >>>> >>>> private final State state = new State(); >>>> private final Cleaner.Cleanable cleanable = cleaner.register(this, state); >>>> >>>> @Override >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Sorry I had no choice but to look at this more closely ... and apologies >>>>>> as this is very late feedback ... I only looked at the API not the >>>>>> details of the implementation. >>>>>> >>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for the comments, >>>>>>> >>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>> >>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not part of >>>>>> the core reference related functionality. Perhaps even state how they >>>>>> are preferred to use of finalization? >>>>>> >>>>>> Cleaner.Cleanable: >>>>>> >>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>> that the intent is that rather than register a "thunk" (lets call it an >>>>>> "action") that can be invoked directly by user-code, the user should >>>>>> invoke the action via the call to clean(). In which case I think it >>>>>> should be explained somewhat more clearly - see below. >>>>>> >>>>>> I would describe the Cleanable class as: >>>>>> >>>>>> Cleanable: Represents an object that has been registered for cleanup by >>>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>>>>> it is no longer to be used, else it will be cleaned automatically when >>>>>> the object becomes phantom-reachable. >>>>>> >>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>> action that was associated with it. If this Cleanable has already been >>>>>> unregistered nothing happens. The cleanup action is invoked at most once >>>>>> per registered Cleanable, regardless of the number of calls to clean(). >>>>>> >>>>>> --- >>>>>> >>>>>> Looking at Cleaner .... >>>>>> >>>>>> >>>>>> "Cleaner manages a set of object references and corresponding cleaning >>>>>> functions" >>>>>> >>>>>> I would say "cleaning actions" rather than functions as they yield no >>>>>> value. This change needs to be made throughout. >>>>>> >>>>>> "The most efficient use is to explicitly invoke the clean method when >>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>> Runnable to be invoked at most once when the object is no longer >>>>>> reachable unless it has already been explicitly cleaned." >>>>>> >>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>> directly. I would rephrase: >>>>>> >>>>>> "In normal use a object should be cleaned up when no longer required, by >>>>>> invoking the clean() method of the associated Cleanable. This guarantees >>>>>> that the cleaning action will be performed at most once per object: >>>>>> either explicitly, or automatically if it becomes phantom-reachable. If >>>>>> cleaned explicitly the object should not be used again. Note that the >>>>>> cleaning action must not refer to the object ..." >>>>>> >>>>>> --- >>>>>> >>>>>> Question: what happens if an object is registered simultaneously with >>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>> >>>>>> --- >>>>>> >>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>>> never processed, or even touched - right? So really the thread is >>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>> >>>>>> create(): can also throw SecurityException if not allowed to >>>>>> create/start threads. >>>>>> >>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>> >>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>> ThreadFactory could throw anything) . >>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>>>>> Thread.State of the new thread >>>>>>> and since it allows various attributes of the thread to be modified >>>>>>> after the constructor. >>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>> started, >>>>>>> why not. >>>>>>> It seemed useful to reinforce the salient points. >>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>> Did I miss some edge case? >>>>>>>> Also this: >>>>>>>> >>>>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>>>> thread factory} >>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>>> an appropriate >>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>> loader}, >>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>> 132 * permissions, etc. >>>>>>>> >>>>>>>> then begs the questions as to what is "appropriate". I think this can >>>>>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>>>>> that is suitable for performing the cleaning work". Though even that >>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>>>>> here ?? Special security context? If so that could be mentioned, but I >>>>>>>> don't think name or priority need to be discussed. >>>>>>> It was intended to prod the client to be deliberate about the >>>>>>> threadFactory. >>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>> functions >>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>> client to >>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>>>>> the operative one. >>>>>>> >>>>>>> Thanks, Roger >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> From mandy.chung at oracle.com Tue Dec 8 22:01:39 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Dec 2015 14:01:39 -0800 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <566746C9.9040006@oracle.com> References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> <028AB270-89CE-41EE-810E-7E04D84BA585@oracle.com> <566746C9.9040006@oracle.com> Message-ID: <28E2B975-2C31-4C28-842D-039D7FFCA2D4@oracle.com> Yes but it won?t work for existing classes that extend Thread. Mandy > On Dec 8, 2015, at 1:08 PM, Roger Riggs wrote: > > Hi, > > Using a static factory method, in Thread, would I think be preferable to creating a whole new class > and provide the opportunity to name it intuitively. > > $.02, Roger > > > On 12/08/2015 03:53 PM, Mandy Chung wrote: >>> On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: >>> >>>> Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? >>> I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently? >> I am not thinking of any new thread-local related operation. The boolean inheritThreadLocals argument is added to one single constructor that forces the caller to pass the null/zero or other default value is not ideal. >> >> Since the audience of this API would be small, defining a new class with the appropriate constructors (perhaps no stackSize) is a good alternative. The change would still be simple. >> >> Mandy > From Roger.Riggs at Oracle.com Tue Dec 8 22:08:04 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 17:08:04 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56674A80.6070906@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> Message-ID: <566754C4.4060308@Oracle.com> Hi, Another option that should always capture is to define a specific static method with the needed values as arguments: public static class CleanerExample implements AutoCloseable { FileDescriptor fd = ...; private static final Cleaner cleaner = Cleaner.create(); private final Cleaner.Cleanable cleanable = cleaner.register(this,*() -> cleanup(fd)*); @Override public void close() { cleanable.clean(); } *static void cleanup(FileDescriptor fd ...) {** ** fd.close();** ** }* } On 12/8/2015 4:24 PM, Peter Levart wrote: > > > On 12/08/2015 08:08 PM, Steven Schlansker wrote: >> On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: >>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>>> private final Cleaner.Cleanable cleanable = cleaner.register(this, () -> fd.close()); >>> Sorry Roger, but this example is flawed. This is tricky! The lambda "() -> fd.close()" captures 'this', not only 'fd' as can be seen by running the following example: >>> To correct that, but still use lambda, you would have to capture a local variable >> It looks like using "fd::close" might also work, and is more concise: >> >> IntSupplier x = () -> 10; >> IntSupplier xS = x::getAsInt; >> >> @Test >> public void test() { >> System.out.println(xS.getAsInt()); >> x = () -> 15; >> System.out.println(xS.getAsInt()); >> } >> >> 10 >> 10 > > Yes, good idea. This is a pre-bound method reference (the part on the > left of '::' is evaluated immediately). Contrast to lambda, where > "fd.close()" is an expression in the lambda body which is evaluated > when lambda is invoked and that expression is composed of a field get > + method invocation. In order to get an instance field, the object > containing it must be captured. > > So for Roger's example, this will work: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = > cleaner.register(this, fd::close); > > @Override > public void close() { > cleanable.clean(); > } > } > > > ...if FileDescriptor.close() is an instance method with no arguments > and doesn't throw any checked exceptions. > > > Regards, Peter > >>>> I'll work the example into the javadoc. >>>> >>>> Roger >>>> >>>> >>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>>> Actually I'm having more doubts about this API. >>>>>> >>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>> library writer I would think I am now expected to register my >>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>> finalize() would have done. But in that usage pattern the end user of >>>>>> my objects never has any access to my Cleanables so can never call >>>>>> clean() themselves - instead they should be calling the cleanup >>>>>> function directly, just as they would previously. So the whole "invoke >>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>> the way we should write the cleanup method and the Runnable need to be >>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>> implementation. >>>>>> >>>>>> David >>>>> Hi David, (once again for the list) >>>>> >>>>> I agree that an example would be most helpful. Here's how a normal finalizable object is typically coded: >>>>> >>>>> public class FinalizeExample implements AutoCloseable { >>>>> >>>>> private boolean closed; >>>>> >>>>> @Override >>>>> public synchronized void close() { >>>>> if (!closed) { >>>>> closed = true; >>>>> // cleanup actions accessing state of FinalizeExample, executed at most once >>>>> } >>>>> } >>>>> >>>>> @Override >>>>> protected void finalize() throws Throwable { >>>>> close(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Re-factoring to use Cleaner is a process that extracts the state representing native resource from the user-facing class into a private nested static class and makes the user-facing object just a facade that has access to the state object and is registered with a Cleaner. The Cleaner.Cleanable instance is also made accessible from the user-facing object, so it can provide the on-demand cleaning: >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static class State implements Runnable { >>>>> @Override >>>>> public void run() { >>>>> // cleanup actions accessing State, executed at most once >>>>> } >>>>> } >>>>> >>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>> >>>>> private final State state = new State(); >>>>> private final Cleaner.Cleanable cleanable = cleaner.register(this, state); >>>>> >>>>> @Override >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry I had no choice but to look at this more closely ... and apologies >>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>> details of the implementation. >>>>>>> >>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for the comments, >>>>>>>> >>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>> Should cleaning and cleanables be mentioned as part of the package-doc >>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not part of >>>>>>> the core reference related functionality. Perhaps even state how they >>>>>>> are preferred to use of finalization? >>>>>>> >>>>>>> Cleaner.Cleanable: >>>>>>> >>>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>>> that the intent is that rather than register a "thunk" (lets call it an >>>>>>> "action") that can be invoked directly by user-code, the user should >>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>> should be explained somewhat more clearly - see below. >>>>>>> >>>>>>> I would describe the Cleanable class as: >>>>>>> >>>>>>> Cleanable: Represents an object that has been registered for cleanup by >>>>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), if >>>>>>> it is no longer to be used, else it will be cleaned automatically when >>>>>>> the object becomes phantom-reachable. >>>>>>> >>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>>> action that was associated with it. If this Cleanable has already been >>>>>>> unregistered nothing happens. The cleanup action is invoked at most once >>>>>>> per registered Cleanable, regardless of the number of calls to clean(). >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Looking at Cleaner .... >>>>>>> >>>>>>> >>>>>>> "Cleaner manages a set of object references and corresponding cleaning >>>>>>> functions" >>>>>>> >>>>>>> I would say "cleaning actions" rather than functions as they yield no >>>>>>> value. This change needs to be made throughout. >>>>>>> >>>>>>> "The most efficient use is to explicitly invoke the clean method when >>>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>> >>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>> directly. I would rephrase: >>>>>>> >>>>>>> "In normal use a object should be cleaned up when no longer required, by >>>>>>> invoking the clean() method of the associated Cleanable. This guarantees >>>>>>> that the cleaning action will be performed at most once per object: >>>>>>> either explicitly, or automatically if it becomes phantom-reachable. If >>>>>>> cleaned explicitly the object should not be used again. Note that the >>>>>>> cleaning action must not refer to the object ..." >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Question: what happens if an object is registered simultaneously with >>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>>>> never processed, or even touched - right? So really the thread is >>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>> >>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>> create/start threads. >>>>>>> >>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>> >>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>> ThreadFactory could throw anything) . >>>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to the >>>>>>>> Thread.State of the new thread >>>>>>>> and since it allows various attributes of the thread to be modified >>>>>>>> after the constructor. >>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>> started, >>>>>>>> why not. >>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>> Did I miss some edge case? >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> 127 * On each call the {@link ThreadFactory#newThread(Runnable) >>>>>>>>> thread factory} >>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>>>> an appropriate >>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>>> loader}, >>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>> 132 * permissions, etc. >>>>>>>>> >>>>>>>>> then begs the questions as to what is "appropriate". I think this can >>>>>>>>> be said much more simply as: "The ThreadFactory must provide a Thread >>>>>>>>> that is suitable for performing the cleaning work". Though even that >>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually needed >>>>>>>>> here ?? Special security context? If so that could be mentioned, but I >>>>>>>>> don't think name or priority need to be discussed. >>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>> threadFactory. >>>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>>> functions >>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>> client to >>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>> I agree that the phrase 'suitable for performing the cleaning work' is >>>>>>>> the operative one. >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> > From ecki at zusammenkunft.net Tue Dec 8 23:07:37 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Wed, 9 Dec 2015 00:07:37 +0100 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <28E2B975-2C31-4C28-842D-039D7FFCA2D4@oracle.com> References: <5666EA24.9040108@oracle.com> <39E92DD0-8D5A-4B4B-AB7C-3832F0F27FB5@oracle.com> <8B10143E-6C38-45E7-9A98-EE8C7A0F63C8@oracle.com> <028AB270-89CE-41EE-810E-7E04D84BA585@oracle.com> <566746C9.9040006@oracle.com> <28E2B975-2C31-4C28-842D-039D7FFCA2D4@oracle.com> Message-ID: Hm, In need of an API I would stick to an executor. Maybe (but thats likely not needed) have a common (caching) thread pool for such tasks. I would kt encourage using those stray thread classes. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Mandy Chung To: Roger Riggs Cc: core-libs-dev at openjdk.java.net Sent: Mi., 09 Dez. 2015 0:02 Subject: Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals Yes but it won?t work for existing classes that extend Thread. Mandy > On Dec 8, 2015, at 1:08 PM, Roger Riggs wrote: > > Hi, > > Using a static factory method, in Thread, would I think be preferable to creating a whole new class > and provide the opportunity to name it intuitively. > > $.02, Roger > > > On 12/08/2015 03:53 PM, Mandy Chung wrote: >>> On Dec 8, 2015, at 12:28 PM, Chris Hegarty wrote: >>> >>>> Since this is target for advanced users, what?s your thought of defining a new subclass extending Thread? >>> I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently? >> I am not thinking of any new thread-local related operation. The boolean inheritThreadLocals argument is added to one single constructor that forces the caller to pass the null/zero or other default value is not ideal. >> >> Since the audience of this API would be small, defining a new class with the appropriate constructors (perhaps no stackSize) is a good alternative. The change would still be simple. >> >> Mandy > From vitalyd at gmail.com Tue Dec 8 23:09:44 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Dec 2015 18:09:44 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56674A80.6070906@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> Message-ID: Can we enhance java to allow specifying lambda capture and how the value is captured? :) This is very subtle to the point where I maybe wouldn't even encourage use of lambda in this context. sent from my phone On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > On 12/08/2015 08:08 PM, Steven Schlansker wrote: > >> On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: >> >>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>> >>>> private final Cleaner.Cleanable cleanable = >>>> cleaner.register(this, () -> fd.close()); >>>> >>> Sorry Roger, but this example is flawed. This is tricky! The lambda "() >>> -> fd.close()" captures 'this', not only 'fd' as can be seen by running the >>> following example: >>> To correct that, but still use lambda, you would have to capture a local >>> variable >>> >> It looks like using "fd::close" might also work, and is more concise: >> >> IntSupplier x = () -> 10; >> IntSupplier xS = x::getAsInt; >> >> @Test >> public void test() { >> System.out.println(xS.getAsInt()); >> x = () -> 15; >> System.out.println(xS.getAsInt()); >> } >> >> 10 >> 10 >> > > Yes, good idea. This is a pre-bound method reference (the part on the left > of '::' is evaluated immediately). Contrast to lambda, where "fd.close()" > is an expression in the lambda body which is evaluated when lambda is > invoked and that expression is composed of a field get + method invocation. > In order to get an instance field, the object containing it must be > captured. > > So for Roger's example, this will work: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = cleaner.register(this, > fd::close); > > @Override > public void close() { > cleanable.clean(); > } > } > > > ...if FileDescriptor.close() is an instance method with no arguments and > doesn't throw any checked exceptions. > > > Regards, Peter > > >> I'll work the example into the javadoc. >>>> >>>> Roger >>>> >>>> >>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>> >>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>> >>>>>> Actually I'm having more doubts about this API. >>>>>> >>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>> library writer I would think I am now expected to register my >>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>> finalize() would have done. But in that usage pattern the end user of >>>>>> my objects never has any access to my Cleanables so can never call >>>>>> clean() themselves - instead they should be calling the cleanup >>>>>> function directly, just as they would previously. So the whole "invoke >>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>> the way we should write the cleanup method and the Runnable need to be >>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>> implementation. >>>>>> >>>>>> David >>>>>> >>>>> Hi David, (once again for the list) >>>>> >>>>> I agree that an example would be most helpful. Here's how a normal >>>>> finalizable object is typically coded: >>>>> >>>>> public class FinalizeExample implements AutoCloseable { >>>>> >>>>> private boolean closed; >>>>> >>>>> @Override >>>>> public synchronized void close() { >>>>> if (!closed) { >>>>> closed = true; >>>>> // cleanup actions accessing state of FinalizeExample, >>>>> executed at most once >>>>> } >>>>> } >>>>> >>>>> @Override >>>>> protected void finalize() throws Throwable { >>>>> close(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Re-factoring to use Cleaner is a process that extracts the state >>>>> representing native resource from the user-facing class into a private >>>>> nested static class and makes the user-facing object just a facade that has >>>>> access to the state object and is registered with a Cleaner. The >>>>> Cleaner.Cleanable instance is also made accessible from the user-facing >>>>> object, so it can provide the on-demand cleaning: >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static class State implements Runnable { >>>>> @Override >>>>> public void run() { >>>>> // cleanup actions accessing State, executed at most >>>>> once >>>>> } >>>>> } >>>>> >>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>> >>>>> private final State state = new State(); >>>>> private final Cleaner.Cleanable cleanable = >>>>> cleaner.register(this, state); >>>>> >>>>> @Override >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>>> apologies >>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>> details of the implementation. >>>>>>> >>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for the comments, >>>>>>>> >>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>>> >>>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>>> package-doc >>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>>> part of >>>>>>> the core reference related functionality. Perhaps even state how they >>>>>>> are preferred to use of finalization? >>>>>>> >>>>>>> Cleaner.Cleanable: >>>>>>> >>>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>>> that the intent is that rather than register a "thunk" (lets call it >>>>>>> an >>>>>>> "action") that can be invoked directly by user-code, the user should >>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>> should be explained somewhat more clearly - see below. >>>>>>> >>>>>>> I would describe the Cleanable class as: >>>>>>> >>>>>>> Cleanable: Represents an object that has been registered for cleanup >>>>>>> by >>>>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), >>>>>>> if >>>>>>> it is no longer to be used, else it will be cleaned automatically >>>>>>> when >>>>>>> the object becomes phantom-reachable. >>>>>>> >>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>>> action that was associated with it. If this Cleanable has already >>>>>>> been >>>>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>>>> once >>>>>>> per registered Cleanable, regardless of the number of calls to >>>>>>> clean(). >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Looking at Cleaner .... >>>>>>> >>>>>>> >>>>>>> "Cleaner manages a set of object references and corresponding >>>>>>> cleaning >>>>>>> functions" >>>>>>> >>>>>>> I would say "cleaning actions" rather than functions as they yield no >>>>>>> value. This change needs to be made throughout. >>>>>>> >>>>>>> "The most efficient use is to explicitly invoke the clean method when >>>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>> >>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>> directly. I would rephrase: >>>>>>> >>>>>>> "In normal use a object should be cleaned up when no longer >>>>>>> required, by >>>>>>> invoking the clean() method of the associated Cleanable. This >>>>>>> guarantees >>>>>>> that the cleaning action will be performed at most once per object: >>>>>>> either explicitly, or automatically if it becomes phantom-reachable. >>>>>>> If >>>>>>> cleaned explicitly the object should not be used again. Note that the >>>>>>> cleaning action must not refer to the object ..." >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Question: what happens if an object is registered simultaneously with >>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>>>> never processed, or even touched - right? So really the thread is >>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>> >>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>> create/start threads. >>>>>>> >>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>> >>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>> ThreadFactory could throw anything) . >>>>>>>>> >>>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>>>> the >>>>>>>> Thread.State of the new thread >>>>>>>> and since it allows various attributes of the thread to be modified >>>>>>>> after the constructor. >>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>> started, >>>>>>>> why not. >>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>> >>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>>> >>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>> Did I miss some edge case? >>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> 127 * On each call the {@link >>>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>>> thread factory} >>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>>>> an appropriate >>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>>> loader}, >>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>> 132 * permissions, etc. >>>>>>>>> >>>>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>>>> can >>>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>>> Thread >>>>>>>>> that is suitable for performing the cleaning work". Though even >>>>>>>>> that >>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>>> needed >>>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>>> but I >>>>>>>>> don't think name or priority need to be discussed. >>>>>>>>> >>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>> threadFactory. >>>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>>> functions >>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>> client to >>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>> I agree that the phrase 'suitable for performing the cleaning work' >>>>>>>> is >>>>>>>> the operative one. >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> > From bechler at agno3.eu Tue Dec 8 23:15:24 2015 From: bechler at agno3.eu (Moritz Bechler) Date: Wed, 9 Dec 2015 00:15:24 +0100 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: Message-ID: <5667648C.3010501@agno3.eu> Hi, > Many threads created by the platform are short lived and perform some > simple async operation on behalf of the platform. These threads typically > use/extend sun.misc.ManagedLocalsThread. This is a convenient internal > API that can be used to create threads that do not wish to inherit initial > values from inheritable thread-local variables. > > I'd like to propose an additional java.lang.Thread constructor that exposes > the ability to explicitly "opt out" of inheriting these initial values ( from > inheritable thread-local variables ). This seems like useful general > functionality, given the amount of usage in the JDK of the internal API. > > This new public API can then be used to replace usages of the internal > sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted > the usage in the sources of the base module. Other modules can be done > as a follow up. > I can only very much second that request as I recently came across a library using lazy initialized thread pools in a very bad way. This usage currently unconditionally leaks the caller context and there is no good way (without knowing the internals and using reflection) to prevent that. As for the interface I would also prefer a more versatile approach as this could be further extended to specifying whether TCCL should be inherited and which ACC should be used (ok, that latter one is a bit tricky, but I'd guess an explicit API would make people more aware of the issue). Moritz -- AgNO3 GmbH & Co. KG, Sitz T?bingen, Amtsgericht Stuttgart HRA 728731 Pers?nlich haftend: Metagesellschaft mbH, Sitz T?bingen, Amtsgericht Stuttgart HRB 744820, Vertreten durch Joachim Keltsch From xueming.shen at oracle.com Wed Dec 9 00:40:20 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 8 Dec 2015 16:40:20 -0800 Subject: RFR JDK-8144958: changes by JDK-8142508 seems to have broken jtreg Message-ID: <56677874.9050401@oracle.com> Please help review the change for 8144958. issue: https://bugs.openjdk.java.net/browse/JDK-8144958 webrev: http://cr.openjdk.java.net/~sherman/8144958/ The changeset pushed this morning for 8142508 appears to trigger jtreg fail on some tests. --------------------------------------------------- Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev --------------------------------------------------- To avoid blocking the repository, the proposed changeset is to complete backout the change for 8142508 while investigating the direct cause. Thanks, Sherman From joe.darcy at oracle.com Wed Dec 9 00:42:19 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 08 Dec 2015 16:42:19 -0800 Subject: RFR JDK-8144958: changes by JDK-8142508 seems to have broken jtreg In-Reply-To: <56677874.9050401@oracle.com> References: <56677874.9050401@oracle.com> Message-ID: <566778EB.9010402@oracle.com> Approved to back out the earlier changeset while the investigation is underway. Thanks, -Joe On 12/8/2015 4:40 PM, Xueming Shen wrote: > Please help review the change for 8144958. > > issue: https://bugs.openjdk.java.net/browse/JDK-8144958 > webrev: http://cr.openjdk.java.net/~sherman/8144958/ > > The changeset pushed this morning for 8142508 appears to trigger > jtreg fail on some tests. > > --------------------------------------------------- > Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 > webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev > --------------------------------------------------- > > To avoid blocking the repository, the proposed changeset is to complete > backout the change for 8142508 while investigating the direct cause. > > Thanks, > Sherman From david.holmes at oracle.com Wed Dec 9 01:36:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 11:36:44 +1000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: Message-ID: <566785AC.1000007@oracle.com> Hi Chris, On 9/12/2015 12:15 AM, Chris Hegarty wrote: > Many threads created by the platform are short lived and perform some > simple async operation on behalf of the platform. These threads typically > use/extend sun.misc.ManagedLocalsThread. This is a convenient internal > API that can be used to create threads that do not wish to inherit initial > values from inheritable thread-local variables. > > I'd like to propose an additional java.lang.Thread constructor that exposes > the ability to explicitly "opt out" of inheriting these initial values ( from > inheritable thread-local variables ). This seems like useful general > functionality, given the amount of usage in the JDK of the internal API. > > This new public API can then be used to replace usages of the internal > sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted > the usage in the sources of the base module. Other modules can be done > as a follow up. > > Webrev: > http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ Addition to Thread looks good to me. I vote in favor of maintaining consistency of the existing Thread construction patterns. Builders or whatever can be added later as a separate RFE if considered desirable. I actually wasn't aware of the existing ManagedLocalsThread. Thanks, David > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8056152 > From ecki at zusammenkunft.net Wed Dec 9 01:37:52 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Wed, 9 Dec 2015 02:37:52 +0100 Subject: [rmi] supressStackTraces does not suppress suppressed exception Message-ID: Hello I noticed that RMI servers honor the sun.rmi.server.suppressStackTraces system property only for the `cause` member, but not for the suppressed exception array. This seems to be not documented (and is most likely not wanted?) It looks like it does also not handle SQLWarning#getNextWarning() chains, but I guess this is not expected. With suppressed remote stacks: java.lang.Exception: suppressor at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162) at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:217) at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:171) at com.sun.proxy.$Proxy0.test(Unknown Source) at testl.RMIS.main(RMIS.java:54) Suppressed: java.lang.RuntimeException: suppresed at testl.RMIS$RemoteObj.test(RMIS.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) at sun.rmi.transport.Transport$1.run(Transport.java:200) at sun.rmi.transport.Transport$1.run(Transport.java:197) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:196) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$255(TCPTransport.java:683) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/1626415735.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Greetings Bernd From stuart.marks at oracle.com Wed Dec 9 02:26:30 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 8 Dec 2015 18:26:30 -0800 Subject: [rmi] supressStackTraces does not suppress suppressed exception In-Reply-To: References: Message-ID: <56679156.7050709@oracle.com> Hi Bernd, How very interesting. Thanks for pointing this out. You're right, suppressStackTraces should probably also suppress the stack traces for suppressed exceptions. (Kind of funny given the names, but the word "suppress" is being used in two different senses here.) I've filed this bug to track the issue: https://bugs.openjdk.java.net/browse/JDK-8144968 I'm not sure if there's anything to be done about SQLWarning though. s'marks On 12/8/15 5:37 PM, ecki at zusammenkunft.net wrote: > Hello > > I noticed that RMI servers honor the sun.rmi.server.suppressStackTraces system property only for the > `cause` member, but not for the suppressed exception array. This seems to be not documented (and is most > likely not wanted?) > > It looks like it does also not handle SQLWarning#getNextWarning() chains, but I guess this is not expected. > > With suppressed remote stacks: > > java.lang.Exception: suppressor > at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276) > at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162) > at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:217) > at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:171) > at com.sun.proxy.$Proxy0.test(Unknown Source) > at testl.RMIS.main(RMIS.java:54) > Suppressed: java.lang.RuntimeException: suppresed > at testl.RMIS$RemoteObj.test(RMIS.java:33) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) > at sun.rmi.transport.Transport$1.run(Transport.java:200) > at sun.rmi.transport.Transport$1.run(Transport.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:196) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$255(TCPTransport.java:683) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/1626415735.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > Greetings > Bernd > From timo.kinnunen at gmail.com Wed Dec 9 02:52:18 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 9 Dec 2015 03:52:18 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> Message-ID: <56679768.6adec20a.6dc79.ffffcb48@mx.google.com> Hi, Not encouraging the use of lambdas won?t stop people discovering lambda usage for this on their own anyways, then writing blog posts about their discovery, promoting it, extolling its simplicity, encouraging others to use it too, etc? etc.. Let?s say I?ve forgotten about this issue and written some wrong/bad code like this: Utils.cleaning.register(this, () -> Arrays.stream(this.colors).forEach(Color::dispose)); Question(s): What is the failure mode that I would be seeing? And would it be immediately apparent that the code isn?t working properly, or how soon? -- Have a nice day, Timo Sent from Mail for Windows 10 From: Vitaly Davidovich Sent: Wednesday, December 9, 2015 00:09 To: Peter Levart Cc: core-libs-dev Subject: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization Can we enhance java to allow specifying lambda capture and how the value is captured? :) This is very subtle to the point where I maybe wouldn't even encourage use of lambda in this context. sent from my phone On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > On 12/08/2015 08:08 PM, Steven Schlansker wrote: > >> On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: >> >>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>> >>>> private final Cleaner.Cleanable cleanable = >>>> cleaner.register(this, () -> fd.close()); >>>> >>> Sorry Roger, but this example is flawed. This is tricky! The lambda "() >>> -> fd.close()" captures 'this', not only 'fd' as can be seen by running the >>> following example: >>> To correct that, but still use lambda, you would have to capture a local >>> variable >>> >> It looks like using "fd::close" might also work, and is more concise: >> >> IntSupplier x = () -> 10; >> IntSupplier xS = x::getAsInt; >> >> @Test >> public void test() { >> System.out.println(xS.getAsInt()); >> x = () -> 15; >> System.out.println(xS.getAsInt()); >> } >> >> 10 >> 10 >> > > Yes, good idea. This is a pre-bound method reference (the part on the left > of '::' is evaluated immediately). Contrast to lambda, where "fd.close()" > is an expression in the lambda body which is evaluated when lambda is > invoked and that expression is composed of a field get + method invocation. > In order to get an instance field, the object containing it must be > captured. > > So for Roger's example, this will work: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = cleaner.register(this, > fd::close); > > @Override > public void close() { > cleanable.clean(); > } > } > > > ...if FileDescriptor.close() is an instance method with no arguments and > doesn't throw any checked exceptions. > > > Regards, Peter > > >> I'll work the example into the javadoc. >>>> >>>> Roger >>>> >>>> >>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>> >>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>> >>>>>> Actually I'm having more doubts about this API. >>>>>> >>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>> library writer I would think I am now expected to register my >>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>> finalize() would have done. But in that usage pattern the end user of >>>>>> my objects never has any access to my Cleanables so can never call >>>>>> clean() themselves - instead they should be calling the cleanup >>>>>> function directly, just as they would previously. So the whole "invoke >>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>> the way we should write the cleanup method and the Runnable need to be >>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>> implementation. >>>>>> >>>>>> David >>>>>> >>>>> Hi David, (once again for the list) >>>>> >>>>> I agree that an example would be most helpful. Here's how a normal >>>>> finalizable object is typically coded: >>>>> >>>>> public class FinalizeExample implements AutoCloseable { >>>>> >>>>> private boolean closed; >>>>> >>>>> @Override >>>>> public synchronized void close() { >>>>> if (!closed) { >>>>> closed = true; >>>>> // cleanup actions accessing state of FinalizeExample, >>>>> executed at most once >>>>> } >>>>> } >>>>> >>>>> @Override >>>>> protected void finalize() throws Throwable { >>>>> close(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Re-factoring to use Cleaner is a process that extracts the state >>>>> representing native resource from the user-facing class into a private >>>>> nested static class and makes the user-facing object just a facade that has >>>>> access to the state object and is registered with a Cleaner. The >>>>> Cleaner.Cleanable instance is also made accessible from the user-facing >>>>> object, so it can provide the on-demand cleaning: >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static class State implements Runnable { >>>>> @Override >>>>> public void run() { >>>>> // cleanup actions accessing State, executed at most >>>>> once >>>>> } >>>>> } >>>>> >>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>> >>>>> private final State state = new State(); >>>>> private final Cleaner.Cleanable cleanable = >>>>> cleaner.register(this, state); >>>>> >>>>> @Override >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>>> apologies >>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>> details of the implementation. >>>>>>> >>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for the comments, >>>>>>>> >>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>>> >>>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>>> package-doc >>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>>> part of >>>>>>> the core reference related functionality. Perhaps even state how they >>>>>>> are preferred to use of finalization? >>>>>>> >>>>>>> Cleaner.Cleanable: >>>>>>> >>>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>>> that the intent is that rather than register a "thunk" (lets call it >>>>>>> an >>>>>>> "action") that can be invoked directly by user-code, the user should >>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>> should be explained somewhat more clearly - see below. >>>>>>> >>>>>>> I would describe the Cleanable class as: >>>>>>> >>>>>>> Cleanable: Represents an object that has been registered for cleanup >>>>>>> by >>>>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), >>>>>>> if >>>>>>> it is no longer to be used, else it will be cleaned automatically >>>>>>> when >>>>>>> the object becomes phantom-reachable. >>>>>>> >>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>>> action that was associated with it. If this Cleanable has already >>>>>>> been >>>>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>>>> once >>>>>>> per registered Cleanable, regardless of the number of calls to >>>>>>> clean(). >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Looking at Cleaner .... >>>>>>> >>>>>>> >>>>>>> "Cleaner manages a set of object references and corresponding >>>>>>> cleaning >>>>>>> functions" >>>>>>> >>>>>>> I would say "cleaning actions" rather than functions as they yield no >>>>>>> value. This change needs to be made throughout. >>>>>>> >>>>>>> "The most efficient use is to explicitly invoke the clean method when >>>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>> >>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>> directly. I would rephrase: >>>>>>> >>>>>>> "In normal use a object should be cleaned up when no longer >>>>>>> required, by >>>>>>> invoking the clean() method of the associated Cleanable. This >>>>>>> guarantees >>>>>>> that the cleaning action will be performed at most once per object: >>>>>>> either explicitly, or automatically if it becomes phantom-reachable. >>>>>>> If >>>>>>> cleaned explicitly the object should not be used again. Note that the >>>>>>> cleaning action must not refer to the object ..." >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Question: what happens if an object is registered simultaneously with >>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>> functions" doesn't quite seem right to me. The objects themselves are >>>>>>> never processed, or even touched - right? So really the thread is >>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>> >>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>> create/start threads. >>>>>>> >>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>> >>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>> unstarted threads - that is what a new Thread is - so I don't think >>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>> ThreadFactory could throw anything) . >>>>>>>>> >>>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>>>> the >>>>>>>> Thread.State of the new thread >>>>>>>> and since it allows various attributes of the thread to be modified >>>>>>>> after the constructor. >>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>> started, >>>>>>>> why not. >>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>> >>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>>> >>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>> Did I miss some edge case? >>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> 127 * On each call the {@link >>>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>>> thread factory} >>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with >>>>>>>>> an appropriate >>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>>> loader}, >>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>> 132 * permissions, etc. >>>>>>>>> >>>>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>>>> can >>>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>>> Thread >>>>>>>>> that is suitable for performing the cleaning work". Though even >>>>>>>>> that >>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>>> needed >>>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>>> but I >>>>>>>>> don't think name or priority need to be discussed. >>>>>>>>> >>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>> threadFactory. >>>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>>> functions >>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>> client to >>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>> I agree that the phrase 'suitable for performing the cleaning work' >>>>>>>> is >>>>>>>> the operative one. >>>>>>>> >>>>>>>> Thanks, Roger >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> > From vitalyd at gmail.com Wed Dec 9 03:04:44 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Dec 2015 22:04:44 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization In-Reply-To: <56679768.6adec20a.6dc79.ffffcb48@mx.google.com> References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <56679768.6adec20a.6dc79.ffffcb48@mx.google.com> Message-ID: sent from my phone On Dec 8, 2015 9:52 PM, "Timo Kinnunen" wrote: > > Hi, > > > > Not encouraging the use of lambdas won?t stop people discovering lambda usage for this on their own anyways, then writing blog posts about their discovery, promoting it, extolling its simplicity, encouraging others to use it too, etc? etc.. I know I know :). > > > > Let?s say I?ve forgotten about this issue and written some wrong/bad code like this: > > > > Utils.cleaning.register(this, () -> Arrays.stream(this.colors).forEach(Color::dispose)); > > > > > > Question(s): What is the failure mode that I would be seeing? And would it be immediately apparent that the code isn?t working properly, or how soon? You leak the object in the sense that it won't become unreachable to begin with. It's subtle and likely to not be easily detected. > > > > > -- > Have a nice day, > Timo > > Sent from Mail for Windows 10 > > > > > > > From: Vitaly Davidovich > Sent: Wednesday, December 9, 2015 00:09 > To: Peter Levart > Cc: core-libs-dev > Subject: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to usealternative to finalization > > > > > > Can we enhance java to allow specifying lambda capture and how the value is > > captured? :) > > > > This is very subtle to the point where I maybe wouldn't even encourage use > > of lambda in this context. > > > > sent from my phone > > On Dec 8, 2015 4:25 PM, "Peter Levart" wrote: > > > > > > > > > > > On 12/08/2015 08:08 PM, Steven Schlansker wrote: > > > > > >> On Dec 8, 2015, at 10:51 AM, Peter Levart wrote: > > >> > > >>> On 12/08/2015 04:34 PM, Roger Riggs wrote: > > >>> > > >>>> private final Cleaner.Cleanable cleanable = > > >>>> cleaner.register(this, () -> fd.close()); > > >>>> > > >>> Sorry Roger, but this example is flawed. This is tricky! The lambda "() > > >>> -> fd.close()" captures 'this', not only 'fd' as can be seen by running the > > >>> following example: > > >>> To correct that, but still use lambda, you would have to capture a local > > >>> variable > > >>> > > >> It looks like using "fd::close" might also work, and is more concise: > > >> > > >> IntSupplier x = () -> 10; > > >> IntSupplier xS = x::getAsInt; > > >> > > >> @Test > > >> public void test() { > > >> System.out.println(xS.getAsInt()); > > >> x = () -> 15; > > >> System.out.println(xS.getAsInt()); > > >> } > > >> > > >> 10 > > >> 10 > > >> > > > > > > Yes, good idea. This is a pre-bound method reference (the part on the left > > > of '::' is evaluated immediately). Contrast to lambda, where "fd.close()" > > > is an expression in the lambda body which is evaluated when lambda is > > > invoked and that expression is composed of a field get + method invocation. > > > In order to get an instance field, the object containing it must be > > > captured. > > > > > > So for Roger's example, this will work: > > > > > > > > > public static class CleanerExample implements AutoCloseable { > > > > > > FileDescriptor fd = ...; > > > > > > private static final Cleaner cleaner = Cleaner.create(); > > > > > > private final Cleaner.Cleanable cleanable = cleaner.register(this, > > > fd::close); > > > > > > @Override > > > public void close() { > > > cleanable.clean(); > > > } > > > } > > > > > > > > > ...if FileDescriptor.close() is an instance method with no arguments and > > > doesn't throw any checked exceptions. > > > > > > > > > Regards, Peter > > > > > > > > >> I'll work the example into the javadoc. > > >>>> > > >>>> Roger > > >>>> > > >>>> > > >>>> On 12/08/2015 07:25 AM, Peter Levart wrote: > > >>>> > > >>>>> On 12/08/2015 09:22 AM, David Holmes wrote: > > >>>>> > > >>>>>> Actually I'm having more doubts about this API. > > >>>>>> > > >>>>>> Library writers use finalize() as a last ditch cleanup mechanism in > > >>>>>> case the user doesn't explicitly call any "cleanup" method. So as a > > >>>>>> library writer I would think I am now expected to register my > > >>>>>> instances with a Cleaner and provide a Runnable that does what > > >>>>>> finalize() would have done. But in that usage pattern the end user of > > >>>>>> my objects never has any access to my Cleanables so can never call > > >>>>>> clean() themselves - instead they should be calling the cleanup > > >>>>>> function directly, just as they would previously. So the whole "invoke > > >>>>>> at most once" for the clean() method seems somewhat unnecessary; and > > >>>>>> the way we should write the cleanup method and the Runnable need to be > > >>>>>> more cleary explained as the idempotentcy of the cleanup needs to be > > >>>>>> handled in the library writers code not the Cleaner/Clenable > > >>>>>> implementation. > > >>>>>> > > >>>>>> David > > >>>>>> > > >>>>> Hi David, (once again for the list) > > >>>>> > > >>>>> I agree that an example would be most helpful. Here's how a normal > > >>>>> finalizable object is typically coded: > > >>>>> > > >>>>> public class FinalizeExample implements AutoCloseable { > > >>>>> > > >>>>> private boolean closed; > > >>>>> > > >>>>> @Override > > >>>>> public synchronized void close() { > > >>>>> if (!closed) { > > >>>>> closed = true; > > >>>>> // cleanup actions accessing state of FinalizeExample, > > >>>>> executed at most once > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> @Override > > >>>>> protected void finalize() throws Throwable { > > >>>>> close(); > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> > > >>>>> Re-factoring to use Cleaner is a process that extracts the state > > >>>>> representing native resource from the user-facing class into a private > > >>>>> nested static class and makes the user-facing object just a facade that has > > >>>>> access to the state object and is registered with a Cleaner. The > > >>>>> Cleaner.Cleanable instance is also made accessible from the user-facing > > >>>>> object, so it can provide the on-demand cleaning: > > >>>>> > > >>>>> public static class CleanerExample implements AutoCloseable { > > >>>>> > > >>>>> private static class State implements Runnable { > > >>>>> @Override > > >>>>> public void run() { > > >>>>> // cleanup actions accessing State, executed at most > > >>>>> once > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> private static final Cleaner cleaner = Cleaner.create(); > > >>>>> > > >>>>> private final State state = new State(); > > >>>>> private final Cleaner.Cleanable cleanable = > > >>>>> cleaner.register(this, state); > > >>>>> > > >>>>> @Override > > >>>>> public void close() { > > >>>>> cleanable.clean(); > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> > > >>>>> Regards, Peter > > >>>>> > > >>>>> On 8/12/2015 6:09 PM, David Holmes wrote: > > >>>>>> > > >>>>>>> Hi Roger, > > >>>>>>> > > >>>>>>> Sorry I had no choice but to look at this more closely ... and > > >>>>>>> apologies > > >>>>>>> as this is very late feedback ... I only looked at the API not the > > >>>>>>> details of the implementation. > > >>>>>>> > > >>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: > > >>>>>>> > > >>>>>>>> Hi David, > > >>>>>>>> > > >>>>>>>> Thanks for the comments, > > >>>>>>>> > > >>>>>>>> Updated the javadoc and webrev with editorial changes. > > >>>>>>>> > > >>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > >>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > >>>>>>>> > > >>>>>>> Should cleaning and cleanables be mentioned as part of the > > >>>>>>> package-doc > > >>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not > > >>>>>>> part of > > >>>>>>> the core reference related functionality. Perhaps even state how they > > >>>>>>> are preferred to use of finalization? > > >>>>>>> > > >>>>>>> Cleaner.Cleanable: > > >>>>>>> > > >>>>>>> It was unclear to me what the usage model was for this. I'm assuming > > >>>>>>> that the intent is that rather than register a "thunk" (lets call it > > >>>>>>> an > > >>>>>>> "action") that can be invoked directly by user-code, the user should > > >>>>>>> invoke the action via the call to clean(). In which case I think it > > >>>>>>> should be explained somewhat more clearly - see below. > > >>>>>>> > > >>>>>>> I would describe the Cleanable class as: > > >>>>>>> > > >>>>>>> Cleanable: Represents an object that has been registered for cleanup > > >>>>>>> by > > >>>>>>> a Cleaner. The object can be cleaned directly, by a call to clean(), > > >>>>>>> if > > >>>>>>> it is no longer to be used, else it will be cleaned automatically > > >>>>>>> when > > >>>>>>> the object becomes phantom-reachable. > > >>>>>>> > > >>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup > > >>>>>>> action that was associated with it. If this Cleanable has already > > >>>>>>> been > > >>>>>>> unregistered nothing happens. The cleanup action is invoked at most > > >>>>>>> once > > >>>>>>> per registered Cleanable, regardless of the number of calls to > > >>>>>>> clean(). > > >>>>>>> > > >>>>>>> --- > > >>>>>>> > > >>>>>>> Looking at Cleaner .... > > >>>>>>> > > >>>>>>> > > >>>>>>> "Cleaner manages a set of object references and corresponding > > >>>>>>> cleaning > > >>>>>>> functions" > > >>>>>>> > > >>>>>>> I would say "cleaning actions" rather than functions as they yield no > > >>>>>>> value. This change needs to be made throughout. > > >>>>>>> > > >>>>>>> "The most efficient use is to explicitly invoke the clean method when > > >>>>>>> the object is closed or no longer needed. The cleaning function is a > > >>>>>>> Runnable to be invoked at most once when the object is no longer > > >>>>>>> reachable unless it has already been explicitly cleaned." > > >>>>>>> > > >>>>>>> To me this doesn't quite capture the need to not use the Runnable > > >>>>>>> directly. I would rephrase: > > >>>>>>> > > >>>>>>> "In normal use a object should be cleaned up when no longer > > >>>>>>> required, by > > >>>>>>> invoking the clean() method of the associated Cleanable. This > > >>>>>>> guarantees > > >>>>>>> that the cleaning action will be performed at most once per object: > > >>>>>>> either explicitly, or automatically if it becomes phantom-reachable. > > >>>>>>> If > > >>>>>>> cleaned explicitly the object should not be used again. Note that the > > >>>>>>> cleaning action must not refer to the object ..." > > >>>>>>> > > >>>>>>> --- > > >>>>>>> > > >>>>>>> Question: what happens if an object is registered simultaneously with > > >>>>>>> multiple Cleaners? Do we need to warn the user against that? > > >>>>>>> > > >>>>>>> --- > > >>>>>>> > > >>>>>>> The phrase "process the unreachable objects and to invoke cleaning > > >>>>>>> functions" doesn't quite seem right to me. The objects themselves are > > >>>>>>> never processed, or even touched - right? So really the thread is > > >>>>>>> started to "invoke the cleanup actions for unreachable objects". > > >>>>>>> > > >>>>>>> create(): can also throw SecurityException if not allowed to > > >>>>>>> create/start threads. > > >>>>>>> > > >>>>>>> register(Object obj, Runnable thunk): thunk -> action > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> David > > >>>>>>> > > >>>>>>> > > >>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: > > >>>>>>>> > > >>>>>>>>> Hi Roger, > > >>>>>>>>> > > >>>>>>>>> Sorry to be late here but was trying not to get involved :) > > >>>>>>>>> > > >>>>>>>>> It is already implicit that ThreadFactory.newThread should return > > >>>>>>>>> unstarted threads - that is what a new Thread is - so I don't think > > >>>>>>>>> IllegalThreadStateException needs to be documented here as it is > > >>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken > > >>>>>>>>> ThreadFactory could throw anything) . > > >>>>>>>>> > > >>>>>>>> It does seem that new is fairly well understood but one can read of > > >>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to > > >>>>>>>> the > > >>>>>>>> Thread.State of the new thread > > >>>>>>>> and since it allows various attributes of the thread to be modified > > >>>>>>>> after the constructor. > > >>>>>>>> Since the runnable is supplied as an argument it is ready to be > > >>>>>>>> started, > > >>>>>>>> why not. > > >>>>>>>> It seemed useful to reinforce the salient points. > > >>>>>>>> > > >>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. > > >>>>>>>>> > > >>>>>>>> The thread construction is done in doPriv so it should not throw. > > >>>>>>>> Did I miss some edge case? > > >>>>>>>> > > >>>>>>>>> Also this: > > >>>>>>>>> > > >>>>>>>>> 127 * On each call the {@link > > >>>>>>>>> ThreadFactory#newThread(Runnable) > > >>>>>>>>> thread factory} > > >>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} with > > >>>>>>>>> an appropriate > > >>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class > > >>>>>>>>> loader}, > > >>>>>>>>> 130 * {@linkplain Thread#getName() name}, > > >>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, > > >>>>>>>>> 132 * permissions, etc. > > >>>>>>>>> > > >>>>>>>>> then begs the questions as to what is "appropriate". I think this > > >>>>>>>>> can > > >>>>>>>>> be said much more simply as: "The ThreadFactory must provide a > > >>>>>>>>> Thread > > >>>>>>>>> that is suitable for performing the cleaning work". Though even > > >>>>>>>>> that > > >>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually > > >>>>>>>>> needed > > >>>>>>>>> here ?? Special security context? If so that could be mentioned, > > >>>>>>>>> but I > > >>>>>>>>> don't think name or priority need to be discussed. > > >>>>>>>>> > > >>>>>>>> It was intended to prod the client to be deliberate about the > > >>>>>>>> threadFactory. > > >>>>>>>> Since the client is integrating the Cleaner and respective cleaning > > >>>>>>>> functions > > >>>>>>>> with the client code, the ThreadFactory makes it possible for the > > >>>>>>>> client to > > >>>>>>>> initialize a suitable thread and the comments serve as a reminder. > > >>>>>>>> I agree that the phrase 'suitable for performing the cleaning work' > > >>>>>>>> is > > >>>>>>>> the operative one. > > >>>>>>>> > > >>>>>>>> Thanks, Roger > > >>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> David > > >>>>>>>>> > > >>>>>>>>> > > > > > > > From vitalyd at gmail.com Wed Dec 9 04:15:37 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Dec 2015 23:15:37 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566754C4.4060308@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> Message-ID: This has the same problem, doesn't it? The bottom line is if the lambda is () -> you're getting a capture of `this`. On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs wrote: > Hi, > > Another option that should always capture is to define a specific static > method with the needed values as arguments: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = > cleaner.register(this,*() -> cleanup(fd)*); > > @Override > public void close() { > cleanable.clean(); > } > > *static void cleanup(FileDescriptor fd ...) {** > ** fd.close();** > ** }* > > } > > On 12/8/2015 4:24 PM, Peter Levart wrote: > >> >> >> On 12/08/2015 08:08 PM, Steven Schlansker wrote: >> >>> On Dec 8, 2015, at 10:51 AM, Peter Levart >>> wrote: >>> >>>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>>> >>>>> private final Cleaner.Cleanable cleanable = >>>>> cleaner.register(this, () -> fd.close()); >>>>> >>>> Sorry Roger, but this example is flawed. This is tricky! The lambda "() >>>> -> fd.close()" captures 'this', not only 'fd' as can be seen by running the >>>> following example: >>>> To correct that, but still use lambda, you would have to capture a >>>> local variable >>>> >>> It looks like using "fd::close" might also work, and is more concise: >>> >>> IntSupplier x = () -> 10; >>> IntSupplier xS = x::getAsInt; >>> >>> @Test >>> public void test() { >>> System.out.println(xS.getAsInt()); >>> x = () -> 15; >>> System.out.println(xS.getAsInt()); >>> } >>> >>> 10 >>> 10 >>> >> >> Yes, good idea. This is a pre-bound method reference (the part on the >> left of '::' is evaluated immediately). Contrast to lambda, where >> "fd.close()" is an expression in the lambda body which is evaluated when >> lambda is invoked and that expression is composed of a field get + method >> invocation. In order to get an instance field, the object containing it >> must be captured. >> >> So for Roger's example, this will work: >> >> >> public static class CleanerExample implements AutoCloseable { >> >> FileDescriptor fd = ...; >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this, fd::close); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } >> >> >> ...if FileDescriptor.close() is an instance method with no arguments and >> doesn't throw any checked exceptions. >> >> >> Regards, Peter >> >> I'll work the example into the javadoc. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>>> >>>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>>> >>>>>>> Actually I'm having more doubts about this API. >>>>>>> >>>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>>> library writer I would think I am now expected to register my >>>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>>> finalize() would have done. But in that usage pattern the end user of >>>>>>> my objects never has any access to my Cleanables so can never call >>>>>>> clean() themselves - instead they should be calling the cleanup >>>>>>> function directly, just as they would previously. So the whole >>>>>>> "invoke >>>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>>> the way we should write the cleanup method and the Runnable need to >>>>>>> be >>>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>>> implementation. >>>>>>> >>>>>>> David >>>>>>> >>>>>> Hi David, (once again for the list) >>>>>> >>>>>> I agree that an example would be most helpful. Here's how a normal >>>>>> finalizable object is typically coded: >>>>>> >>>>>> public class FinalizeExample implements AutoCloseable { >>>>>> >>>>>> private boolean closed; >>>>>> >>>>>> @Override >>>>>> public synchronized void close() { >>>>>> if (!closed) { >>>>>> closed = true; >>>>>> // cleanup actions accessing state of >>>>>> FinalizeExample, executed at most once >>>>>> } >>>>>> } >>>>>> >>>>>> @Override >>>>>> protected void finalize() throws Throwable { >>>>>> close(); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> Re-factoring to use Cleaner is a process that extracts the state >>>>>> representing native resource from the user-facing class into a private >>>>>> nested static class and makes the user-facing object just a facade that has >>>>>> access to the state object and is registered with a Cleaner. The >>>>>> Cleaner.Cleanable instance is also made accessible from the user-facing >>>>>> object, so it can provide the on-demand cleaning: >>>>>> >>>>>> public static class CleanerExample implements AutoCloseable { >>>>>> >>>>>> private static class State implements Runnable { >>>>>> @Override >>>>>> public void run() { >>>>>> // cleanup actions accessing State, executed at most >>>>>> once >>>>>> } >>>>>> } >>>>>> >>>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>>> >>>>>> private final State state = new State(); >>>>>> private final Cleaner.Cleanable cleanable = >>>>>> cleaner.register(this, state); >>>>>> >>>>>> @Override >>>>>> public void close() { >>>>>> cleanable.clean(); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>>> >>>>>>>> Hi Roger, >>>>>>>> >>>>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>>>> apologies >>>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>>> details of the implementation. >>>>>>>> >>>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thanks for the comments, >>>>>>>>> >>>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>>> >>>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>>>> >>>>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>>>> package-doc >>>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>>>> part of >>>>>>>> the core reference related functionality. Perhaps even state how >>>>>>>> they >>>>>>>> are preferred to use of finalization? >>>>>>>> >>>>>>>> Cleaner.Cleanable: >>>>>>>> >>>>>>>> It was unclear to me what the usage model was for this. I'm assuming >>>>>>>> that the intent is that rather than register a "thunk" (lets call >>>>>>>> it an >>>>>>>> "action") that can be invoked directly by user-code, the user should >>>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>>> should be explained somewhat more clearly - see below. >>>>>>>> >>>>>>>> I would describe the Cleanable class as: >>>>>>>> >>>>>>>> Cleanable: Represents an object that has been registered for >>>>>>>> cleanup by >>>>>>>> a Cleaner. The object can be cleaned directly, by a call to >>>>>>>> clean(), if >>>>>>>> it is no longer to be used, else it will be cleaned automatically >>>>>>>> when >>>>>>>> the object becomes phantom-reachable. >>>>>>>> >>>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the cleanup >>>>>>>> action that was associated with it. If this Cleanable has already >>>>>>>> been >>>>>>>> unregistered nothing happens. The cleanup action is invoked at most >>>>>>>> once >>>>>>>> per registered Cleanable, regardless of the number of calls to >>>>>>>> clean(). >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Looking at Cleaner .... >>>>>>>> >>>>>>>> >>>>>>>> "Cleaner manages a set of object references and corresponding >>>>>>>> cleaning >>>>>>>> functions" >>>>>>>> >>>>>>>> I would say "cleaning actions" rather than functions as they yield >>>>>>>> no >>>>>>>> value. This change needs to be made throughout. >>>>>>>> >>>>>>>> "The most efficient use is to explicitly invoke the clean method >>>>>>>> when >>>>>>>> the object is closed or no longer needed. The cleaning function is a >>>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>>> >>>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>>> directly. I would rephrase: >>>>>>>> >>>>>>>> "In normal use a object should be cleaned up when no longer >>>>>>>> required, by >>>>>>>> invoking the clean() method of the associated Cleanable. This >>>>>>>> guarantees >>>>>>>> that the cleaning action will be performed at most once per object: >>>>>>>> either explicitly, or automatically if it becomes >>>>>>>> phantom-reachable. If >>>>>>>> cleaned explicitly the object should not be used again. Note that >>>>>>>> the >>>>>>>> cleaning action must not refer to the object ..." >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Question: what happens if an object is registered simultaneously >>>>>>>> with >>>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>>> functions" doesn't quite seem right to me. The objects themselves >>>>>>>> are >>>>>>>> never processed, or even touched - right? So really the thread is >>>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>>> >>>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>>> create/start threads. >>>>>>>> >>>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>>> Hi Roger, >>>>>>>>>> >>>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>>> >>>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>>> unstarted threads - that is what a new Thread is - so I don't >>>>>>>>>> think >>>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>>> ThreadFactory could throw anything) . >>>>>>>>>> >>>>>>>>> It does seem that new is fairly well understood but one can read of >>>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference to >>>>>>>>> the >>>>>>>>> Thread.State of the new thread >>>>>>>>> and since it allows various attributes of the thread to be modified >>>>>>>>> after the constructor. >>>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>>> started, >>>>>>>>> why not. >>>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>>> >>>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>>>> >>>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>>> Did I miss some edge case? >>>>>>>>> >>>>>>>>>> Also this: >>>>>>>>>> >>>>>>>>>> 127 * On each call the {@link >>>>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>>>> thread factory} >>>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} >>>>>>>>>> with >>>>>>>>>> an appropriate >>>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>>>> loader}, >>>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>>> 132 * permissions, etc. >>>>>>>>>> >>>>>>>>>> then begs the questions as to what is "appropriate". I think this >>>>>>>>>> can >>>>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>>>> Thread >>>>>>>>>> that is suitable for performing the cleaning work". Though even >>>>>>>>>> that >>>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>>>> needed >>>>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>>>> but I >>>>>>>>>> don't think name or priority need to be discussed. >>>>>>>>>> >>>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>>> threadFactory. >>>>>>>>> Since the client is integrating the Cleaner and respective cleaning >>>>>>>>> functions >>>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>>> client to >>>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>>> I agree that the phrase 'suitable for performing the cleaning >>>>>>>>> work' is >>>>>>>>> the operative one. >>>>>>>>> >>>>>>>>> Thanks, Roger >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >> > From run2000 at gmail.com Wed Dec 9 06:17:57 2015 From: run2000 at gmail.com (Nicholas Cull) Date: Wed, 9 Dec 2015 17:17:57 +1100 Subject: Potential performance improvement for java.util.AbstractList? Message-ID: Mon Dec 7 15:31:56 UTC 2015 C?dric Champeau : > I assume one reason it's done this way is that depending on the list > implementation you are using, getting the size might involve iterating over > all elements, so you would be iterating twice at worst case. If calling size() was a non-trivial operation for AbstractList, it would already be a problem for its listIterator(int) and the internal Iterator implementations, which both call size(), and in turn are used by the provided equals() method. I had a quick look at the JDK code base to see what happens in practice. All implementations I could find had a constant time lookup for size(). Looking at a more broad code base, the only example that wasn't guaranteed constant time was in a Groovy class, which performs a lazy evaluation of size(), resulting in constant amortized time. Tue Dec 8 12:17:17 UTC 2015 Vitaly Davidovich : > Which also begs the question of why not override this in subclasses that > have fast size(). Yes there may be some duplication but it's "simple" > duplication >From all the code I looked at in the JDK, few of the subclasses of AbstractList override the equals() method, and all have constant time size(). If this check is to be duplicated, it would be duplication over many classes. Yes, the time performance of size() appears to be unspecified by the whole Collections framework: the implementation of equals() in AbstractSet uses size() as an optimization, though AbstractCollection does not. Naively it seems odd that we don't perform this check inside AbstractList. What contract is AbstractList implying that would be broken by doing so? Regards, Nicholas. From peter.levart at gmail.com Wed Dec 9 07:05:32 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Dec 2015 08:05:32 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> Message-ID: <5667D2BC.2030505@gmail.com> Hi, I think the only way to try to prevent such things is with a good example in javadoc that "screams" of possible miss-usages. public static class CleanerExample implements AutoCloseable { private static final Cleaner cleaner = ...; // preferably a shared cleaner private final PrivateNativeResource pnr; private final Cleaner.Cleanable cleanable; public CleanerExample(args, ...) { // prepare captured state as local vars... PrivateNativeResource _pnr = ...; this.cleanable = cleaner.register(this, () -> { // DON'T capture any instance fields with lambda since that would // capture 'this' and prevent it from becoming phantom-reachable!!! _pnr.close(); }); this.pnr = _pnr; } public void close() { cleanable.clean(); } Regards, Peter On 12/09/2015 05:15 AM, Vitaly Davidovich wrote: > This has the same problem, doesn't it? The bottom line is if the > lambda is () -> you're getting a > capture of `this`. > > On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs > wrote: > > Hi, > > Another option that should always capture is to define a specific > static method with the needed values as arguments: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = > cleaner.register(this,*() -> cleanup(fd)*); > > @Override > public void close() { > cleanable.clean(); > } > > *static void cleanup(FileDescriptor fd ...) {** > ** fd.close();** > ** }* > > } > > On 12/8/2015 4:24 PM, Peter Levart wrote: > > > > On 12/08/2015 08:08 PM, Steven Schlansker wrote: > > On Dec 8, 2015, at 10:51 AM, Peter > Levart > wrote: > > On 12/08/2015 04:34 PM, Roger Riggs wrote: > > private final Cleaner.Cleanable cleanable > = cleaner.register(this, () -> fd.close()); > > Sorry Roger, but this example is flawed. This is > tricky! The lambda "() -> fd.close()" captures 'this', > not only 'fd' as can be seen by running the following > example: > To correct that, but still use lambda, you would have > to capture a local variable > > It looks like using "fd::close" might also work, and is > more concise: > > IntSupplier x = () -> 10; > IntSupplier xS = x::getAsInt; > > @Test > public void test() { > System.out.println(xS.getAsInt()); > x = () -> 15; > System.out.println(xS.getAsInt()); > } > > 10 > 10 > > > Yes, good idea. This is a pre-bound method reference (the part > on the left of '::' is evaluated immediately). Contrast to > lambda, where "fd.close()" is an expression in the lambda body > which is evaluated when lambda is invoked and that expression > is composed of a field get + method invocation. In order to > get an instance field, the object containing it must be captured. > > So for Roger's example, this will work: > > > public static class CleanerExample implements AutoCloseable { > > FileDescriptor fd = ...; > > private static final Cleaner cleaner = Cleaner.create(); > > private final Cleaner.Cleanable cleanable = > cleaner.register(this, fd::close); > > @Override > public void close() { > cleanable.clean(); > } > } > > > ...if FileDescriptor.close() is an instance method with no > arguments and doesn't throw any checked exceptions. > > > Regards, Peter > > I'll work the example into the javadoc. > > Roger > > > On 12/08/2015 07:25 AM, Peter Levart wrote: > > On 12/08/2015 09:22 AM, David Holmes wrote: > > Actually I'm having more doubts about this > API. > > Library writers use finalize() as a last > ditch cleanup mechanism in > case the user doesn't explicitly call any > "cleanup" method. So as a > library writer I would think I am now > expected to register my > instances with a Cleaner and provide a > Runnable that does what > finalize() would have done. But in that > usage pattern the end user of > my objects never has any access to my > Cleanables so can never call > clean() themselves - instead they should > be calling the cleanup > function directly, just as they would > previously. So the whole "invoke > at most once" for the clean() method seems > somewhat unnecessary; and > the way we should write the cleanup method > and the Runnable need to be > more cleary explained as the idempotentcy > of the cleanup needs to be > handled in the library writers code not > the Cleaner/Clenable > implementation. > > David > > Hi David, (once again for the list) > > I agree that an example would be most helpful. > Here's how a normal finalizable object is > typically coded: > > public class FinalizeExample implements > AutoCloseable { > > private boolean closed; > > @Override > public synchronized void close() { > if (!closed) { > closed = true; > // cleanup actions accessing > state of FinalizeExample, executed at most once > } > } > > @Override > protected void finalize() throws > Throwable { > close(); > } > } > > > Re-factoring to use Cleaner is a process that > extracts the state representing native > resource from the user-facing class into a > private nested static class and makes the > user-facing object just a facade that has > access to the state object and is registered > with a Cleaner. The Cleaner.Cleanable instance > is also made accessible from the user-facing > object, so it can provide the on-demand cleaning: > > public static class CleanerExample > implements AutoCloseable { > > private static class State implements > Runnable { > @Override > public void run() { > // cleanup actions accessing > State, executed at most once > } > } > > private static final Cleaner cleaner = > Cleaner.create(); > > private final State state = new State(); > private final Cleaner.Cleanable > cleanable = cleaner.register(this, state); > > @Override > public void close() { > cleanable.clean(); > } > } > > > Regards, Peter > > On 8/12/2015 6:09 PM, David Holmes wrote: > > Hi Roger, > > Sorry I had no choice but to look at > this more closely ... and apologies > as this is very late feedback ... I > only looked at the API not the > details of the implementation. > > On 8/12/2015 4:50 AM, Roger Riggs wrote: > > Hi David, > > Thanks for the comments, > > Updated the javadoc and webrev > with editorial changes. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > > Should cleaning and cleanables be > mentioned as part of the package-doc > for java.lang.ref? Else they seem to > be an overlooked add-on not part of > the core reference related > functionality. Perhaps even state how they > are preferred to use of finalization? > > Cleaner.Cleanable: > > It was unclear to me what the usage > model was for this. I'm assuming > that the intent is that rather than > register a "thunk" (lets call it an > "action") that can be invoked directly > by user-code, the user should > invoke the action via the call to > clean(). In which case I think it > should be explained somewhat more > clearly - see below. > > I would describe the Cleanable class as: > > Cleanable: Represents an object that > has been registered for cleanup by > a Cleaner. The object can be cleaned > directly, by a call to clean(), if > it is no longer to be used, else it > will be cleaned automatically when > the object becomes phantom-reachable. > > Cleanable.clean: Unregisters this > Cleanable and performs the cleanup > action that was associated with it. If > this Cleanable has already been > unregistered nothing happens. The > cleanup action is invoked at most once > per registered Cleanable, regardless > of the number of calls to clean(). > > --- > > Looking at Cleaner .... > > > "Cleaner manages a set of object > references and corresponding cleaning > functions" > > I would say "cleaning actions" rather > than functions as they yield no > value. This change needs to be made > throughout. > > "The most efficient use is to > explicitly invoke the clean method when > the object is closed or no longer > needed. The cleaning function is a > Runnable to be invoked at most once > when the object is no longer > reachable unless it has already been > explicitly cleaned." > > To me this doesn't quite capture the > need to not use the Runnable > directly. I would rephrase: > > "In normal use a object should be > cleaned up when no longer required, by > invoking the clean() method of the > associated Cleanable. This guarantees > that the cleaning action will be > performed at most once per object: > either explicitly, or automatically if > it becomes phantom-reachable. If > cleaned explicitly the object should > not be used again. Note that the > cleaning action must not refer to the > object ..." > > --- > > Question: what happens if an object is > registered simultaneously with > multiple Cleaners? Do we need to warn > the user against that? > > --- > > The phrase "process the unreachable > objects and to invoke cleaning > functions" doesn't quite seem right to > me. The objects themselves are > never processed, or even touched - > right? So really the thread is > started to "invoke the cleanup actions > for unreachable objects". > > create(): can also throw > SecurityException if not allowed to > create/start threads. > > register(Object obj, Runnable thunk): > thunk -> action > > Thanks, > David > > > On 12/6/15 7:46 PM, David Holmes > wrote: > > Hi Roger, > > Sorry to be late here but was > trying not to get involved :) > > It is already implicit that > ThreadFactory.newThread should > return > unstarted threads - that is > what a new Thread is - so I > don't think > IllegalThreadStateException > needs to be documented here as > it is > documenting behaviour of a > broken ThreadFactory (and a broken > ThreadFactory could throw > anything) . > > It does seem that new is fairly > well understood but one can read of > ThreadFactory is as a bit > ambiguous, lacking a direct > reference to the > Thread.State of the new thread > and since it allows various > attributes of the thread to be > modified > after the constructor. > Since the runnable is supplied as > an argument it is ready to be > started, > why not. > It seemed useful to reinforce the > salient points. > > Also the no-arg cleaner() can > also throw SecurityException. > > The thread construction is done in > doPriv so it should not throw. > Did I miss some edge case? > > Also this: > > 127 * On each call the > {@link > ThreadFactory#newThread(Runnable) > thread factory} > 128 * should return a > {@link Thread.State#NEW new > thread} with > an appropriate > 129 * {@linkplain > Thread#getContextClassLoader > context class > loader}, > 130 * {@linkplain > Thread#getName() name}, > 131 * {@linkplain > Thread#getPriority() priority}, > 132 * permissions, etc. > > then begs the questions as to > what is "appropriate". I think > this can > be said much more simply as: > "The ThreadFactory must > provide a Thread > that is suitable for > performing the cleaning work". > Though even that > raises questions. I'm not sure > why a ThreadFactory is > actually needed > here ?? Special security > context? If so that could be > mentioned, but I > don't think name or priority > need to be discussed. > > It was intended to prod the client > to be deliberate about the > threadFactory. > Since the client is integrating > the Cleaner and respective cleaning > functions > with the client code, the > ThreadFactory makes it possible > for the > client to > initialize a suitable thread and > the comments serve as a reminder. > I agree that the phrase 'suitable > for performing the cleaning work' is > the operative one. > > Thanks, Roger > > Thanks, > David > > > > From ramanand.patil at oracle.com Wed Dec 9 07:44:42 2015 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 8 Dec 2015 23:44:42 -0800 (PST) Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition Message-ID: <75b86334-1d29-4889-b9ae-e2815462d711@default> HI all, Please review a fix for Bug - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. Regards, Ramanand. From peter.levart at gmail.com Wed Dec 9 07:46:12 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Dec 2015 08:46:12 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666CD2D.3080402@oracle.com> <5666D0B3.707090! 5@oracle.com> Message-ID: <5667DC44.7020009@gmail.com> On 12/08/2015 07:44 PM, Kim Barrett wrote: > On Dec 8, 2015, at 7:44 AM, David Holmes wrote: >> But thinking more on this approach this is simply not scalable. A >> Cleaner per cleanable-class could result in hundreds of threads being >> active! > That would indeed be awful. However, the scope of a Cleaner should > not usually be a class. More typically it would be a subsystem, > module, plugin, or some other sensible unit of sharing. I assume > Peter's example had a class-scoped Cleaner for simplicity of > presentation. A class-scoped Cleaner probably should be treated as a > canonical anti-pattern for Cleaner usage; appropriate in rare > circumstances, but usually a mistake. > >> What exactly are the advantages over finalization again? > The same as PhantomReference-based cleanup vs finalization. > > - Performance (especially after JDK-8071507). > > - Semantic simplicity, avoiding the need to deal with resurrection of > objects, and objects not needing to protect themselves from some > kinds of post-cleanup misuse. > ... the last thing is applicable only if Cleanable.clean() is never invoked. If it is invoked (as part of on-demand cleaning like AutoCloseable.close()) the object will still have to protect itself from misuse. That's what the problem with direct/mapped ByteBuffer is. The protection from post-cleanup misuse would be to costly so there was rather no on-demand unmapping implemented (in public API)... Regards, Peter From david.holmes at oracle.com Wed Dec 9 07:54:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 17:54:51 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5667D2BC.2030505@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> Message-ID: <5667DE4B.80409@oracle.com> On 9/12/2015 5:05 PM, Peter Levart wrote: > Hi, > > I think the only way to try to prevent such things is with a good > example in javadoc that "screams" of possible miss-usages. Problem is that many people - myself included - would not have a clue when a lambda "captures this"! Is that part of lambda expressions or a consequence of the current implementation? David > > public static class CleanerExample implements AutoCloseable { > > private static final Cleaner cleaner = ...; // preferably a > shared cleaner > > private final PrivateNativeResource pnr; > > private final Cleaner.Cleanable cleanable; > > public CleanerExample(args, ...) { > > // prepare captured state as local vars... > PrivateNativeResource _pnr = ...; > > this.cleanable = cleaner.register(this, () -> { > // DON'T capture any instance fields with lambda since > that would > // capture 'this' and prevent it from becoming > phantom-reachable!!! > _pnr.close(); > }); > > this.pnr = _pnr; > } > > public void close() { > cleanable.clean(); > } > > > Regards, Peter > > On 12/09/2015 05:15 AM, Vitaly Davidovich wrote: >> This has the same problem, doesn't it? The bottom line is if the >> lambda is () -> you're getting a >> capture of `this`. >> >> On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs > > wrote: >> >> Hi, >> >> Another option that should always capture is to define a specific >> static method with the needed values as arguments: >> >> >> public static class CleanerExample implements AutoCloseable { >> >> FileDescriptor fd = ...; >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this,*() -> cleanup(fd)*); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> >> *static void cleanup(FileDescriptor fd ...) {** >> ** fd.close();** >> ** }* >> >> } >> >> On 12/8/2015 4:24 PM, Peter Levart wrote: >> >> >> >> On 12/08/2015 08:08 PM, Steven Schlansker wrote: >> >> On Dec 8, 2015, at 10:51 AM, Peter >> Levart> > wrote: >> >> On 12/08/2015 04:34 PM, Roger Riggs wrote: >> >> private final Cleaner.Cleanable cleanable >> = cleaner.register(this, () -> fd.close()); >> >> Sorry Roger, but this example is flawed. This is >> tricky! The lambda "() -> fd.close()" captures 'this', >> not only 'fd' as can be seen by running the following >> example: >> To correct that, but still use lambda, you would have >> to capture a local variable >> >> It looks like using "fd::close" might also work, and is >> more concise: >> >> IntSupplier x = () -> 10; >> IntSupplier xS = x::getAsInt; >> >> @Test >> public void test() { >> System.out.println(xS.getAsInt()); >> x = () -> 15; >> System.out.println(xS.getAsInt()); >> } >> >> 10 >> 10 >> >> >> Yes, good idea. This is a pre-bound method reference (the part >> on the left of '::' is evaluated immediately). Contrast to >> lambda, where "fd.close()" is an expression in the lambda body >> which is evaluated when lambda is invoked and that expression >> is composed of a field get + method invocation. In order to >> get an instance field, the object containing it must be captured. >> >> So for Roger's example, this will work: >> >> >> public static class CleanerExample implements AutoCloseable { >> >> FileDescriptor fd = ...; >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this, fd::close); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } >> >> >> ...if FileDescriptor.close() is an instance method with no >> arguments and doesn't throw any checked exceptions. >> >> >> Regards, Peter >> >> I'll work the example into the javadoc. >> >> Roger >> >> >> On 12/08/2015 07:25 AM, Peter Levart wrote: >> >> On 12/08/2015 09:22 AM, David Holmes wrote: >> >> Actually I'm having more doubts about this >> API. >> >> Library writers use finalize() as a last >> ditch cleanup mechanism in >> case the user doesn't explicitly call any >> "cleanup" method. So as a >> library writer I would think I am now >> expected to register my >> instances with a Cleaner and provide a >> Runnable that does what >> finalize() would have done. But in that >> usage pattern the end user of >> my objects never has any access to my >> Cleanables so can never call >> clean() themselves - instead they should >> be calling the cleanup >> function directly, just as they would >> previously. So the whole "invoke >> at most once" for the clean() method seems >> somewhat unnecessary; and >> the way we should write the cleanup method >> and the Runnable need to be >> more cleary explained as the idempotentcy >> of the cleanup needs to be >> handled in the library writers code not >> the Cleaner/Clenable >> implementation. >> >> David >> >> Hi David, (once again for the list) >> >> I agree that an example would be most helpful. >> Here's how a normal finalizable object is >> typically coded: >> >> public class FinalizeExample implements >> AutoCloseable { >> >> private boolean closed; >> >> @Override >> public synchronized void close() { >> if (!closed) { >> closed = true; >> // cleanup actions accessing >> state of FinalizeExample, executed at most once >> } >> } >> >> @Override >> protected void finalize() throws >> Throwable { >> close(); >> } >> } >> >> >> Re-factoring to use Cleaner is a process that >> extracts the state representing native >> resource from the user-facing class into a >> private nested static class and makes the >> user-facing object just a facade that has >> access to the state object and is registered >> with a Cleaner. The Cleaner.Cleanable instance >> is also made accessible from the user-facing >> object, so it can provide the on-demand cleaning: >> >> public static class CleanerExample >> implements AutoCloseable { >> >> private static class State implements >> Runnable { >> @Override >> public void run() { >> // cleanup actions accessing >> State, executed at most once >> } >> } >> >> private static final Cleaner cleaner = >> Cleaner.create(); >> >> private final State state = new State(); >> private final Cleaner.Cleanable >> cleanable = cleaner.register(this, state); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> } >> >> >> Regards, Peter >> >> On 8/12/2015 6:09 PM, David Holmes wrote: >> >> Hi Roger, >> >> Sorry I had no choice but to look at >> this more closely ... and apologies >> as this is very late feedback ... I >> only looked at the API not the >> details of the implementation. >> >> On 8/12/2015 4:50 AM, Roger Riggs wrote: >> >> Hi David, >> >> Thanks for the comments, >> >> Updated the javadoc and webrev >> with editorial changes. >> >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> >> >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> >> >> Should cleaning and cleanables be >> mentioned as part of the package-doc >> for java.lang.ref? Else they seem to >> be an overlooked add-on not part of >> the core reference related >> functionality. Perhaps even state how >> they >> are preferred to use of finalization? >> >> Cleaner.Cleanable: >> >> It was unclear to me what the usage >> model was for this. I'm assuming >> that the intent is that rather than >> register a "thunk" (lets call it an >> "action") that can be invoked directly >> by user-code, the user should >> invoke the action via the call to >> clean(). In which case I think it >> should be explained somewhat more >> clearly - see below. >> >> I would describe the Cleanable class as: >> >> Cleanable: Represents an object that >> has been registered for cleanup by >> a Cleaner. The object can be cleaned >> directly, by a call to clean(), if >> it is no longer to be used, else it >> will be cleaned automatically when >> the object becomes phantom-reachable. >> >> Cleanable.clean: Unregisters this >> Cleanable and performs the cleanup >> action that was associated with it. If >> this Cleanable has already been >> unregistered nothing happens. The >> cleanup action is invoked at most once >> per registered Cleanable, regardless >> of the number of calls to clean(). >> >> --- >> >> Looking at Cleaner .... >> >> >> "Cleaner manages a set of object >> references and corresponding cleaning >> functions" >> >> I would say "cleaning actions" rather >> than functions as they yield no >> value. This change needs to be made >> throughout. >> >> "The most efficient use is to >> explicitly invoke the clean method when >> the object is closed or no longer >> needed. The cleaning function is a >> Runnable to be invoked at most once >> when the object is no longer >> reachable unless it has already been >> explicitly cleaned." >> >> To me this doesn't quite capture the >> need to not use the Runnable >> directly. I would rephrase: >> >> "In normal use a object should be >> cleaned up when no longer required, by >> invoking the clean() method of the >> associated Cleanable. This guarantees >> that the cleaning action will be >> performed at most once per object: >> either explicitly, or automatically if >> it becomes phantom-reachable. If >> cleaned explicitly the object should >> not be used again. Note that the >> cleaning action must not refer to the >> object ..." >> >> --- >> >> Question: what happens if an object is >> registered simultaneously with >> multiple Cleaners? Do we need to warn >> the user against that? >> >> --- >> >> The phrase "process the unreachable >> objects and to invoke cleaning >> functions" doesn't quite seem right to >> me. The objects themselves are >> never processed, or even touched - >> right? So really the thread is >> started to "invoke the cleanup actions >> for unreachable objects". >> >> create(): can also throw >> SecurityException if not allowed to >> create/start threads. >> >> register(Object obj, Runnable thunk): >> thunk -> action >> >> Thanks, >> David >> >> >> On 12/6/15 7:46 PM, David Holmes >> wrote: >> >> Hi Roger, >> >> Sorry to be late here but was >> trying not to get involved :) >> >> It is already implicit that >> ThreadFactory.newThread should >> return >> unstarted threads - that is >> what a new Thread is - so I >> don't think >> IllegalThreadStateException >> needs to be documented here as >> it is >> documenting behaviour of a >> broken ThreadFactory (and a >> broken >> ThreadFactory could throw >> anything) . >> >> It does seem that new is fairly >> well understood but one can read of >> ThreadFactory is as a bit >> ambiguous, lacking a direct >> reference to the >> Thread.State of the new thread >> and since it allows various >> attributes of the thread to be >> modified >> after the constructor. >> Since the runnable is supplied as >> an argument it is ready to be >> started, >> why not. >> It seemed useful to reinforce the >> salient points. >> >> Also the no-arg cleaner() can >> also throw SecurityException. >> >> The thread construction is done in >> doPriv so it should not throw. >> Did I miss some edge case? >> >> Also this: >> >> 127 * On each call the >> {@link >> ThreadFactory#newThread(Runnable) >> thread factory} >> 128 * should return a >> {@link Thread.State#NEW new >> thread} with >> an appropriate >> 129 * {@linkplain >> Thread#getContextClassLoader >> context class >> loader}, >> 130 * {@linkplain >> Thread#getName() name}, >> 131 * {@linkplain >> Thread#getPriority() priority}, >> 132 * permissions, etc. >> >> then begs the questions as to >> what is "appropriate". I think >> this can >> be said much more simply as: >> "The ThreadFactory must >> provide a Thread >> that is suitable for >> performing the cleaning work". >> Though even that >> raises questions. I'm not sure >> why a ThreadFactory is >> actually needed >> here ?? Special security >> context? If so that could be >> mentioned, but I >> don't think name or priority >> need to be discussed. >> >> It was intended to prod the client >> to be deliberate about the >> threadFactory. >> Since the client is integrating >> the Cleaner and respective cleaning >> functions >> with the client code, the >> ThreadFactory makes it possible >> for the >> client to >> initialize a suitable thread and >> the comments serve as a reminder. >> I agree that the phrase 'suitable >> for performing the cleaning work' is >> the operative one. >> >> Thanks, Roger >> >> Thanks, >> David >> >> >> >> > From peter.levart at gmail.com Wed Dec 9 09:30:09 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Dec 2015 10:30:09 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5667DE4B.80409@oracle.com> References: <560D3F61.6040607@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <5667DE4B.80409@oracle.com> Message-ID: <5667F4A1.7080800@gmail.com> On 12/09/2015 08:54 AM, David Holmes wrote: > On 9/12/2015 5:05 PM, Peter Levart wrote: >> Hi, >> >> I think the only way to try to prevent such things is with a good >> example in javadoc that "screams" of possible miss-usages. > > Problem is that many people - myself included - would not have a clue > when a lambda "captures this"! Is that part of lambda expressions or a > consequence of the current implementation? > > David I can't seem to find anything about capturing variables by lambda expressions in JLS (except the talk about definitely assigned local variables). I think lambdas ware meant to act like anonymous inner classes. What they do is they capture a variable not the value variable has at capture time. For locals this is the same, as lambdas and anonymous inner classes only allow capturing "effectively final" and "definitely assigned" local variables, which means only locals that don't change the value after they are captured. With fields this is different. Instance fields are never really final (even if declared final). And as fields are implemented, they can not exist without the object that contains them... Regards, Peter P.S. The difference between anonymous inner class creation expression and lambda expression is that in instance scope, anonymous inner class always "captures" the outer instance while lambda expression only if it has to. > >> >> public static class CleanerExample implements AutoCloseable { >> >> private static final Cleaner cleaner = ...; // preferably a >> shared cleaner >> >> private final PrivateNativeResource pnr; >> >> private final Cleaner.Cleanable cleanable; >> >> public CleanerExample(args, ...) { >> >> // prepare captured state as local vars... >> PrivateNativeResource _pnr = ...; >> >> this.cleanable = cleaner.register(this, () -> { >> // DON'T capture any instance fields with lambda since >> that would >> // capture 'this' and prevent it from becoming >> phantom-reachable!!! >> _pnr.close(); >> }); >> >> this.pnr = _pnr; >> } >> >> public void close() { >> cleanable.clean(); >> } >> >> >> Regards, Peter >> >> On 12/09/2015 05:15 AM, Vitaly Davidovich wrote: >>> This has the same problem, doesn't it? The bottom line is if the >>> lambda is () -> you're getting a >>> capture of `this`. >>> >>> On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs >> > wrote: >>> >>> Hi, >>> >>> Another option that should always capture is to define a specific >>> static method with the needed values as arguments: >>> >>> >>> public static class CleanerExample implements AutoCloseable { >>> >>> FileDescriptor fd = ...; >>> >>> private static final Cleaner cleaner = Cleaner.create(); >>> >>> private final Cleaner.Cleanable cleanable = >>> cleaner.register(this,*() -> cleanup(fd)*); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> >>> *static void cleanup(FileDescriptor fd ...) {** >>> ** fd.close();** >>> ** }* >>> >>> } >>> >>> On 12/8/2015 4:24 PM, Peter Levart wrote: >>> >>> >>> >>> On 12/08/2015 08:08 PM, Steven Schlansker wrote: >>> >>> On Dec 8, 2015, at 10:51 AM, Peter >>> Levart>> > wrote: >>> >>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>> >>> private final Cleaner.Cleanable cleanable >>> = cleaner.register(this, () -> fd.close()); >>> >>> Sorry Roger, but this example is flawed. This is >>> tricky! The lambda "() -> fd.close()" captures 'this', >>> not only 'fd' as can be seen by running the following >>> example: >>> To correct that, but still use lambda, you would have >>> to capture a local variable >>> >>> It looks like using "fd::close" might also work, and is >>> more concise: >>> >>> IntSupplier x = () -> 10; >>> IntSupplier xS = x::getAsInt; >>> >>> @Test >>> public void test() { >>> System.out.println(xS.getAsInt()); >>> x = () -> 15; >>> System.out.println(xS.getAsInt()); >>> } >>> >>> 10 >>> 10 >>> >>> >>> Yes, good idea. This is a pre-bound method reference (the part >>> on the left of '::' is evaluated immediately). Contrast to >>> lambda, where "fd.close()" is an expression in the lambda body >>> which is evaluated when lambda is invoked and that expression >>> is composed of a field get + method invocation. In order to >>> get an instance field, the object containing it must be >>> captured. >>> >>> So for Roger's example, this will work: >>> >>> >>> public static class CleanerExample implements >>> AutoCloseable { >>> >>> FileDescriptor fd = ...; >>> >>> private static final Cleaner cleaner = >>> Cleaner.create(); >>> >>> private final Cleaner.Cleanable cleanable = >>> cleaner.register(this, fd::close); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> } >>> >>> >>> ...if FileDescriptor.close() is an instance method with no >>> arguments and doesn't throw any checked exceptions. >>> >>> >>> Regards, Peter >>> >>> I'll work the example into the javadoc. >>> >>> Roger >>> >>> >>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>> >>> On 12/08/2015 09:22 AM, David Holmes wrote: >>> >>> Actually I'm having more doubts about this >>> API. >>> >>> Library writers use finalize() as a last >>> ditch cleanup mechanism in >>> case the user doesn't explicitly call any >>> "cleanup" method. So as a >>> library writer I would think I am now >>> expected to register my >>> instances with a Cleaner and provide a >>> Runnable that does what >>> finalize() would have done. But in that >>> usage pattern the end user of >>> my objects never has any access to my >>> Cleanables so can never call >>> clean() themselves - instead they should >>> be calling the cleanup >>> function directly, just as they would >>> previously. So the whole "invoke >>> at most once" for the clean() method seems >>> somewhat unnecessary; and >>> the way we should write the cleanup method >>> and the Runnable need to be >>> more cleary explained as the idempotentcy >>> of the cleanup needs to be >>> handled in the library writers code not >>> the Cleaner/Clenable >>> implementation. >>> >>> David >>> >>> Hi David, (once again for the list) >>> >>> I agree that an example would be most helpful. >>> Here's how a normal finalizable object is >>> typically coded: >>> >>> public class FinalizeExample implements >>> AutoCloseable { >>> >>> private boolean closed; >>> >>> @Override >>> public synchronized void close() { >>> if (!closed) { >>> closed = true; >>> // cleanup actions accessing >>> state of FinalizeExample, executed at most once >>> } >>> } >>> >>> @Override >>> protected void finalize() throws >>> Throwable { >>> close(); >>> } >>> } >>> >>> >>> Re-factoring to use Cleaner is a process that >>> extracts the state representing native >>> resource from the user-facing class into a >>> private nested static class and makes the >>> user-facing object just a facade that has >>> access to the state object and is registered >>> with a Cleaner. The Cleaner.Cleanable instance >>> is also made accessible from the user-facing >>> object, so it can provide the on-demand >>> cleaning: >>> >>> public static class CleanerExample >>> implements AutoCloseable { >>> >>> private static class State implements >>> Runnable { >>> @Override >>> public void run() { >>> // cleanup actions accessing >>> State, executed at most once >>> } >>> } >>> >>> private static final Cleaner cleaner = >>> Cleaner.create(); >>> >>> private final State state = new >>> State(); >>> private final Cleaner.Cleanable >>> cleanable = cleaner.register(this, state); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> } >>> >>> >>> Regards, Peter >>> >>> On 8/12/2015 6:09 PM, David Holmes wrote: >>> >>> Hi Roger, >>> >>> Sorry I had no choice but to look at >>> this more closely ... and apologies >>> as this is very late feedback ... I >>> only looked at the API not the >>> details of the implementation. >>> >>> On 8/12/2015 4:50 AM, Roger Riggs >>> wrote: >>> >>> Hi David, >>> >>> Thanks for the comments, >>> >>> Updated the javadoc and webrev >>> with editorial changes. >>> >>> >>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> >>> >>> >>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> >>> >>> Should cleaning and cleanables be >>> mentioned as part of the package-doc >>> for java.lang.ref? Else they seem to >>> be an overlooked add-on not part of >>> the core reference related >>> functionality. Perhaps even state how >>> they >>> are preferred to use of finalization? >>> >>> Cleaner.Cleanable: >>> >>> It was unclear to me what the usage >>> model was for this. I'm assuming >>> that the intent is that rather than >>> register a "thunk" (lets call it an >>> "action") that can be invoked directly >>> by user-code, the user should >>> invoke the action via the call to >>> clean(). In which case I think it >>> should be explained somewhat more >>> clearly - see below. >>> >>> I would describe the Cleanable class >>> as: >>> >>> Cleanable: Represents an object that >>> has been registered for cleanup by >>> a Cleaner. The object can be cleaned >>> directly, by a call to clean(), if >>> it is no longer to be used, else it >>> will be cleaned automatically when >>> the object becomes phantom-reachable. >>> >>> Cleanable.clean: Unregisters this >>> Cleanable and performs the cleanup >>> action that was associated with it. If >>> this Cleanable has already been >>> unregistered nothing happens. The >>> cleanup action is invoked at most once >>> per registered Cleanable, regardless >>> of the number of calls to clean(). >>> >>> --- >>> >>> Looking at Cleaner .... >>> >>> >>> "Cleaner manages a set of object >>> references and corresponding cleaning >>> functions" >>> >>> I would say "cleaning actions" rather >>> than functions as they yield no >>> value. This change needs to be made >>> throughout. >>> >>> "The most efficient use is to >>> explicitly invoke the clean method when >>> the object is closed or no longer >>> needed. The cleaning function is a >>> Runnable to be invoked at most once >>> when the object is no longer >>> reachable unless it has already been >>> explicitly cleaned." >>> >>> To me this doesn't quite capture the >>> need to not use the Runnable >>> directly. I would rephrase: >>> >>> "In normal use a object should be >>> cleaned up when no longer required, by >>> invoking the clean() method of the >>> associated Cleanable. This guarantees >>> that the cleaning action will be >>> performed at most once per object: >>> either explicitly, or automatically if >>> it becomes phantom-reachable. If >>> cleaned explicitly the object should >>> not be used again. Note that the >>> cleaning action must not refer to the >>> object ..." >>> >>> --- >>> >>> Question: what happens if an object is >>> registered simultaneously with >>> multiple Cleaners? Do we need to warn >>> the user against that? >>> >>> --- >>> >>> The phrase "process the unreachable >>> objects and to invoke cleaning >>> functions" doesn't quite seem right to >>> me. The objects themselves are >>> never processed, or even touched - >>> right? So really the thread is >>> started to "invoke the cleanup actions >>> for unreachable objects". >>> >>> create(): can also throw >>> SecurityException if not allowed to >>> create/start threads. >>> >>> register(Object obj, Runnable thunk): >>> thunk -> action >>> >>> Thanks, >>> David >>> >>> >>> On 12/6/15 7:46 PM, David Holmes >>> wrote: >>> >>> Hi Roger, >>> >>> Sorry to be late here but was >>> trying not to get involved :) >>> >>> It is already implicit that >>> ThreadFactory.newThread should >>> return >>> unstarted threads - that is >>> what a new Thread is - so I >>> don't think >>> IllegalThreadStateException >>> needs to be documented here as >>> it is >>> documenting behaviour of a >>> broken ThreadFactory (and a >>> broken >>> ThreadFactory could throw >>> anything) . >>> >>> It does seem that new is fairly >>> well understood but one can read of >>> ThreadFactory is as a bit >>> ambiguous, lacking a direct >>> reference to the >>> Thread.State of the new thread >>> and since it allows various >>> attributes of the thread to be >>> modified >>> after the constructor. >>> Since the runnable is supplied as >>> an argument it is ready to be >>> started, >>> why not. >>> It seemed useful to reinforce the >>> salient points. >>> >>> Also the no-arg cleaner() can >>> also throw SecurityException. >>> >>> The thread construction is done in >>> doPriv so it should not throw. >>> Did I miss some edge case? >>> >>> Also this: >>> >>> 127 * On each call the >>> {@link >>> ThreadFactory#newThread(Runnable) >>> thread factory} >>> 128 * should return a >>> {@link Thread.State#NEW new >>> thread} with >>> an appropriate >>> 129 * {@linkplain >>> Thread#getContextClassLoader >>> context class >>> loader}, >>> 130 * {@linkplain >>> Thread#getName() name}, >>> 131 * {@linkplain >>> Thread#getPriority() priority}, >>> 132 * permissions, etc. >>> >>> then begs the questions as to >>> what is "appropriate". I think >>> this can >>> be said much more simply as: >>> "The ThreadFactory must >>> provide a Thread >>> that is suitable for >>> performing the cleaning work". >>> Though even that >>> raises questions. I'm not sure >>> why a ThreadFactory is >>> actually needed >>> here ?? Special security >>> context? If so that could be >>> mentioned, but I >>> don't think name or priority >>> need to be discussed. >>> >>> It was intended to prod the client >>> to be deliberate about the >>> threadFactory. >>> Since the client is integrating >>> the Cleaner and respective cleaning >>> functions >>> with the client code, the >>> ThreadFactory makes it possible >>> for the >>> client to >>> initialize a suitable thread and >>> the comments serve as a reminder. >>> I agree that the phrase 'suitable >>> for performing the cleaning >>> work' is >>> the operative one. >>> >>> Thanks, Roger >>> >>> Thanks, >>> David >>> >>> >>> >>> >> From scolebourne at joda.org Wed Dec 9 11:15:59 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 9 Dec 2015 11:15:59 +0000 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <75b86334-1d29-4889-b9ae-e2815462d711@default> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> Message-ID: The logic looks fine. In the main code, this part .getLong(INSTANT_SECONDS); can be replaced with .toEpochSecond(); which will be slightly faster. In the test case, this part .plus(15, ChronoUnit.MINUTES); can be replaced with .plusMinutes(15) And .with(ChronoField.OFFSET_SECONDS, ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) can be replaced with .with(ZoneOffset.of(offsetSamples[j])) In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. thanks for fixing this Stephen On 9 December 2015 at 07:44, Ramanand Patil wrote: > HI all, > > > > Please review a fix for Bug - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 > > > > Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). > > > > Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ > > > > One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. > > > > > > Regards, > > Ramanand. From paul.sandoz at oracle.com Wed Dec 9 11:21:58 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Dec 2015 12:21:58 +0100 Subject: ConcurrentMap::compute clarification In-Reply-To: References: Message-ID: Hi Jaromir, Thanks, you found a bug, seems to be a hangover from the Map default implementation. One fix might be: if (oldValue != null) { // something to remove if (remove(key, oldValue)) { // removed the old value as expected return null; } // some other value replaced old value. try again. oldValue = get(key); } else if (contains(key)) { // a mapping was added after obtaining the old value, try again oldValue = get(key); } else { // nothing to do. Leave things as they were. return null; } Although i am somewhat inclined to do away with the contains check (given nulls are not supported), so things are just left alone. Do you wanna report the issue here: http://bugreport.java.com/ Thanks, Paul. > On 8 Dec 2015, at 11:12, Jaromir Hamala wrote: > > Hi, > > I stumbled upon an interesting issue with default implementation of > `compute(K key, BiFunction > remappingFunction)` in JDK8 `ConcurrentMap`. > According to its contract the default method implementation assumes map > implementations do not support null values. > > This is the begin of the default implementation: > > default V compute(K key, BiFunction > remappingFunction) { > Objects.requireNonNull(remappingFunction); > V oldValue = get(key); > for(;;) { > V newValue = remappingFunction.apply(key, oldValue); > if (newValue == null) { > // delete mapping > if (oldValue != null || containsKey(key)) { > // something to remove > if (remove(key, oldValue)) { > [...] > > > Let's say we have an empty map and 2 threads: > T1 is calling the `compute('foo', someFunction)` > T2 is concurrently calling calling `put('foo', 'bar');` > > so the T1 will get `oldValue = null`, but `containsKey()` will return > `true` - because T2 already created the mapping `foo -> bar`. Hence T1 will > call `remove('foo', null)` ! > > Contract of `remove()` says: `throws NullPointerException if the specified > key or value is null, and this map does not permit null keys or values > optional.` -> the T1 will throw NPE. > Is it a bug in default method impl or do I understand it wrong? > > Cheers, > Jaromir > > -- > ?Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away.? > Antoine de Saint Exup?ry From jaromir.hamala at gmail.com Wed Dec 9 11:24:06 2015 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Wed, 9 Dec 2015 13:24:06 +0200 Subject: ConcurrentMap::compute clarification In-Reply-To: References: Message-ID: Hi Paul, many thanks for confirmation. I'm going to fill the bug. Cheers, Jaromir On Wed, Dec 9, 2015 at 1:21 PM, Paul Sandoz wrote: > Hi Jaromir, > > Thanks, you found a bug, seems to be a hangover from the Map default > implementation. > > One fix might be: > > if (oldValue != null) { > // something to remove > if (remove(key, oldValue)) { > // removed the old value as expected > return null; > } > > // some other value replaced old value. try again. > oldValue = get(key); > } else if (contains(key)) { > // a mapping was added after obtaining the old value, try again > oldValue = get(key); > } else { > // nothing to do. Leave things as they were. > return null; > } > > Although i am somewhat inclined to do away with the contains check (given > nulls are not supported), so things are just left alone. > > Do you wanna report the issue here: > > http://bugreport.java.com/ > > Thanks, > Paul. > > > On 8 Dec 2015, at 11:12, Jaromir Hamala > wrote: > > > > Hi, > > > > I stumbled upon an interesting issue with default implementation of > > `compute(K key, BiFunction > > remappingFunction)` in JDK8 `ConcurrentMap`. > > According to its contract the default method implementation assumes map > > implementations do not support null values. > > > > This is the begin of the default implementation: > > > > default V compute(K key, BiFunction > > remappingFunction) { > > Objects.requireNonNull(remappingFunction); > > V oldValue = get(key); > > for(;;) { > > V newValue = remappingFunction.apply(key, oldValue); > > if (newValue == null) { > > // delete mapping > > if (oldValue != null || containsKey(key)) { > > // something to remove > > if (remove(key, oldValue)) { > > [...] > > > > > > Let's say we have an empty map and 2 threads: > > T1 is calling the `compute('foo', someFunction)` > > T2 is concurrently calling calling `put('foo', 'bar');` > > > > so the T1 will get `oldValue = null`, but `containsKey()` will return > > `true` - because T2 already created the mapping `foo -> bar`. Hence T1 > will > > call `remove('foo', null)` ! > > > > Contract of `remove()` says: `throws NullPointerException if the > specified > > key or value is null, and this map does not permit null keys or values > > optional.` -> the T1 will throw NPE. > > Is it a bug in default method impl or do I understand it wrong? > > > > Cheers, > > Jaromir > > > > -- > > ?Perfection is achieved, not when there is nothing more to add, but when > > there is nothing left to take away.? > > Antoine de Saint Exup?ry > > -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry From chris.hegarty at oracle.com Wed Dec 9 11:44:22 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Dec 2015 11:44:22 +0000 Subject: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16 Message-ID: <56681416.1030406@oracle.com> Looks like the Compact Strings work inadvertently introduced a dependency on sun.misc.Unsafe. ( just temporary confusion with having two Unsafes until the jdk.unsupported module is defined ) diff --git a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java --- a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java +++ b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java @@ -25,8 +25,8 @@ package sun.nio.cs; -import static sun.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; -import static sun.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; class StringUTF16 { @@ -35,5 +35,5 @@ ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L); } - private static final sun.misc.Unsafe unsafe = sun.misc.Unsafe.getUnsafe(); + private static final jdk.internal.misc.Unsafe unsafe = jdk.internal.misc.Unsafe.getUnsafe(); } -Chris. From paul.sandoz at oracle.com Wed Dec 9 11:48:34 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 9 Dec 2015 12:48:34 +0100 Subject: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16 In-Reply-To: <56681416.1030406@oracle.com> References: <56681416.1030406@oracle.com> Message-ID: +1 Paul. > On 9 Dec 2015, at 12:44, Chris Hegarty wrote: > > Looks like the Compact Strings work inadvertently introduced a > dependency on sun.misc.Unsafe. ( just temporary confusion with > having two Unsafes until the jdk.unsupported module is defined ) > > diff --git a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > --- a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > +++ b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > @@ -25,8 +25,8 @@ > > package sun.nio.cs; > > -import static sun.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; > -import static sun.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; > +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; > +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; > > class StringUTF16 { > > @@ -35,5 +35,5 @@ > ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L); > } > > - private static final sun.misc.Unsafe unsafe = sun.misc.Unsafe.getUnsafe(); > + private static final jdk.internal.misc.Unsafe unsafe = jdk.internal.misc.Unsafe.getUnsafe(); > } > > -Chris. From vladimir.x.ivanov at oracle.com Wed Dec 9 12:10:01 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 9 Dec 2015 15:10:01 +0300 Subject: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character In-Reply-To: <565EF117.5090804@oracle.com> References: <564B532E.6000906@oracle.com> <142916502.1330400.1447794836696.JavaMail.zimbra@u-pem.fr> <564BA577.1030701@oracle.com> <564CFB05.8080901@oracle.com> <565EF117.5090804@oracle.com> Message-ID: <56681A19.6080502@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/2/15 4:24 PM, Claes Redestad wrote: > > On 2015-11-18 23:26, Aleksey Shipilev wrote: >> By the way, I see there is a cleaner way to implement emitIconstInsn, >> see java.lang.invoke.TypeConvertingMethodAdapter.iconst: >> >> void iconst(final int cst) { >> if (cst >= -1 && cst <= 5) { >> mv.visitInsn(Opcodes.ICONST_0 + cst); >> } else if (cst >= Byte.MIN_VALUE && cst <= Byte.MAX_VALUE) { >> mv.visitIntInsn(Opcodes.BIPUSH, cst); >> } else if (cst >= Short.MIN_VALUE && cst <= Short.MAX_VALUE) { >> mv.visitIntInsn(Opcodes.SIPUSH, cst); >> } else { >> mv.visitLdcInsn(cst); >> } >> } >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/aa9e8b3916ae/src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java#l285 >> >> > > Nice catch. > > Picking up this tiny improvement again, I realized there are a few other > bytecode minifying tricks we could consider while we're at it: > > http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ > > It would probably make sense to move emitConst to > TypeConvertingMethodAdapter and use that in place a raw MethodVisitor - > removing some code - but there might be some reasons not to > (bootstrapping?). For this improvement I opt to keep the changes > contained inside InvokerBytecodeGenerator. unless someone insists. > > /Claes From timo.kinnunen at gmail.com Wed Dec 9 13:00:17 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 9 Dec 2015 14:00:17 +0100 Subject: ConcurrentMap::compute clarification In-Reply-To: References: Message-ID: <566825e1.95151c0a.d0516.ffffb8e2@mx.google.com> Yes, I think the containsKey check is just not appropriate here. Doing the check means the information gained from reading oldValue becomes immediately stale. This means oldValue has to be read again. But reading oldValue means the information received from the check on whether the loop has to repeated now becomes stale. So in the end no new information is gained but one extra loop will be performed. If there?s a devious Maxwell?s daemon thread which keeps adding and removing a key-value mapping at just the right times around the containsKey check then the compute method will loop forever without the value the daemon is using ever being observable. This could be simulated by having the containsKey method return true for any key in every case where it is the sole party to an atomic operation. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Paul Sandoz Sent: Wednesday, December 9, 2015 12:22 To: Jaromir Hamala Cc: core-libs-dev at openjdk.java.net Subject: Re: ConcurrentMap::compute clarification Hi Jaromir, Thanks, you found a bug, seems to be a hangover from the Map default implementation. One fix might be: if (oldValue != null) { // something to remove if (remove(key, oldValue)) { // removed the old value as expected return null; } // some other value replaced old value. try again. oldValue = get(key); } else if (contains(key)) { // a mapping was added after obtaining the old value, try again oldValue = get(key); } else { // nothing to do. Leave things as they were. return null; } Although i am somewhat inclined to do away with the contains check (given nulls are not supported), so things are just left alone. Do you wanna report the issue here: http://bugreport.java.com/ Thanks, Paul. > On 8 Dec 2015, at 11:12, Jaromir Hamala wrote: > > Hi, > > I stumbled upon an interesting issue with default implementation of > `compute(K key, BiFunction > remappingFunction)` in JDK8 `ConcurrentMap`. > According to its contract the default method implementation assumes map > implementations do not support null values. > > This is the begin of the default implementation: > > default V compute(K key, BiFunction > remappingFunction) { > Objects.requireNonNull(remappingFunction); > V oldValue = get(key); > for(;;) { > V newValue = remappingFunction.apply(key, oldValue); > if (newValue == null) { > // delete mapping > if (oldValue != null || containsKey(key)) { > // something to remove > if (remove(key, oldValue)) { > [...] > > > Let's say we have an empty map and 2 threads: > T1 is calling the `compute('foo', someFunction)` > T2 is concurrently calling calling `put('foo', 'bar');` > > so the T1 will get `oldValue = null`, but `containsKey()` will return > `true` - because T2 already created the mapping `foo -> bar`. Hence T1 will > call `remove('foo', null)` ! > > Contract of `remove()` says: `throws NullPointerException if the specified > key or value is null, and this map does not permit null keys or values > optional.` -> the T1 will throw NPE. > Is it a bug in default method impl or do I understand it wrong? > > Cheers, > Jaromir > > -- > ?Perfection is achieved, not when there is nothing more to add, but when > there is nothing left to take away.? > Antoine de Saint Exup?ry From roland.westrelin at oracle.com Wed Dec 9 13:27:28 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Dec 2015 14:27:28 +0100 Subject: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables In-Reply-To: References: Message-ID: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ The hotspot changes look good to me. Roland. From vitalyd at gmail.com Wed Dec 9 13:45:39 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 Dec 2015 08:45:39 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5667F4A1.7080800@gmail.com> References: <560D3F61.6040607@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <5667DE4B.80409@oracle.com> <5667F4A1.7080800@gmail.com> Message-ID: At the risk of going off topic with respect to this thread, I really think java should allow specifying at least what should be captured explicitly (if unspecified, behaves like today). It's counterintuitive that capturing just a field of 'this' captures the entire object, although some other languages do the same. sent from my phone On Dec 9, 2015 4:30 AM, "Peter Levart" wrote: > > > On 12/09/2015 08:54 AM, David Holmes wrote: > >> On 9/12/2015 5:05 PM, Peter Levart wrote: >> >>> Hi, >>> >>> I think the only way to try to prevent such things is with a good >>> example in javadoc that "screams" of possible miss-usages. >>> >> >> Problem is that many people - myself included - would not have a clue >> when a lambda "captures this"! Is that part of lambda expressions or a >> consequence of the current implementation? >> >> David >> > > I can't seem to find anything about capturing variables by lambda > expressions in JLS (except the talk about definitely assigned local > variables). I think lambdas ware meant to act like anonymous inner classes. > What they do is they capture a variable not the value variable has at > capture time. For locals this is the same, as lambdas and anonymous inner > classes only allow capturing "effectively final" and "definitely assigned" > local variables, which means only locals that don't change the value after > they are captured. With fields this is different. Instance fields are never > really final (even if declared final). And as fields are implemented, they > can not exist without the object that contains them... > > Regards, Peter > > P.S. The difference between anonymous inner class creation expression and > lambda expression is that in instance scope, anonymous inner class always > "captures" the outer instance while lambda expression only if it has to. > > >> >>> public static class CleanerExample implements AutoCloseable { >>> >>> private static final Cleaner cleaner = ...; // preferably a >>> shared cleaner >>> >>> private final PrivateNativeResource pnr; >>> >>> private final Cleaner.Cleanable cleanable; >>> >>> public CleanerExample(args, ...) { >>> >>> // prepare captured state as local vars... >>> PrivateNativeResource _pnr = ...; >>> >>> this.cleanable = cleaner.register(this, () -> { >>> // DON'T capture any instance fields with lambda since >>> that would >>> // capture 'this' and prevent it from becoming >>> phantom-reachable!!! >>> _pnr.close(); >>> }); >>> >>> this.pnr = _pnr; >>> } >>> >>> public void close() { >>> cleanable.clean(); >>> } >>> >>> >>> Regards, Peter >>> >>> On 12/09/2015 05:15 AM, Vitaly Davidovich wrote: >>> >>>> This has the same problem, doesn't it? The bottom line is if the >>>> lambda is () -> you're getting a >>>> capture of `this`. >>>> >>>> On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs >>> > wrote: >>>> >>>> Hi, >>>> >>>> Another option that should always capture is to define a specific >>>> static method with the needed values as arguments: >>>> >>>> >>>> public static class CleanerExample implements AutoCloseable { >>>> >>>> FileDescriptor fd = ...; >>>> >>>> private static final Cleaner cleaner = Cleaner.create(); >>>> >>>> private final Cleaner.Cleanable cleanable = >>>> cleaner.register(this,*() -> cleanup(fd)*); >>>> >>>> @Override >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> >>>> *static void cleanup(FileDescriptor fd ...) {** >>>> ** fd.close();** >>>> ** }* >>>> >>>> } >>>> >>>> On 12/8/2015 4:24 PM, Peter Levart wrote: >>>> >>>> >>>> >>>> On 12/08/2015 08:08 PM, Steven Schlansker wrote: >>>> >>>> On Dec 8, 2015, at 10:51 AM, Peter >>>> Levart>>> > wrote: >>>> >>>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>>> >>>> private final Cleaner.Cleanable cleanable >>>> = cleaner.register(this, () -> fd.close()); >>>> >>>> Sorry Roger, but this example is flawed. This is >>>> tricky! The lambda "() -> fd.close()" captures 'this', >>>> not only 'fd' as can be seen by running the following >>>> example: >>>> To correct that, but still use lambda, you would have >>>> to capture a local variable >>>> >>>> It looks like using "fd::close" might also work, and is >>>> more concise: >>>> >>>> IntSupplier x = () -> 10; >>>> IntSupplier xS = x::getAsInt; >>>> >>>> @Test >>>> public void test() { >>>> System.out.println(xS.getAsInt()); >>>> x = () -> 15; >>>> System.out.println(xS.getAsInt()); >>>> } >>>> >>>> 10 >>>> 10 >>>> >>>> >>>> Yes, good idea. This is a pre-bound method reference (the part >>>> on the left of '::' is evaluated immediately). Contrast to >>>> lambda, where "fd.close()" is an expression in the lambda body >>>> which is evaluated when lambda is invoked and that expression >>>> is composed of a field get + method invocation. In order to >>>> get an instance field, the object containing it must be >>>> captured. >>>> >>>> So for Roger's example, this will work: >>>> >>>> >>>> public static class CleanerExample implements AutoCloseable >>>> { >>>> >>>> FileDescriptor fd = ...; >>>> >>>> private static final Cleaner cleaner = Cleaner.create(); >>>> >>>> private final Cleaner.Cleanable cleanable = >>>> cleaner.register(this, fd::close); >>>> >>>> @Override >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> } >>>> >>>> >>>> ...if FileDescriptor.close() is an instance method with no >>>> arguments and doesn't throw any checked exceptions. >>>> >>>> >>>> Regards, Peter >>>> >>>> I'll work the example into the javadoc. >>>> >>>> Roger >>>> >>>> >>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>> >>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>> >>>> Actually I'm having more doubts about this >>>> API. >>>> >>>> Library writers use finalize() as a last >>>> ditch cleanup mechanism in >>>> case the user doesn't explicitly call any >>>> "cleanup" method. So as a >>>> library writer I would think I am now >>>> expected to register my >>>> instances with a Cleaner and provide a >>>> Runnable that does what >>>> finalize() would have done. But in that >>>> usage pattern the end user of >>>> my objects never has any access to my >>>> Cleanables so can never call >>>> clean() themselves - instead they should >>>> be calling the cleanup >>>> function directly, just as they would >>>> previously. So the whole "invoke >>>> at most once" for the clean() method seems >>>> somewhat unnecessary; and >>>> the way we should write the cleanup method >>>> and the Runnable need to be >>>> more cleary explained as the idempotentcy >>>> of the cleanup needs to be >>>> handled in the library writers code not >>>> the Cleaner/Clenable >>>> implementation. >>>> >>>> David >>>> >>>> Hi David, (once again for the list) >>>> >>>> I agree that an example would be most helpful. >>>> Here's how a normal finalizable object is >>>> typically coded: >>>> >>>> public class FinalizeExample implements >>>> AutoCloseable { >>>> >>>> private boolean closed; >>>> >>>> @Override >>>> public synchronized void close() { >>>> if (!closed) { >>>> closed = true; >>>> // cleanup actions accessing >>>> state of FinalizeExample, executed at most once >>>> } >>>> } >>>> >>>> @Override >>>> protected void finalize() throws >>>> Throwable { >>>> close(); >>>> } >>>> } >>>> >>>> >>>> Re-factoring to use Cleaner is a process that >>>> extracts the state representing native >>>> resource from the user-facing class into a >>>> private nested static class and makes the >>>> user-facing object just a facade that has >>>> access to the state object and is registered >>>> with a Cleaner. The Cleaner.Cleanable instance >>>> is also made accessible from the user-facing >>>> object, so it can provide the on-demand >>>> cleaning: >>>> >>>> public static class CleanerExample >>>> implements AutoCloseable { >>>> >>>> private static class State implements >>>> Runnable { >>>> @Override >>>> public void run() { >>>> // cleanup actions accessing >>>> State, executed at most once >>>> } >>>> } >>>> >>>> private static final Cleaner cleaner = >>>> Cleaner.create(); >>>> >>>> private final State state = new State(); >>>> private final Cleaner.Cleanable >>>> cleanable = cleaner.register(this, state); >>>> >>>> @Override >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>> >>>> Hi Roger, >>>> >>>> Sorry I had no choice but to look at >>>> this more closely ... and apologies >>>> as this is very late feedback ... I >>>> only looked at the API not the >>>> details of the implementation. >>>> >>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for the comments, >>>> >>>> Updated the javadoc and webrev >>>> with editorial changes. >>>> >>>> >>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> >>>> >>>> >>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>> >>>> >>>> >>>> Should cleaning and cleanables be >>>> mentioned as part of the package-doc >>>> for java.lang.ref? Else they seem to >>>> be an overlooked add-on not part of >>>> the core reference related >>>> functionality. Perhaps even state how >>>> they >>>> are preferred to use of finalization? >>>> >>>> Cleaner.Cleanable: >>>> >>>> It was unclear to me what the usage >>>> model was for this. I'm assuming >>>> that the intent is that rather than >>>> register a "thunk" (lets call it an >>>> "action") that can be invoked directly >>>> by user-code, the user should >>>> invoke the action via the call to >>>> clean(). In which case I think it >>>> should be explained somewhat more >>>> clearly - see below. >>>> >>>> I would describe the Cleanable class as: >>>> >>>> Cleanable: Represents an object that >>>> has been registered for cleanup by >>>> a Cleaner. The object can be cleaned >>>> directly, by a call to clean(), if >>>> it is no longer to be used, else it >>>> will be cleaned automatically when >>>> the object becomes phantom-reachable. >>>> >>>> Cleanable.clean: Unregisters this >>>> Cleanable and performs the cleanup >>>> action that was associated with it. If >>>> this Cleanable has already been >>>> unregistered nothing happens. The >>>> cleanup action is invoked at most once >>>> per registered Cleanable, regardless >>>> of the number of calls to clean(). >>>> >>>> --- >>>> >>>> Looking at Cleaner .... >>>> >>>> >>>> "Cleaner manages a set of object >>>> references and corresponding cleaning >>>> functions" >>>> >>>> I would say "cleaning actions" rather >>>> than functions as they yield no >>>> value. This change needs to be made >>>> throughout. >>>> >>>> "The most efficient use is to >>>> explicitly invoke the clean method when >>>> the object is closed or no longer >>>> needed. The cleaning function is a >>>> Runnable to be invoked at most once >>>> when the object is no longer >>>> reachable unless it has already been >>>> explicitly cleaned." >>>> >>>> To me this doesn't quite capture the >>>> need to not use the Runnable >>>> directly. I would rephrase: >>>> >>>> "In normal use a object should be >>>> cleaned up when no longer required, by >>>> invoking the clean() method of the >>>> associated Cleanable. This guarantees >>>> that the cleaning action will be >>>> performed at most once per object: >>>> either explicitly, or automatically if >>>> it becomes phantom-reachable. If >>>> cleaned explicitly the object should >>>> not be used again. Note that the >>>> cleaning action must not refer to the >>>> object ..." >>>> >>>> --- >>>> >>>> Question: what happens if an object is >>>> registered simultaneously with >>>> multiple Cleaners? Do we need to warn >>>> the user against that? >>>> >>>> --- >>>> >>>> The phrase "process the unreachable >>>> objects and to invoke cleaning >>>> functions" doesn't quite seem right to >>>> me. The objects themselves are >>>> never processed, or even touched - >>>> right? So really the thread is >>>> started to "invoke the cleanup actions >>>> for unreachable objects". >>>> >>>> create(): can also throw >>>> SecurityException if not allowed to >>>> create/start threads. >>>> >>>> register(Object obj, Runnable thunk): >>>> thunk -> action >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 12/6/15 7:46 PM, David Holmes >>>> wrote: >>>> >>>> Hi Roger, >>>> >>>> Sorry to be late here but was >>>> trying not to get involved :) >>>> >>>> It is already implicit that >>>> ThreadFactory.newThread should >>>> return >>>> unstarted threads - that is >>>> what a new Thread is - so I >>>> don't think >>>> IllegalThreadStateException >>>> needs to be documented here as >>>> it is >>>> documenting behaviour of a >>>> broken ThreadFactory (and a >>>> broken >>>> ThreadFactory could throw >>>> anything) . >>>> >>>> It does seem that new is fairly >>>> well understood but one can read of >>>> ThreadFactory is as a bit >>>> ambiguous, lacking a direct >>>> reference to the >>>> Thread.State of the new thread >>>> and since it allows various >>>> attributes of the thread to be >>>> modified >>>> after the constructor. >>>> Since the runnable is supplied as >>>> an argument it is ready to be >>>> started, >>>> why not. >>>> It seemed useful to reinforce the >>>> salient points. >>>> >>>> Also the no-arg cleaner() can >>>> also throw SecurityException. >>>> >>>> The thread construction is done in >>>> doPriv so it should not throw. >>>> Did I miss some edge case? >>>> >>>> Also this: >>>> >>>> 127 * On each call the >>>> {@link >>>> ThreadFactory#newThread(Runnable) >>>> thread factory} >>>> 128 * should return a >>>> {@link Thread.State#NEW new >>>> thread} with >>>> an appropriate >>>> 129 * {@linkplain >>>> Thread#getContextClassLoader >>>> context class >>>> loader}, >>>> 130 * {@linkplain >>>> Thread#getName() name}, >>>> 131 * {@linkplain >>>> Thread#getPriority() priority}, >>>> 132 * permissions, etc. >>>> >>>> then begs the questions as to >>>> what is "appropriate". I think >>>> this can >>>> be said much more simply as: >>>> "The ThreadFactory must >>>> provide a Thread >>>> that is suitable for >>>> performing the cleaning work". >>>> Though even that >>>> raises questions. I'm not sure >>>> why a ThreadFactory is >>>> actually needed >>>> here ?? Special security >>>> context? If so that could be >>>> mentioned, but I >>>> don't think name or priority >>>> need to be discussed. >>>> >>>> It was intended to prod the client >>>> to be deliberate about the >>>> threadFactory. >>>> Since the client is integrating >>>> the Cleaner and respective cleaning >>>> functions >>>> with the client code, the >>>> ThreadFactory makes it possible >>>> for the >>>> client to >>>> initialize a suitable thread and >>>> the comments serve as a reminder. >>>> I agree that the phrase 'suitable >>>> for performing the cleaning work' is >>>> the operative one. >>>> >>>> Thanks, Roger >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> >>>> >>> > From sgehwolf at redhat.com Wed Dec 9 13:55:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 14:55:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1448975945.4309.16.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> Message-ID: <1449669302.3543.62.camel@redhat.com> On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > Hi Jaroslav, > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > incorporates > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability- > > > > > dev > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > look at > > > > > this > > > > > as well? Thank you! > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > sponsor for > > > > this. > > > > > > Anyone? > > > > I'm sorry for not spotting this earlier: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- > > ssl-factory- > > changes/jdk/src/java.management/share/classes/sun/management/jmxrem > > ote/ConnectorBootstrap.java.sdiff.html > > * L442 - the log would contain 'com.sun.management.jmxremote.host > > =? > > null' if host is not specified; might be better not to print this > > out at all > > Updated webrev which does not print > 'com.sun.management.jmxremote.host = null' if unset: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > Other than that the change looks good to me. If no one else is > > volunteering I may sponsor this change. > > Thank you! Jaroslav, are you still willing to sponsor this? There hasn't been much movement :-/ Thanks, Severin From jaroslav.bachorik at oracle.com Wed Dec 9 13:58:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 14:58:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1449669302.3543.62.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> Message-ID: <5668336A.3010406@oracle.com> On 9.12.2015 14:55, Severin Gehwolf wrote: > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: >> Hi Jaroslav, >> >> On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: >>> On 1.12.2015 11:17, Severin Gehwolf wrote: >>>> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >>>>> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Updated webrev with jtreg test in Java: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>> >>>>>> I believe this updated webrev addresses all concerns and >>>>>> incorporates >>>>>> suggestions brought up by Jaroslav and Daniel. >>>>>> >>>>>> I'm still looking for a sponsor and a hotspot/servicability- >>>>>> dev >>>>>> reviewer. Could somebody maintaining javax.rmi.ssl have a >>>>>> look at >>>>>> this >>>>>> as well? Thank you! >>>>> >>>>> Ping? Friendly reminder that I still need reviewers and a >>>>> sponsor for >>>>> this. >>>> >>>> Anyone? >>> >>> I'm sorry for not spotting this earlier: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- >>> ssl-factory- >>> changes/jdk/src/java.management/share/classes/sun/management/jmxrem >>> ote/ConnectorBootstrap.java.sdiff.html >>> * L442 - the log would contain 'com.sun.management.jmxremote.host >>> = >>> null' if host is not specified; might be better not to print this >>> out at all >> >> Updated webrev which does not print >> 'com.sun.management.jmxremote.host = null' if unset: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ >> >>> Other than that the change looks good to me. If no one else is >>> volunteering I may sponsor this change. >> >> Thank you! > > Jaroslav, are you still willing to sponsor this? There hasn't been much > movement :-/ Sure. I need to start the compatibility review process before integration and it might take some time. -JB- > > Thanks, > Severin > From vitalyd at gmail.com Wed Dec 9 14:03:36 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 Dec 2015 09:03:36 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5667D2BC.2030505@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> Message-ID: Unfortunately I think you're right that docs with loud warnings is the best that can be done here. But this will become fertile ground for leaks nonetheless. IDEs will need to be taught not to suggest any refactoring that may start capturing 'this'. sent from my phone On Dec 9, 2015 2:05 AM, "Peter Levart" wrote: > Hi, > > I think the only way to try to prevent such things is with a good example > in javadoc that "screams" of possible miss-usages. > > > public static class CleanerExample implements AutoCloseable { > > private static final Cleaner cleaner = ...; // preferably a shared > cleaner > > private final PrivateNativeResource pnr; > > private final Cleaner.Cleanable cleanable; > > public CleanerExample(args, ...) { > > // prepare captured state as local vars... > PrivateNativeResource _pnr = ...; > > this.cleanable = cleaner.register(this, () -> { > // DON'T capture any instance fields with lambda since > that would > // capture 'this' and prevent it from becoming > phantom-reachable!!! > _pnr.close(); > }); > > this.pnr = _pnr; > } > > public void close() { > cleanable.clean(); > } > > > Regards, Peter > > On 12/09/2015 05:15 AM, Vitaly Davidovich wrote: > > This has the same problem, doesn't it? The bottom line is if the lambda is > () -> you're getting a capture of `this`. > > On Tue, Dec 8, 2015 at 5:08 PM, Roger Riggs > wrote: > >> Hi, >> >> Another option that should always capture is to define a specific static >> method with the needed values as arguments: >> >> >> public static class CleanerExample implements AutoCloseable { >> >> FileDescriptor fd = ...; >> >> private static final Cleaner cleaner = Cleaner.create(); >> >> private final Cleaner.Cleanable cleanable = >> cleaner.register(this,*() -> cleanup(fd)*); >> >> @Override >> public void close() { >> cleanable.clean(); >> } >> >> *static void cleanup(FileDescriptor fd ...) {** >> ** fd.close();** >> ** }* >> >> } >> >> On 12/8/2015 4:24 PM, Peter Levart wrote: >> >>> >>> >>> On 12/08/2015 08:08 PM, Steven Schlansker wrote: >>> >>>> On Dec 8, 2015, at 10:51 AM, Peter Levart >>>> wrote: >>>> >>>>> On 12/08/2015 04:34 PM, Roger Riggs wrote: >>>>> >>>>>> private final Cleaner.Cleanable cleanable = >>>>>> cleaner.register(this, () -> fd.close()); >>>>>> >>>>> Sorry Roger, but this example is flawed. This is tricky! The lambda >>>>> "() -> fd.close()" captures 'this', not only 'fd' as can be seen by running >>>>> the following example: >>>>> To correct that, but still use lambda, you would have to capture a >>>>> local variable >>>>> >>>> It looks like using "fd::close" might also work, and is more concise: >>>> >>>> IntSupplier x = () -> 10; >>>> IntSupplier xS = x::getAsInt; >>>> >>>> @Test >>>> public void test() { >>>> System.out.println(xS.getAsInt()); >>>> x = () -> 15; >>>> System.out.println(xS.getAsInt()); >>>> } >>>> >>>> 10 >>>> 10 >>>> >>> >>> Yes, good idea. This is a pre-bound method reference (the part on the >>> left of '::' is evaluated immediately). Contrast to lambda, where >>> "fd.close()" is an expression in the lambda body which is evaluated when >>> lambda is invoked and that expression is composed of a field get + method >>> invocation. In order to get an instance field, the object containing it >>> must be captured. >>> >>> So for Roger's example, this will work: >>> >>> >>> public static class CleanerExample implements AutoCloseable { >>> >>> FileDescriptor fd = ...; >>> >>> private static final Cleaner cleaner = Cleaner.create(); >>> >>> private final Cleaner.Cleanable cleanable = >>> cleaner.register(this, fd::close); >>> >>> @Override >>> public void close() { >>> cleanable.clean(); >>> } >>> } >>> >>> >>> ...if FileDescriptor.close() is an instance method with no arguments and >>> doesn't throw any checked exceptions. >>> >>> >>> Regards, Peter >>> >>> I'll work the example into the javadoc. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> On 12/08/2015 07:25 AM, Peter Levart wrote: >>>>>> >>>>>>> On 12/08/2015 09:22 AM, David Holmes wrote: >>>>>>> >>>>>>>> Actually I'm having more doubts about this API. >>>>>>>> >>>>>>>> Library writers use finalize() as a last ditch cleanup mechanism in >>>>>>>> case the user doesn't explicitly call any "cleanup" method. So as a >>>>>>>> library writer I would think I am now expected to register my >>>>>>>> instances with a Cleaner and provide a Runnable that does what >>>>>>>> finalize() would have done. But in that usage pattern the end user >>>>>>>> of >>>>>>>> my objects never has any access to my Cleanables so can never call >>>>>>>> clean() themselves - instead they should be calling the cleanup >>>>>>>> function directly, just as they would previously. So the whole >>>>>>>> "invoke >>>>>>>> at most once" for the clean() method seems somewhat unnecessary; and >>>>>>>> the way we should write the cleanup method and the Runnable need to >>>>>>>> be >>>>>>>> more cleary explained as the idempotentcy of the cleanup needs to be >>>>>>>> handled in the library writers code not the Cleaner/Clenable >>>>>>>> implementation. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>> Hi David, (once again for the list) >>>>>>> >>>>>>> I agree that an example would be most helpful. Here's how a normal >>>>>>> finalizable object is typically coded: >>>>>>> >>>>>>> public class FinalizeExample implements AutoCloseable { >>>>>>> >>>>>>> private boolean closed; >>>>>>> >>>>>>> @Override >>>>>>> public synchronized void close() { >>>>>>> if (!closed) { >>>>>>> closed = true; >>>>>>> // cleanup actions accessing state of >>>>>>> FinalizeExample, executed at most once >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> protected void finalize() throws Throwable { >>>>>>> close(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Re-factoring to use Cleaner is a process that extracts the state >>>>>>> representing native resource from the user-facing class into a private >>>>>>> nested static class and makes the user-facing object just a facade that has >>>>>>> access to the state object and is registered with a Cleaner. The >>>>>>> Cleaner.Cleanable instance is also made accessible from the user-facing >>>>>>> object, so it can provide the on-demand cleaning: >>>>>>> >>>>>>> public static class CleanerExample implements AutoCloseable { >>>>>>> >>>>>>> private static class State implements Runnable { >>>>>>> @Override >>>>>>> public void run() { >>>>>>> // cleanup actions accessing State, executed at most >>>>>>> once >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> private static final Cleaner cleaner = Cleaner.create(); >>>>>>> >>>>>>> private final State state = new State(); >>>>>>> private final Cleaner.Cleanable cleanable = >>>>>>> cleaner.register(this, state); >>>>>>> >>>>>>> @Override >>>>>>> public void close() { >>>>>>> cleanable.clean(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> On 8/12/2015 6:09 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> Hi Roger, >>>>>>>>> >>>>>>>>> Sorry I had no choice but to look at this more closely ... and >>>>>>>>> apologies >>>>>>>>> as this is very late feedback ... I only looked at the API not the >>>>>>>>> details of the implementation. >>>>>>>>> >>>>>>>>> On 8/12/2015 4:50 AM, Roger Riggs wrote: >>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thanks for the comments, >>>>>>>>>> >>>>>>>>>> Updated the javadoc and webrev with editorial changes. >>>>>>>>>> >>>>>>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>>>>>> >>>>>>>>> Should cleaning and cleanables be mentioned as part of the >>>>>>>>> package-doc >>>>>>>>> for java.lang.ref? Else they seem to be an overlooked add-on not >>>>>>>>> part of >>>>>>>>> the core reference related functionality. Perhaps even state how >>>>>>>>> they >>>>>>>>> are preferred to use of finalization? >>>>>>>>> >>>>>>>>> Cleaner.Cleanable: >>>>>>>>> >>>>>>>>> It was unclear to me what the usage model was for this. I'm >>>>>>>>> assuming >>>>>>>>> that the intent is that rather than register a "thunk" (lets call >>>>>>>>> it an >>>>>>>>> "action") that can be invoked directly by user-code, the user >>>>>>>>> should >>>>>>>>> invoke the action via the call to clean(). In which case I think it >>>>>>>>> should be explained somewhat more clearly - see below. >>>>>>>>> >>>>>>>>> I would describe the Cleanable class as: >>>>>>>>> >>>>>>>>> Cleanable: Represents an object that has been registered for >>>>>>>>> cleanup by >>>>>>>>> a Cleaner. The object can be cleaned directly, by a call to >>>>>>>>> clean(), if >>>>>>>>> it is no longer to be used, else it will be cleaned automatically >>>>>>>>> when >>>>>>>>> the object becomes phantom-reachable. >>>>>>>>> >>>>>>>>> Cleanable.clean: Unregisters this Cleanable and performs the >>>>>>>>> cleanup >>>>>>>>> action that was associated with it. If this Cleanable has already >>>>>>>>> been >>>>>>>>> unregistered nothing happens. The cleanup action is invoked at >>>>>>>>> most once >>>>>>>>> per registered Cleanable, regardless of the number of calls to >>>>>>>>> clean(). >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Looking at Cleaner .... >>>>>>>>> >>>>>>>>> >>>>>>>>> "Cleaner manages a set of object references and corresponding >>>>>>>>> cleaning >>>>>>>>> functions" >>>>>>>>> >>>>>>>>> I would say "cleaning actions" rather than functions as they yield >>>>>>>>> no >>>>>>>>> value. This change needs to be made throughout. >>>>>>>>> >>>>>>>>> "The most efficient use is to explicitly invoke the clean method >>>>>>>>> when >>>>>>>>> the object is closed or no longer needed. The cleaning function is >>>>>>>>> a >>>>>>>>> Runnable to be invoked at most once when the object is no longer >>>>>>>>> reachable unless it has already been explicitly cleaned." >>>>>>>>> >>>>>>>>> To me this doesn't quite capture the need to not use the Runnable >>>>>>>>> directly. I would rephrase: >>>>>>>>> >>>>>>>>> "In normal use a object should be cleaned up when no longer >>>>>>>>> required, by >>>>>>>>> invoking the clean() method of the associated Cleanable. This >>>>>>>>> guarantees >>>>>>>>> that the cleaning action will be performed at most once per object: >>>>>>>>> either explicitly, or automatically if it becomes >>>>>>>>> phantom-reachable. If >>>>>>>>> cleaned explicitly the object should not be used again. Note that >>>>>>>>> the >>>>>>>>> cleaning action must not refer to the object ..." >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Question: what happens if an object is registered simultaneously >>>>>>>>> with >>>>>>>>> multiple Cleaners? Do we need to warn the user against that? >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> The phrase "process the unreachable objects and to invoke cleaning >>>>>>>>> functions" doesn't quite seem right to me. The objects themselves >>>>>>>>> are >>>>>>>>> never processed, or even touched - right? So really the thread is >>>>>>>>> started to "invoke the cleanup actions for unreachable objects". >>>>>>>>> >>>>>>>>> create(): can also throw SecurityException if not allowed to >>>>>>>>> create/start threads. >>>>>>>>> >>>>>>>>> register(Object obj, Runnable thunk): thunk -> action >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/6/15 7:46 PM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Hi Roger, >>>>>>>>>>> >>>>>>>>>>> Sorry to be late here but was trying not to get involved :) >>>>>>>>>>> >>>>>>>>>>> It is already implicit that ThreadFactory.newThread should return >>>>>>>>>>> unstarted threads - that is what a new Thread is - so I don't >>>>>>>>>>> think >>>>>>>>>>> IllegalThreadStateException needs to be documented here as it is >>>>>>>>>>> documenting behaviour of a broken ThreadFactory (and a broken >>>>>>>>>>> ThreadFactory could throw anything) . >>>>>>>>>>> >>>>>>>>>> It does seem that new is fairly well understood but one can read >>>>>>>>>> of >>>>>>>>>> ThreadFactory is as a bit ambiguous, lacking a direct reference >>>>>>>>>> to the >>>>>>>>>> Thread.State of the new thread >>>>>>>>>> and since it allows various attributes of the thread to be >>>>>>>>>> modified >>>>>>>>>> after the constructor. >>>>>>>>>> Since the runnable is supplied as an argument it is ready to be >>>>>>>>>> started, >>>>>>>>>> why not. >>>>>>>>>> It seemed useful to reinforce the salient points. >>>>>>>>>> >>>>>>>>>>> Also the no-arg cleaner() can also throw SecurityException. >>>>>>>>>>> >>>>>>>>>> The thread construction is done in doPriv so it should not throw. >>>>>>>>>> Did I miss some edge case? >>>>>>>>>> >>>>>>>>>>> Also this: >>>>>>>>>>> >>>>>>>>>>> 127 * On each call the {@link >>>>>>>>>>> ThreadFactory#newThread(Runnable) >>>>>>>>>>> thread factory} >>>>>>>>>>> 128 * should return a {@link Thread.State#NEW new thread} >>>>>>>>>>> with >>>>>>>>>>> an appropriate >>>>>>>>>>> 129 * {@linkplain Thread#getContextClassLoader context class >>>>>>>>>>> loader}, >>>>>>>>>>> 130 * {@linkplain Thread#getName() name}, >>>>>>>>>>> 131 * {@linkplain Thread#getPriority() priority}, >>>>>>>>>>> 132 * permissions, etc. >>>>>>>>>>> >>>>>>>>>>> then begs the questions as to what is "appropriate". I think >>>>>>>>>>> this can >>>>>>>>>>> be said much more simply as: "The ThreadFactory must provide a >>>>>>>>>>> Thread >>>>>>>>>>> that is suitable for performing the cleaning work". Though even >>>>>>>>>>> that >>>>>>>>>>> raises questions. I'm not sure why a ThreadFactory is actually >>>>>>>>>>> needed >>>>>>>>>>> here ?? Special security context? If so that could be mentioned, >>>>>>>>>>> but I >>>>>>>>>>> don't think name or priority need to be discussed. >>>>>>>>>>> >>>>>>>>>> It was intended to prod the client to be deliberate about the >>>>>>>>>> threadFactory. >>>>>>>>>> Since the client is integrating the Cleaner and respective >>>>>>>>>> cleaning >>>>>>>>>> functions >>>>>>>>>> with the client code, the ThreadFactory makes it possible for the >>>>>>>>>> client to >>>>>>>>>> initialize a suitable thread and the comments serve as a reminder. >>>>>>>>>> I agree that the phrase 'suitable for performing the cleaning >>>>>>>>>> work' is >>>>>>>>>> the operative one. >>>>>>>>>> >>>>>>>>>> Thanks, Roger >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>> >> > > From sgehwolf at redhat.com Wed Dec 9 14:13:01 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 15:13:01 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <5668336A.3010406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> <5668336A.3010406@oracle.com> Message-ID: <1449670381.3543.63.camel@redhat.com> On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote: > On 9.12.2015 14:55, Severin Gehwolf wrote: > > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > > > Hi Jaroslav, > > > > > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > > > > > 02/ > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > > > incorporates > > > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > > > > > I'm still looking for a sponsor and a > > > > > > > hotspot/servicability- > > > > > > > dev > > > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > > > look at > > > > > > > this > > > > > > > as well? Thank you! > > > > > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > > > sponsor for > > > > > > this. > > > > > > > > > > Anyone? > > > > > > > > I'm sorry for not spotting this earlier: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no- > > > > rmi- > > > > ssl-factory- > > > > changes/jdk/src/java.management/share/classes/sun/management/jm > > > > xrem > > > > ote/ConnectorBootstrap.java.sdiff.html > > > > * L442 - the log would contain > > > > 'com.sun.management.jmxremote.host > > > > = > > > > null' if host is not specified; might be better not to print > > > > this > > > > out at all > > > > > > Updated webrev which does not print > > > 'com.sun.management.jmxremote.host = null' if unset: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > > > > > Other than that the change looks good to me. If no one else is > > > > volunteering I may sponsor this change. > > > > > > Thank you! > > > > Jaroslav, are you still willing to sponsor this? There hasn't been > > much > > movement :-/ > > Sure. I need to start the compatibility review process before > integration and it might take some time. OK. Thanks for the heads-up! Cheers, Severin > -JB- > > > > > Thanks, > > Severin > > > From chris.hegarty at oracle.com Wed Dec 9 15:03:46 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Dec 2015 15:03:46 +0000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5667D2BC.2030505@gmail.com> References: <560D3F61.6040607@Oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> Message-ID: <566842D2.1080200@oracle.com> Peter, On 09/12/15 07:05, Peter Levart wrote: > Hi, > > I think the only way to try to prevent such things is with a good > example in javadoc that "screams" of possible miss-usages. > > > public static class CleanerExample implements AutoCloseable { > > private static final Cleaner cleaner = ...; // preferably a > shared cleaner > > private final PrivateNativeResource pnr; > > private final Cleaner.Cleanable cleanable; > > public CleanerExample(args, ...) { > > // prepare captured state as local vars... > PrivateNativeResource _pnr = ...; > > this.cleanable = cleaner.register(this, () -> { > // DON'T capture any instance fields with lambda since > that would > // capture 'this' and prevent it from becoming I assume that the WARNING should include anonymous inner classes too ( which I expect are quite common, though less now with lambda ) ? Is "leaking" 'this' in a constructor a potential issue with respect to the visibility of pnr? As well as causing red-squiggly lines in the IDE ;-) -Chris. > phantom-reachable!!! > _pnr.close(); > }); > > this.pnr = _pnr; > } > > public void close() { > cleanable.clean(); > } > > > Regards, Peter > From peter.levart at gmail.com Wed Dec 9 16:04:51 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 9 Dec 2015 17:04:51 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566842D2.1080200@oracle.com> References: <560D3F61.6040607@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> Message-ID: <56685123.5030402@gmail.com> Hi Chris, On 12/09/2015 04:03 PM, Chris Hegarty wrote: > Peter, > > On 09/12/15 07:05, Peter Levart wrote: >> Hi, >> >> I think the only way to try to prevent such things is with a good >> example in javadoc that "screams" of possible miss-usages. >> >> >> public static class CleanerExample implements AutoCloseable { >> >> private static final Cleaner cleaner = ...; // preferably a >> shared cleaner >> >> private final PrivateNativeResource pnr; >> >> private final Cleaner.Cleanable cleanable; >> >> public CleanerExample(args, ...) { >> >> // prepare captured state as local vars... >> PrivateNativeResource _pnr = ...; >> >> this.cleanable = cleaner.register(this, () -> { >> // DON'T capture any instance fields with lambda since >> that would >> // capture 'this' and prevent it from becoming > > I assume that the WARNING should include anonymous inner classes too > ( which I expect are quite common, though less now with lambda ) ? > > Is "leaking" 'this' in a constructor a potential issue with respect > to the visibility of pnr? As well as causing red-squiggly lines in > the IDE ;-) 'this' only leaks to the 'referent' field of PhantomReference where by definition is not accessible. 'this' can become phantom-reachable before CleanerExample constructor ends. But this is harmless, because the code that may execute at that time does not access the object any more, so the object may be safely collected. Cleanup action can run at any time after registration even before CleanerExample constructor ends. But this is harmless too, because it only accesses PrivateNativeResource which is fully constructed before registration of cleanup action. I see no issues apart from IDE(s) not seeing no issues. Regards, Peter > > -Chris. > > >> phantom-reachable!!! >> _pnr.close(); >> }); >> >> this.pnr = _pnr; >> } >> >> public void close() { >> cleanable.clean(); >> } >> >> >> Regards, Peter >> From vincent.x.ryan at oracle.com Wed Dec 9 16:44:41 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 9 Dec 2015 16:44:41 +0000 Subject: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently In-Reply-To: <56670120.3010603@oracle.com> References: <5666E27F.1080100@oracle.com> <5666FB2E.7010304@oracle.com> <56670120.3010603@oracle.com> Message-ID: <983633EC-0E3F-42E9-8639-6CF3D613F8B9@oracle.com> This change to restructure the test looks fine. Thanks. > On 8 Dec 2015, at 16:11, Rob McKenna wrote: > > Thanks, just spotted that myself after attempting to run it in a loop via jtreg. (in case jtreg is somehow involved in causing the intermittent failure) Will be corrected pre-push. > > -Rob > > On 08/12/15 15:45, Daniel Fuchs wrote: >> Hey Rob, >> >> The @run line seems to be wrong in the new test file: >> >> 26 * @run main/othervm LdapTimeoutTest >> >> cheers, >> >> -- daniel >> >> On 08/12/15 15:00, Rob McKenna wrote: >>> Hi folks, >>> >>> Hopefully this fix puts this tests' failures to bed. (mind you I've >>> thought that before) >>> >>> Basically I've separated the failing subtest out into its own file and >>> excluded it on the (intermittently) failing platforms. >>> >>> http://cr.openjdk.java.net/~robm/8141370/webrev.01/ >>> >>> -Rob >> From xueming.shen at oracle.com Wed Dec 9 16:49:44 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 9 Dec 2015 08:49:44 -0800 Subject: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16 In-Reply-To: <56681416.1030406@oracle.com> References: <56681416.1030406@oracle.com> Message-ID: <56685BA8.8040302@oracle.com> +1 On 12/9/15 3:44 AM, Chris Hegarty wrote: > Looks like the Compact Strings work inadvertently introduced a > dependency on sun.misc.Unsafe. ( just temporary confusion with > having two Unsafes until the jdk.unsupported module is defined ) > > diff --git a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > --- a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > +++ b/src/java.base/share/classes/sun/nio/cs/StringUTF16.java > @@ -25,8 +25,8 @@ > > package sun.nio.cs; > > -import static sun.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; > -import static sun.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; > +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_BASE_OFFSET; > +import static jdk.internal.misc.Unsafe.ARRAY_BYTE_INDEX_SCALE; > > class StringUTF16 { > > @@ -35,5 +35,5 @@ > ARRAY_BYTE_BASE_OFFSET + > ARRAY_BYTE_INDEX_SCALE * index * 2L); > } > > - private static final sun.misc.Unsafe unsafe = > sun.misc.Unsafe.getUnsafe(); > + private static final jdk.internal.misc.Unsafe unsafe = > jdk.internal.misc.Unsafe.getUnsafe(); > } > > -Chris. From mark.reinhold at oracle.com Wed Dec 9 16:58:28 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 09 Dec 2015 08:58:28 -0800 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <566785AC.1000007@oracle.com> References: , <566785AC.1000007@oracle.com> Message-ID: <20151209085828.144998@eggemoggin.niobe.net> 2015/12/8 5:36 -0800, david.holmes at oracle.com: > On 9/12/2015 12:15 AM, Chris Hegarty wrote: >> ... >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ > > Addition to Thread looks good to me. > > I vote in favor of maintaining consistency of the existing Thread > construction patterns. Builders or whatever can be added later as a > separate RFE if considered desirable. I agree -- the new constructor is a bit wordy, with five parameters, but this is unlikely to be used all that broadly. Introducing an entirely new way to create threads, with a fluent builder API or whatever, can come later. - Mark From claes.redestad at oracle.com Wed Dec 9 17:14:22 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 09 Dec 2015 18:14:22 +0100 Subject: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character In-Reply-To: <56681A19.6080502@oracle.com> References: <564B532E.6000906@oracle.com> <142916502.1330400.1447794836696.JavaMail.zimbra@u-pem.fr> <564BA577.1030701@oracle.com> <564CFB05.8080901@oracle.com> <565EF117.5090804@oracle.com> <56681A19.6080502@oracle.com> Message-ID: <5668616E.2060509@oracle.com> Thanks Vladimir! /Claes On 2015-12-09 13:10, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/2/15 4:24 PM, Claes Redestad wrote: >> >> On 2015-11-18 23:26, Aleksey Shipilev wrote: >>> By the way, I see there is a cleaner way to implement emitIconstInsn, >>> see java.lang.invoke.TypeConvertingMethodAdapter.iconst: >>> >>> void iconst(final int cst) { >>> if (cst >= -1 && cst <= 5) { >>> mv.visitInsn(Opcodes.ICONST_0 + cst); >>> } else if (cst >= Byte.MIN_VALUE && cst <= Byte.MAX_VALUE) { >>> mv.visitIntInsn(Opcodes.BIPUSH, cst); >>> } else if (cst >= Short.MIN_VALUE && cst <= Short.MAX_VALUE) { >>> mv.visitIntInsn(Opcodes.SIPUSH, cst); >>> } else { >>> mv.visitLdcInsn(cst); >>> } >>> } >>> >>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/aa9e8b3916ae/src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java#l285 >>> >>> >>> >> >> Nice catch. >> >> Picking up this tiny improvement again, I realized there are a few other >> bytecode minifying tricks we could consider while we're at it: >> >> http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ >> >> It would probably make sense to move emitConst to >> TypeConvertingMethodAdapter and use that in place a raw MethodVisitor - >> removing some code - but there might be some reasons not to >> (bootstrapping?). For this improvement I opt to keep the changes >> contained inside InvokerBytecodeGenerator. unless someone insists. >> >> /Claes From martinrb at google.com Wed Dec 9 17:16:13 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Dec 2015 09:16:13 -0800 Subject: Potential performance improvement for java.util.AbstractList? In-Reply-To: References: Message-ID: On Tue, Dec 8, 2015 at 10:17 PM, Nicholas Cull wrote: > Yes, the time performance of size() appears to be unspecified by the whole > Collections framework: the implementation of equals() in AbstractSet uses > size() as an optimization, though AbstractCollection does not. Naively it seems > odd that we don't perform this check inside AbstractList. What contract is > AbstractList implying that would be broken by doing so? Using size in AbstracList is not unreasonable. size is rather likely to be O(1) because the List interface is concurrency-hostile. OTOH creating ListIterators and each check of equality for an index is also O(1), so this is a significant optimization only for lists that generally share a common prefix. And sorry, but that's not a good enough reason to change AbstractList. Especially given that the current implementation is specified! It's easier adding optimized equals methods to subclasses. It's more reasonable for AbstractSet to call size() because you cannot have O(1) element by element comparison. You have to call set.contains which is much more likely to be O(N). From john.r.rose at oracle.com Wed Dec 9 17:48:41 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Dec 2015 09:48:41 -0800 Subject: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character In-Reply-To: <565EF117.5090804@oracle.com> References: <564B532E.6000906@oracle.com> <142916502.1330400.1447794836696.JavaMail.zimbra@u-pem.fr> <564BA577.1030701@oracle.com> <564CFB05.8080901@oracle.com> <565EF117.5090804@oracle.com> Message-ID: On Dec 2, 2015, at 5:24 AM, Claes Redestad wrote: > > Picking up this tiny improvement again, I realized there are a few other bytecode minifying tricks we could consider while we're at it: > > http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ Ah, constant-generation code. Need I point out that this is a deliciously slippery slope? For example, (1L << N) can be generated in 3-4 bytes with no constant pool entry. An arbitrary int or long can be composed without a CP entry; there's a bewildering range of more specialized patterns that would be more compact than burning a CP entry. Remember that CP entries are a limited resource; there are at most 2^16. I'm *not* saying we should go down that slope any further. ? John P.S. Full disclosure: I have spent many happy hours obsessing about the corresponding problem for SPARC. http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/cpu/sparc/vm/macroAssembler_sparc.cpp#l957 There's a lot you can do with shifts and xors, inside a 5-instruction budget. For example, long strings of the same bit value are easy to materialize. So are larger repeated patterns. From Roger.Riggs at Oracle.com Wed Dec 9 18:40:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 9 Dec 2015 13:40:26 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56685123.5030402@gmail.com> References: <560D3F61.6040607@Oracle.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> Message-ID: <5668759A.1070204@Oracle.com> Hi, The example is revised to caution about inner classes and lambdas. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger On 12/9/2015 11:04 AM, Peter Levart wrote: > Hi Chris, > > On 12/09/2015 04:03 PM, Chris Hegarty wrote: >> Peter, >> >> On 09/12/15 07:05, Peter Levart wrote: >>> Hi, >>> >>> I think the only way to try to prevent such things is with a good >>> example in javadoc that "screams" of possible miss-usages. >>> >>> >>> public static class CleanerExample implements AutoCloseable { >>> >>> private static final Cleaner cleaner = ...; // preferably a >>> shared cleaner >>> >>> private final PrivateNativeResource pnr; >>> >>> private final Cleaner.Cleanable cleanable; >>> >>> public CleanerExample(args, ...) { >>> >>> // prepare captured state as local vars... >>> PrivateNativeResource _pnr = ...; >>> >>> this.cleanable = cleaner.register(this, () -> { >>> // DON'T capture any instance fields with lambda since >>> that would >>> // capture 'this' and prevent it from becoming >> >> I assume that the WARNING should include anonymous inner classes too >> ( which I expect are quite common, though less now with lambda ) ? >> >> Is "leaking" 'this' in a constructor a potential issue with respect >> to the visibility of pnr? As well as causing red-squiggly lines in >> the IDE ;-) > > 'this' only leaks to the 'referent' field of PhantomReference where by > definition is not accessible. > > 'this' can become phantom-reachable before CleanerExample constructor > ends. But this is harmless, because the code that may execute at that > time does not access the object any more, so the object may be safely > collected. > > Cleanup action can run at any time after registration even before > CleanerExample constructor ends. But this is harmless too, because it > only accesses PrivateNativeResource which is fully constructed before > registration of cleanup action. > > I see no issues apart from IDE(s) not seeing no issues. > > Regards, Peter > >> >> -Chris. >> >> >>> phantom-reachable!!! >>> _pnr.close(); >>> }); >>> >>> this.pnr = _pnr; >>> } >>> >>> public void close() { >>> cleanable.clean(); >>> } >>> >>> >>> Regards, Peter >>> > From chris.hegarty at oracle.com Wed Dec 9 20:59:53 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Dec 2015 20:59:53 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <20151209085828.144998@eggemoggin.niobe.net> References: , <566785AC.1000007@oracle.com> <20151209085828.144998@eggemoggin.niobe.net> Message-ID: <8B7B0629-5E2A-4A5C-AC7E-859ACF98DAE0@oracle.com> David, Mandy, Mark, Roger, Thanks for your feedback. I understand that ?stackSize? is rarely used, but to avoid having to provide more than one additional constructor I opted to keep it. If someone really wants to create a Thread with a specific stack size and not inherit initial inheritable thread-local values, then they can. As was said, this will not be that commonly used. I?ll finalise this as is, unless there are any objections. -Chris. On 9 Dec 2015, at 16:58, mark.reinhold at oracle.com wrote: > 2015/12/8 5:36 -0800, david.holmes at oracle.com: >> On 9/12/2015 12:15 AM, Chris Hegarty wrote: >>> ... >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ >> >> Addition to Thread looks good to me. >> >> I vote in favor of maintaining consistency of the existing Thread >> construction patterns. Builders or whatever can be added later as a >> separate RFE if considered desirable. > > I agree -- the new constructor is a bit wordy, with five parameters, but > this is unlikely to be used all that broadly. Introducing an entirely > new way to create threads, with a fluent builder API or whatever, can > come later. > > - Mark From chris.hegarty at oracle.com Wed Dec 9 21:05:00 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Dec 2015 21:05:00 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <5666EE0B.7040703@redhat.com> References: <5666EE0B.7040703@redhat.com> Message-ID: <2F5FFB56-AC37-4A8E-8DB5-8E0E51CB1A6A@oracle.com> On 8 Dec 2015, at 14:49, David M. Lloyd wrote: > Great! Now all we need is a way to tell threads to remove all thread locals on exit, and the scourge of ITL might be somewhat mitigated. :-) David, The fields of Thread that hold references to TLs and ITLs are cleared at exit, as seen from the snippet below. Or have I missed your point? public class Thread { .. private void exit() { if (group != null) { group.threadTerminated(this); group = null; } /* Aggressively null out all reference fields: see bug 4006245 */ target = null; /* Speed the release of some of these resources */ threadLocals = null; inheritableThreadLocals = null; inheritedAccessControlContext = null; blocker = null; uncaughtExceptionHandler = null; } } -Chris. > On 12/08/2015 08:15 AM, Chris Hegarty wrote: >> Many threads created by the platform are short lived and perform some >> simple async operation on behalf of the platform. These threads typically >> use/extend sun.misc.ManagedLocalsThread. This is a convenient internal >> API that can be used to create threads that do not wish to inherit initial >> values from inheritable thread-local variables. >> >> I'd like to propose an additional java.lang.Thread constructor that exposes >> the ability to explicitly "opt out" of inheriting these initial values ( from >> inheritable thread-local variables ). This seems like useful general >> functionality, given the amount of usage in the JDK of the internal API. >> >> This new public API can then be used to replace usages of the internal >> sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted >> the usage in the sources of the base module. Other modules can be done >> as a follow up. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8056152 >> > > -- > - DML From huizhe.wang at oracle.com Wed Dec 9 22:37:59 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 09 Dec 2015 14:37:59 -0800 Subject: RFR (JAXP): 8072081 : Supplementary characters are rejected in comments Message-ID: <5668AD47.2040608@oracle.com> Hi, Please review https://bugs.openjdk.java.net/browse/JDK-8072081. Supplementary characters are supported as character data in xml 1.0, and also names in xml 1.1. This patch fixed the bug that rejected supplementary characters in comments, and also made sure they are accepted in names. webrev: http://cr.openjdk.java.net/~joehw/jdk9/8072081/webrev/ Thanks, Joe From martinrb at google.com Wed Dec 9 23:18:16 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Dec 2015 15:18:16 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> Message-ID: I finally studied ForkJoinTask.getThrowableException - I was not aware that we were doing reflection based exception cloning. In practice it probably muddles through, but it just seems too hacky to use in a java core library. We're relying on common conventions, but in principle we are invoking random code with an unknown spec. The stack traces created are fake in the sense that they are not created naturally, and the thrown exception may differ from the original in significant ways, most notably missing the message string. With heroic efforts we can make it safer, e.g. examine the bytecode for the constructors we are invoking, and check whether they call the super constructors in the right way, but that will be a major engineering project by itself. For CompletableFuture.whenComplete: I also keep moving in the direction of less magic. It is perfectly possible for a well-written whenComplete action to catch all Throwables, add the source exception as a suppressed exception, and rethrow. In fact, perhaps people have already tried this and discovered we incorrectly throw the source exception. I think we should really accept our mistake and switch to throwing the action exception rather than the source exception. Perhaps we should only call addSuppressed if the source exception is not already in the list of suppressed exceptions. On Thu, Dec 3, 2015 at 9:54 AM, Jason Mehrens wrote: > Hi Peter, > > I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: > 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) > 2. Walk the type of the cause and super types by calling getConstructor(type of cause, String) (I've seen this but, I can't seem to find an example) > 3. getConstructor(String) + initCause (java.io.InvalidObjectException) > 4. Walk the type of the cause and super types by calling getConstructor(type of cause). (java.awt.print.PrinterIOException) > 5. getConstructor() + initCause. (java.nio.BufferOverflowException) > 6. Look at the return type of methods declared in the cause type and assume there is a constructor matching the type or no repeating types. (java.nio.charset.MalformedInputException, java.lang.EnumConstantNotPresentException, java.util.regex.PatternSyntaxException) > > In the end all of that can still fail. Exceptions can be private subclasses of public classes so that gets interesting with reflection too. > > Jason > > > =========== > What about the 4th option (keep current behavior, but try the > best-effort with reflection to make new exception of the same type): > > ... > } catch (Throwable ex) { > if (x == null) { > x = ex; > } else { > // try to create new exception with same: > // type, cause, suppressed exceptions and > stack-trace... > Throwable nx; > Class xClass = x.getClass(); > try { > Constructor xConstr = > xClass.getConstructor(Throwable.class); > nx = (Throwable) xConstr.newInstance(x.getCause()); > } catch (Exception e1) { > try { > nx = (Throwable) xClass.newInstance(); > nx.initCause(x.getCause()); > } catch (Exception e2) { > // no luck > nx = null; > } > } > if (nx != null) { > // inherit stack-trace of original exception > nx.setStackTrace(x.getStackTrace()); > // inherit suppressed exceptions > for (Throwable sx : x.getSuppressed()) { > nx.addSuppressed(sx); > } > // add 'ex' as a final suppressed exception > nx.addSuppressed(ex); > x = nx; > } > } > } > completeThrowable(x, r); > > ... > > > > Note that such code and similar code in > ForkJoinTask.getThrowableException will probably have to be modified for > jigsaw to include dynamic addition of read-edge to the module of > exception class... > > Regards, Peter > From stuart.marks at oracle.com Wed Dec 9 23:20:15 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Dec 2015 15:20:15 -0800 Subject: RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232) In-Reply-To: <5666F013.7090105@oracle.com> References: <565E590D.3090007@oracle.com> <5662122A.7020303@oracle.com> <5666222A.5070204@oracle.com> <5666F013.7090105@oracle.com> Message-ID: <5668B72F.7030101@oracle.com> On 12/8/15 6:58 AM, Maurizio Cimadamore wrote: > I'm not too worried about the fact that typing 'EnumSet' is more verbose than > just 'Set', obviously; but it would seem reasonable to try (within reasonable > bounds) to provide uniform way to create collections and a smooth user experience. > > I think with the current status quo, we have that: > > Set.of(A, B, C) != EnumSet.of(A, B, C) > > and that's surprising, IMHO. At the same time I notice that, even with the > overload I suggest, they would still be different beasts, as one would be > mutable, while the other would not. > > That said, I think we should aim for an API where such bad surprises are avoided > (why is my enumset so slow? Ah - it's not an enumset because I used the wrong > XYZ.of method); unfortunately I don't have a good suggestion on how to get there > :-( (which might mean that what you did is correct :-) ) Hm. OK, it's not obvious to me what should be done here, but there are enough things going on that I thought it was reasonable to open an RFE to cover this space. See https://bugs.openjdk.java.net/browse/JDK-8145048 Feel free to add comments. s'marks From stuart.marks at oracle.com Thu Dec 10 00:22:34 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Dec 2015 16:22:34 -0800 Subject: RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method Message-ID: <5668C5CA.4050402@oracle.com> Hi all, Joe Darcy pointed out that API changes I pushed into jdk9-dev yesterday are missing wildcards from the Map.ofEntries() method. Please see this bug: https://bugs.openjdk.java.net/browse/JDK-8144952 The Map.ofEntries() method currently has the following declaration: static Map ofEntries(Entry... entries) it should be changed to static Map ofEntries(Entry... entries) This doesn't make all that much difference in practice. For example, this works: Map map1 = MapOfEntries(entry(1, 2.0), entry(3.0f, 4L)); However, this does not: Map.Entry e1 = Map.entry(1, 2.0); Map.Entry e2 = Map.entry(3.0f, 4L); Map map = Map.ofEntries(e1, e2); After adding the wildcards, the latter example compiles fine. This is a pretty unusual case, but for maximum flexibility it's probably a good idea to add the wildcards anyway. Please review the diff appended below. Thanks, s'marks # HG changeset patch # User smarks # Date 1449706837 28800 # Wed Dec 09 16:20:37 2015 -0800 # Node ID b6540a8b7ab064600fe49a8bc678ad96127090ca # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 8144952: add wildcards to the Map.ofEntries() method Reviewed-by: XXX diff -r 7f644a5d554a -r b6540a8b7ab0 src/java.base/share/classes/java/util/Map.java --- a/src/java.base/share/classes/java/util/Map.java Wed Dec 09 15:27:21 2015 -0500 +++ b/src/java.base/share/classes/java/util/Map.java Wed Dec 09 16:20:37 2015 -0800 @@ -1670,9 +1670,9 @@ */ @SafeVarargs @SuppressWarnings("varargs") - static Map ofEntries(Entry... entries) { + static Map ofEntries(Entry... entries) { Map map = new HashMap<>(entries.length * 4 / 3 + 1); // throws NPE if entries is null - for (Entry e : entries) { + for (Entry e : entries) { // next line throws NPE if e is null map.put(Objects.requireNonNull(e.getKey()), Objects.requireNonNull(e.getValue())); } diff -r 7f644a5d554a -r b6540a8b7ab0 test/java/util/Map/MapFactories.java --- a/test/java/util/Map/MapFactories.java Wed Dec 09 15:27:21 2015 -0500 +++ b/test/java/util/Map/MapFactories.java Wed Dec 09 16:20:37 2015 -0800 @@ -377,4 +377,13 @@ assertEquals(sie.toString(), kvh1.toString()); } + // compile-time test of wildcards + @Test + public void entryWildcardTests() { + Map.Entry e1 = Map.entry(1, 2.0); + Map.Entry e2 = Map.entry(3.0f, 4L); + Map map = Map.ofEntries(e1, e2); + assertEquals(map.size(), 2); + } + } From joe.darcy at oracle.com Thu Dec 10 00:31:32 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 09 Dec 2015 16:31:32 -0800 Subject: RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method In-Reply-To: <5668C5CA.4050402@oracle.com> References: <5668C5CA.4050402@oracle.com> Message-ID: <5668C7E4.2010700@oracle.com> Looks fine Stuart; thanks, -Joe On 12/9/2015 4:22 PM, Stuart Marks wrote: > Hi all, > > > Joe Darcy pointed out that API changes I pushed into jdk9-dev > yesterday are missing wildcards from the Map.ofEntries() method. > Please see this bug: > > https://bugs.openjdk.java.net/browse/JDK-8144952 > > The Map.ofEntries() method currently has the following declaration: > > static Map ofEntries(Entry... entries) > > it should be changed to > > static Map ofEntries(Entry... > entries) > > This doesn't make all that much difference in practice. For example, > this works: > > Map map1 = MapOfEntries(entry(1, 2.0), entry(3.0f, > 4L)); > > However, this does not: > > Map.Entry e1 = Map.entry(1, 2.0); > Map.Entry e2 = Map.entry(3.0f, 4L); > Map map = Map.ofEntries(e1, e2); > > After adding the wildcards, the latter example compiles fine. This is > a pretty unusual case, but for maximum flexibility it's probably a > good idea to add the wildcards anyway. > > Please review the diff appended below. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1449706837 28800 > # Wed Dec 09 16:20:37 2015 -0800 > # Node ID b6540a8b7ab064600fe49a8bc678ad96127090ca > # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 > 8144952: add wildcards to the Map.ofEntries() method > Reviewed-by: XXX > > diff -r 7f644a5d554a -r b6540a8b7ab0 > src/java.base/share/classes/java/util/Map.java > --- a/src/java.base/share/classes/java/util/Map.java Wed Dec 09 > 15:27:21 2015 -0500 > +++ b/src/java.base/share/classes/java/util/Map.java Wed Dec 09 > 16:20:37 2015 -0800 > @@ -1670,9 +1670,9 @@ > */ > @SafeVarargs > @SuppressWarnings("varargs") > - static Map ofEntries(Entry... entries) { > + static Map ofEntries(Entry V>... entries) { > Map map = new HashMap<>(entries.length * 4 / 3 + 1); // > throws NPE if entries is null > - for (Entry e : entries) { > + for (Entry e : entries) { > // next line throws NPE if e is null > map.put(Objects.requireNonNull(e.getKey()), > Objects.requireNonNull(e.getValue())); > } > diff -r 7f644a5d554a -r b6540a8b7ab0 test/java/util/Map/MapFactories.java > --- a/test/java/util/Map/MapFactories.java Wed Dec 09 15:27:21 2015 > -0500 > +++ b/test/java/util/Map/MapFactories.java Wed Dec 09 16:20:37 2015 > -0800 > @@ -377,4 +377,13 @@ > assertEquals(sie.toString(), kvh1.toString()); > } > > + // compile-time test of wildcards > + @Test > + public void entryWildcardTests() { > + Map.Entry e1 = Map.entry(1, 2.0); > + Map.Entry e2 = Map.entry(3.0f, 4L); > + Map map = Map.ofEntries(e1, e2); > + assertEquals(map.size(), 2); > + } > + > } From joe.darcy at oracle.com Thu Dec 10 01:09:29 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 09 Dec 2015 17:09:29 -0800 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> Message-ID: <5668D0C9.6010806@oracle.com> Hi Joel, Sorry for the delay in reviewing. For the specification, it should seem reasonable to me to have the default implementation of AnnotatedType.getAnnotatedOwnerType() to return null rather than throwing an UnsupportedOperationException. Following experience with similar structures in the javax.lang.model APIs, e.g. JDK-7015530: Reiterate API specializations in javax.lang.model.element subinterfaces http://cr.openjdk.java.net/~darcy/7015530.1/ I think it is clearer to readers of the specification if description of behavior like // Supertype /** * In these subtypes, do this. In these other subtypes, do that. */ void foo(); is additionally copied down and specialized into the subtypes, even if trivial overriden methods are defined whose only purpose is to serve as a hook to hang the javadoc. What do you think? Thanks, -Joe On 12/7/2015 12:43 PM, Joel Borggr?n-Franck wrote: > Hi Paul, > > See inline, > > On Mon, 7 Dec 2015 at 21:39 Paul Benedict wrote: > >> Joel, some comments on AnnotatedType#getAnnotatedOwnerType(): >> >> * Is it convention to use

    tags to describe the complexity of the >> return value vs. just explaining it all in the @return tag? >> >> It is for the Core Reflection javadocs. Compare with > j.l.Class.get(Declared)Thing. > > >> * What is the convention for @see nowadays? Is it 1.9 or 9? >> >> > Good question. Anyone? I'll grep for 1.9 if it is still there in lots of > places I would expect "someone else" to do a big cleanup job. > > cheers > /Joel From brian.burkhalter at oracle.com Thu Dec 10 01:41:29 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Dec 2015 17:41:29 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <565E648C.9040304@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> Message-ID: <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> Hi Joe, On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy wrote: > Current version looks okay. One more request, before pushing please add explicit test cases for the for the largest number having 63 bits and the smallest number having 64 bits. No need for another round of webrevs for that. Well there is after all a need for another round of review: http://cr.openjdk.java.net/~bpb/8032027/webrev.04/ That was a good call to add the above tests: one of them failed. This was found to be due to a floor() where there should have been a ceil(). Summary: MutableBigInteger: at line 1920 change Math.floor(.) to Math.ceil(.). BigIntegerTest: at lines 331-340 add testing of 2^N and 2^N - 1, 0 < N < 1024 Thanks, Brian From stuart.marks at oracle.com Thu Dec 10 01:47:32 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Dec 2015 17:47:32 -0800 Subject: question on jdk_collections group in jdk/test/TEST.groups Message-ID: <5668D9B4.5040408@oracle.com> Hi, maybe somebody can fill me in on the history here. There's a nice test group called jdk_collections defined in jdk/test/TEST.groups. It runs the tests for the collections in java/util (but not java/util/concurrent) and it excludes all the stuff in java/util that isn't collections-related. Well, not really. The jdk_collections group excludes the java/util/Deque and java/util/PriorityQueue tests. Those are in the jdk_concurrent test group, and there's a note there that those are maintained by "JSR-166 (Doug Lea et al)". I'm dimly aware that some of the newer non-concurrent collections like Deque and PQ came in via the various JSR-166 efforts. Is it still useful to preserve this distinction in the TEST.groups file? It seems to me that, as much as possible, the jdk_collections group should include the "core collections" tests and the jdk_concurrent group should include the tests for the j.u.c stuff. s'marks From joe.darcy at oracle.com Thu Dec 10 02:11:41 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 09 Dec 2015 18:11:41 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> Message-ID: <5668DF5D.2040908@oracle.com> Hi Brian, New version looks good. One more case to try: start with a BigInteger that would overflow to Double.POSITIVE_INFINITY when the doubleValue method was called. If this case doesn't take too long to run, it would be a fine additional case to add to the test. 2^1024 should be fine input value. More precisely, (new BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE); should do the trick. If the code passes with this value, you're okay to push. Well, while you're at it, might as well verify (new BigDecimal(Double.MAX_VALUE)).toBigInteger() behaves well too ;-) Thanks, -Joe On 12/9/2015 5:41 PM, Brian Burkhalter wrote: > Hi Joe, > > On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy > wrote: > >> Current version looks okay. One more request, before pushing please >> add explicit test cases for the for the largest number having 63 bits >> and the smallest number having 64 bits. No need for another round of >> webrevs for that. > > Well there is after all a need for another round of review: > > http://cr.openjdk.java.net/~bpb/8032027/webrev.04/ > > > That was a good call to add the above tests: one of them failed. This > was found to be due to a floor() where there should have been a ceil(). > > Summary: > > MutableBigInteger: at line 1920 change Math.floor(.) to Math.ceil(.). > BigIntegerTest: at lines 331-340 add testing of 2^N and 2^N - 1, 0 < N > < 1024 > > Thanks, > > Brian From wasserman.louis at gmail.com Thu Dec 10 02:22:56 2015 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Thu, 10 Dec 2015 02:22:56 +0000 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <5668DF5D.2040908@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> <5668DF5D.2040908@oracle.com> Message-ID: Guava's tests check the explicit definition of square root (mentioned by Joe above) on 2^n +/- 1 for all n up to Double.MAX_EXPONENT + 1, because why not? On Wed, Dec 9, 2015 at 6:12 PM Joseph D. Darcy wrote: > Hi Brian, > > New version looks good. > > One more case to try: start with a BigInteger that would overflow to > Double.POSITIVE_INFINITY when the doubleValue method was called. If this > case doesn't take too long to run, it would be a fine additional case to > add to the test. 2^1024 should be fine input value. More precisely, > > (new > BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE); > > should do the trick. If the code passes with this value, you're okay to > push. Well, while you're at it, might as well verify > > (new BigDecimal(Double.MAX_VALUE)).toBigInteger() > > behaves well too ;-) > > Thanks, > > -Joe > > On 12/9/2015 5:41 PM, Brian Burkhalter wrote: > > Hi Joe, > > > > On Dec 1, 2015, at 7:25 PM, Joseph D. Darcy > > wrote: > > > >> Current version looks okay. One more request, before pushing please > >> add explicit test cases for the for the largest number having 63 bits > >> and the smallest number having 64 bits. No need for another round of > >> webrevs for that. > > > > Well there is after all a need for another round of review: > > > > http://cr.openjdk.java.net/~bpb/8032027/webrev.04/ > > > > > > That was a good call to add the above tests: one of them failed. This > > was found to be due to a floor() where there should have been a ceil(). > > > > Summary: > > > > MutableBigInteger: at line 1920 change Math.floor(.) to Math.ceil(.). > > BigIntegerTest: at lines 331-340 add testing of 2^N and 2^N - 1, 0 < N > > < 1024 > > > > Thanks, > > > > Brian > > From lance.andersen at oracle.com Thu Dec 10 02:43:56 2015 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 9 Dec 2015 21:43:56 -0500 Subject: RFR (JAXP): 8072081 : Supplementary characters are rejected in comments In-Reply-To: <5668AD47.2040608@oracle.com> References: <5668AD47.2040608@oracle.com> Message-ID: <023EDF9F-574D-452C-BE6F-20B613405E2D@oracle.com> Hi joe, Looks ok. Assume the jck runs clean as well? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad > On Dec 9, 2015, at 5:37 PM, huizhe wang wrote: > > Hi, > > Please review https://bugs.openjdk.java.net/browse/JDK-8072081. Supplementary characters are supported as character data in xml 1.0, and also names in xml 1.1. This patch fixed the bug that rejected supplementary characters in comments, and also made sure they are accepted in names. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk9/8072081/webrev/ > > Thanks, > Joe > From stuart.marks at oracle.com Thu Dec 10 02:54:36 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Dec 2015 18:54:36 -0800 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> Message-ID: <5668E96C.2020101@oracle.com> Hi Shinya, Thanks for doing this work. This looks very nice! (And thanks to Paul for helping move it through the process.) I have only a minor comment, which is that it might be good to clarify in the example why a filtering collector is necessary instead of just adding a filter() step into the stream. (This is what prompted Henry Jen's question, and it was my initial thought too.) Maybe it would be sufficient to add something like the following after the example: ? A filtering collector differs from a stream's {@code filter()} operation. In this example, suppose there are no employees whose salary is above the threshold in some department. Using a filtering collector as shown above would result in a mapping from that department to an empty {@code Set}. If a stream {@code filter()} operation were done instead, there would be no mapping for that department at all. ? s'marks On 12/8/15 4:21 AM, ShinyaYoshida wrote: > Hi Stefan, > Thank you for pointing out. > I've just updated: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.03/ > > Regards, > shinyafox(Shinya Yoshida) > > 2015-12-08 21:08 GMT+09:00 Stefan Zobel : > >> Hi shinyafox, >> >> minor typo in the code example: >> >> >> s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment >> >> >> Regards, >> Stefan >> >> >> 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : >>> Thank you so much! >>> I've updated in webrev.02. >>> >>> Best regard, >>> shinyafox(Shinya Yoshida) >>> >> From jason_mehrens at hotmail.com Thu Dec 10 03:52:31 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 10 Dec 2015 03:52:31 +0000 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> , Message-ID: Not saying that ForkJoinTask and JDBC go together but, this is from the java.sql.SQLException source code : ============ public SQLException(String reason, Throwable cause) { super(reason,cause); if (!(this instanceof SQLWarning)) { if (DriverManager.getLogWriter() != null) { printStackTrace(DriverManager.getLogWriter()); } } } ========= Yikes! Kind of proves point about not knowing the spec. Jason ________________________________________ From: Martin Buchholz Sent: Wednesday, December 9, 2015 5:18 PM To: Jason Mehrens; Doug Lea Cc: Peter Levart; core-libs-dev Subject: Re: RFR: jsr166 jdk9 integration wave 2 I finally studied ForkJoinTask.getThrowableException - I was not aware that we were doing reflection based exception cloning. In practice it probably muddles through, but it just seems too hacky to use in a java core library. We're relying on common conventions, but in principle we are invoking random code with an unknown spec. The stack traces created are fake in the sense that they are not created naturally, and the thrown exception may differ from the original in significant ways, most notably missing the message string. With heroic efforts we can make it safer, e.g. examine the bytecode for the constructors we are invoking, and check whether they call the super constructors in the right way, but that will be a major engineering project by itself. For CompletableFuture.whenComplete: I also keep moving in the direction of less magic. It is perfectly possible for a well-written whenComplete action to catch all Throwables, add the source exception as a suppressed exception, and rethrow. In fact, perhaps people have already tried this and discovered we incorrectly throw the source exception. I think we should really accept our mistake and switch to throwing the action exception rather than the source exception. Perhaps we should only call addSuppressed if the source exception is not already in the list of suppressed exceptions. On Thu, Dec 3, 2015 at 9:54 AM, Jason Mehrens wrote: > Hi Peter, > > I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: > 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) > 2. Walk the type of the cause and super types by calling getConstructor(type of cause, String) (I've seen this but, I can't seem to find an example) > 3. getConstructor(String) + initCause (java.io.InvalidObjectException) > 4. Walk the type of the cause and super types by calling getConstructor(type of cause). (java.awt.print.PrinterIOException) > 5. getConstructor() + initCause. (java.nio.BufferOverflowException) > 6. Look at the return type of methods declared in the cause type and assume there is a constructor matching the type or no repeating types. (java.nio.charset.MalformedInputException, java.lang.EnumConstantNotPresentException, java.util.regex.PatternSyntaxException) > > In the end all of that can still fail. Exceptions can be private subclasses of public classes so that gets interesting with reflection too. > > Jason > > > =========== > What about the 4th option (keep current behavior, but try the > best-effort with reflection to make new exception of the same type): > > ... > } catch (Throwable ex) { > if (x == null) { > x = ex; > } else { > // try to create new exception with same: > // type, cause, suppressed exceptions and > stack-trace... > Throwable nx; > Class xClass = x.getClass(); > try { > Constructor xConstr = > xClass.getConstructor(Throwable.class); > nx = (Throwable) xConstr.newInstance(x.getCause()); > } catch (Exception e1) { > try { > nx = (Throwable) xClass.newInstance(); > nx.initCause(x.getCause()); > } catch (Exception e2) { > // no luck > nx = null; > } > } > if (nx != null) { > // inherit stack-trace of original exception > nx.setStackTrace(x.getStackTrace()); > // inherit suppressed exceptions > for (Throwable sx : x.getSuppressed()) { > nx.addSuppressed(sx); > } > // add 'ex' as a final suppressed exception > nx.addSuppressed(ex); > x = nx; > } > } > } > completeThrowable(x, r); > > ... > > > > Note that such code and similar code in > ForkJoinTask.getThrowableException will probably have to be modified for > jigsaw to include dynamic addition of read-edge to the module of > exception class... > > Regards, Peter > From huizhe.wang at oracle.com Thu Dec 10 04:12:50 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 09 Dec 2015 20:12:50 -0800 Subject: RFR (JAXP): 8072081 : Supplementary characters are rejected in comments In-Reply-To: <023EDF9F-574D-452C-BE6F-20B613405E2D@oracle.com> References: <5668AD47.2040608@oracle.com> <023EDF9F-574D-452C-BE6F-20B613405E2D@oracle.com> Message-ID: <5668FBC2.5040003@oracle.com> Thanks Lance! Yes, all tests passed. Best, Joe On 12/9/2015 6:43 PM, Lance @ Oracle wrote: > Hi joe, > > Looks ok. Assume the jck runs clean as well? > > Best > Lance > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > Sent from my iPad > > On Dec 9, 2015, at 5:37 PM, huizhe wang > wrote: > >> Hi, >> >> Please review https://bugs.openjdk.java.net/browse/JDK-8072081. >> Supplementary characters are supported as character data in xml 1.0, >> and also names in xml 1.1. This patch fixed the bug that rejected >> supplementary characters in comments, and also made sure they are >> accepted in names. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk9/8072081/webrev/ >> >> >> Thanks, >> Joe >> From sebastian.sickelmann at gmx.de Thu Dec 10 04:39:28 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 10 Dec 2015 05:39:28 +0100 Subject: RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs) In-Reply-To: <562EFE6F.7050407@gmx.de> References: <562EFE6F.7050407@gmx.de> Message-ID: <56690200.5070305@gmx.de> Hi, i wanted to start a discussion/review-process for JDK5108778 some time ago. Please see a previous try below. The patches are now pretty old, and I will rebase and update them to the created sub-issues - JDK-8143008 (jaxp) - JDK-8143009 (jaxws) - JDK-8143010 (corba) for a sub-repo-discussion/review/push-process after initial discussion has started. For now the webrev for the initial discussion i would love to use http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ -- Sebastian On 10/27/2015 05:32 AM, Sebastian Sickelmann wrote: > Hello, > > Actually I am searching through the JBS for low hanging fruits. > Right now i am looking through the openjdk-sources and try to evaluate > if i can make something about JDK-5108778. > > Please find my webrevs for the jaxp, jaxws and corba repos at: > > http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ > http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ > http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ > > I hope for jaxp,jaxws and corba this mailinglist is also the right place. > 8 > jaxp: > For the change in XBoolean (jaxp) i thought it would be more readable > than the autoboxing solution. > > jaxws: > The changes in jaxws are in a generated class. I would love to fix this > in the source, but i have no clue where the real source could be. > > corba: > For all calls against > com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the > valueOf solution instead of the autoboxing for better readability. > > -- Sebastian From peter.levart at gmail.com Thu Dec 10 08:04:18 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Dec 2015 09:04:18 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> Message-ID: <56693202.1060502@gmail.com> Hi Martin, On 12/10/2015 12:18 AM, Martin Buchholz wrote: > I finally studied ForkJoinTask.getThrowableException - I was not aware > that we were doing reflection based exception cloning. In practice it > probably muddles through, but it just seems too hacky to use in a java > core library. We're relying on common conventions, but in principle > we are invoking random code with an unknown spec. The stack traces > created are fake in the sense that they are not created naturally, and > the thrown exception may differ from the original in significant ways, > most notably missing the message string. With heroic efforts we can > make it safer, e.g. examine the bytecode for the constructors we are > invoking, and check whether they call the super constructors in the > right way, but that will be a major engineering project by itself. I assume the aim of exception cloning in ForkJoinTask.getThrowableException is to provide the user with a stack-trace that originates in its own thread. This helps trace the origin of the exception in case it's handled way up in the call stack. In addition, the original stack trace is also preserved (original exception is added as a cause). This case does not suffer from the visibility of original exception before ForkJoinTask.getThrowableException is called, so perhaps the aim could be achieved in a slightly different manner: just return the original exception, but add a newly constructed CrossThreadPropagationException as a suppressed exception to it. Printing such augmented original exception would then reveal both stack traces. What do you think? > > For CompletableFuture.whenComplete: I also keep moving in the > direction of less magic. It is perfectly possible for a well-written > whenComplete action to catch all Throwables, add the source exception > as a suppressed exception, and rethrow. In fact, perhaps people have > already tried this and discovered we incorrectly throw the source > exception. I think we should really accept our mistake and switch to > throwing the action exception rather than the source exception. > Perhaps we should only call addSuppressed if the source exception is > not already in the list of suppressed exceptions. Less is more. I would even not bother with the additional logic of conditionally adding source exception to the list of suppressed exceptions. I doubt many codes out there do that in the whenComplete handler since such exception was ignored up until now. And if anybody does that, she will get the source exception listed twice - not a big deal. If javadoc describes the behavior, this will not happen frequently. Regards, Peter > > > On Thu, Dec 3, 2015 at 9:54 AM, Jason Mehrens wrote: >> Hi Peter, >> >> I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: >> 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) >> 2. Walk the type of the cause and super types by calling getConstructor(type of cause, String) (I've seen this but, I can't seem to find an example) >> 3. getConstructor(String) + initCause (java.io.InvalidObjectException) >> 4. Walk the type of the cause and super types by calling getConstructor(type of cause). (java.awt.print.PrinterIOException) >> 5. getConstructor() + initCause. (java.nio.BufferOverflowException) >> 6. Look at the return type of methods declared in the cause type and assume there is a constructor matching the type or no repeating types. (java.nio.charset.MalformedInputException, java.lang.EnumConstantNotPresentException, java.util.regex.PatternSyntaxException) >> >> In the end all of that can still fail. Exceptions can be private subclasses of public classes so that gets interesting with reflection too. >> >> Jason >> >> >> =========== >> What about the 4th option (keep current behavior, but try the >> best-effort with reflection to make new exception of the same type): >> >> ... >> } catch (Throwable ex) { >> if (x == null) { >> x = ex; >> } else { >> // try to create new exception with same: >> // type, cause, suppressed exceptions and >> stack-trace... >> Throwable nx; >> Class xClass = x.getClass(); >> try { >> Constructor xConstr = >> xClass.getConstructor(Throwable.class); >> nx = (Throwable) xConstr.newInstance(x.getCause()); >> } catch (Exception e1) { >> try { >> nx = (Throwable) xClass.newInstance(); >> nx.initCause(x.getCause()); >> } catch (Exception e2) { >> // no luck >> nx = null; >> } >> } >> if (nx != null) { >> // inherit stack-trace of original exception >> nx.setStackTrace(x.getStackTrace()); >> // inherit suppressed exceptions >> for (Throwable sx : x.getSuppressed()) { >> nx.addSuppressed(sx); >> } >> // add 'ex' as a final suppressed exception >> nx.addSuppressed(ex); >> x = nx; >> } >> } >> } >> completeThrowable(x, r); >> >> ... >> >> >> >> Note that such code and similar code in >> ForkJoinTask.getThrowableException will probably have to be modified for >> jigsaw to include dynamic addition of read-edge to the module of >> exception class... >> >> Regards, Peter >> From paul.sandoz at oracle.com Thu Dec 10 08:47:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Dec 2015 09:47:25 +0100 Subject: RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method In-Reply-To: <5668C5CA.4050402@oracle.com> References: <5668C5CA.4050402@oracle.com> Message-ID: <8590D52D-56B1-43F3-917F-DB9F5E6C6C7A@oracle.com> +1 Paul. > # HG changeset patch > # User smarks > # Date 1449706837 28800 > # Wed Dec 09 16:20:37 2015 -0800 > # Node ID b6540a8b7ab064600fe49a8bc678ad96127090ca > # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 > 8144952: add wildcards to the Map.ofEntries() method > Reviewed-by: XXX > > diff -r 7f644a5d554a -r b6540a8b7ab0 src/java.base/share/classes/java/util/Map.java > --- a/src/java.base/share/classes/java/util/Map.java Wed Dec 09 15:27:21 2015 -0500 > +++ b/src/java.base/share/classes/java/util/Map.java Wed Dec 09 16:20:37 2015 -0800 > @@ -1670,9 +1670,9 @@ > */ > @SafeVarargs > @SuppressWarnings("varargs") > - static Map ofEntries(Entry... entries) { > + static Map ofEntries(Entry... entries) { > Map map = new HashMap<>(entries.length * 4 / 3 + 1); // throws NPE if entries is null > - for (Entry e : entries) { > + for (Entry e : entries) { > // next line throws NPE if e is null > map.put(Objects.requireNonNull(e.getKey()), Objects.requireNonNull(e.getValue())); > } > diff -r 7f644a5d554a -r b6540a8b7ab0 test/java/util/Map/MapFactories.java > --- a/test/java/util/Map/MapFactories.java Wed Dec 09 15:27:21 2015 -0500 > +++ b/test/java/util/Map/MapFactories.java Wed Dec 09 16:20:37 2015 -0800 > @@ -377,4 +377,13 @@ > assertEquals(sie.toString(), kvh1.toString()); > } > > + // compile-time test of wildcards > + @Test > + public void entryWildcardTests() { > + Map.Entry e1 = Map.entry(1, 2.0); > + Map.Entry e2 = Map.entry(3.0f, 4L); > + Map map = Map.ofEntries(e1, e2); > + assertEquals(map.size(), 2); > + } > + > } From chris.hegarty at oracle.com Thu Dec 10 09:10:53 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Dec 2015 09:10:53 +0000 Subject: RFR(s): JDK-8144952: add wildcards to the Map.ofEntries() method In-Reply-To: <5668C5CA.4050402@oracle.com> References: <5668C5CA.4050402@oracle.com> Message-ID: <8B3806A0-3891-4C07-AF31-283ED3C04F63@oracle.com> This looks good Stuart. -Chris. On 10 Dec 2015, at 00:22, Stuart Marks wrote: > Hi all, > > > Joe Darcy pointed out that API changes I pushed into jdk9-dev yesterday are missing wildcards from the Map.ofEntries() method. Please see this bug: > > https://bugs.openjdk.java.net/browse/JDK-8144952 > > The Map.ofEntries() method currently has the following declaration: > > static Map ofEntries(Entry... entries) > > it should be changed to > > static Map ofEntries(Entry... entries) > > This doesn't make all that much difference in practice. For example, this works: > > Map map1 = MapOfEntries(entry(1, 2.0), entry(3.0f, 4L)); > > However, this does not: > > Map.Entry e1 = Map.entry(1, 2.0); > Map.Entry e2 = Map.entry(3.0f, 4L); > Map map = Map.ofEntries(e1, e2); > > After adding the wildcards, the latter example compiles fine. This is a pretty unusual case, but for maximum flexibility it's probably a good idea to add the wildcards anyway. > > Please review the diff appended below. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1449706837 28800 > # Wed Dec 09 16:20:37 2015 -0800 > # Node ID b6540a8b7ab064600fe49a8bc678ad96127090ca > # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 > 8144952: add wildcards to the Map.ofEntries() method > Reviewed-by: XXX > > diff -r 7f644a5d554a -r b6540a8b7ab0 src/java.base/share/classes/java/util/Map.java > --- a/src/java.base/share/classes/java/util/Map.java Wed Dec 09 15:27:21 2015 -0500 > +++ b/src/java.base/share/classes/java/util/Map.java Wed Dec 09 16:20:37 2015 -0800 > @@ -1670,9 +1670,9 @@ > */ > @SafeVarargs > @SuppressWarnings("varargs") > - static Map ofEntries(Entry... entries) { > + static Map ofEntries(Entry... entries) { > Map map = new HashMap<>(entries.length * 4 / 3 + 1); // throws NPE if entries is null > - for (Entry e : entries) { > + for (Entry e : entries) { > // next line throws NPE if e is null > map.put(Objects.requireNonNull(e.getKey()), Objects.requireNonNull(e.getValue())); > } > diff -r 7f644a5d554a -r b6540a8b7ab0 test/java/util/Map/MapFactories.java > --- a/test/java/util/Map/MapFactories.java Wed Dec 09 15:27:21 2015 -0500 > +++ b/test/java/util/Map/MapFactories.java Wed Dec 09 16:20:37 2015 -0800 > @@ -377,4 +377,13 @@ > assertEquals(sie.toString(), kvh1.toString()); > } > > + // compile-time test of wildcards > + @Test > + public void entryWildcardTests() { > + Map.Entry e1 = Map.entry(1, 2.0); > + Map.Entry e2 = Map.entry(3.0f, 4L); > + Map map = Map.ofEntries(e1, e2); > + assertEquals(map.size(), 2); > + } > + > } From paul.sandoz at oracle.com Thu Dec 10 10:19:07 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Dec 2015 11:19:07 +0100 Subject: RFR 8145006 Collections.asLifoQueue(null) doesn't throw NPE as specified Message-ID: <0B977141-B218-4928-B600-F741CACB08AD@oracle.com> Hi, This is a small fix to Collections.asLifoQueue to throw an NPE if the deque passed is null as per the requirements on the class doc [1], rather than throwing an NPE when the Queue is operated on: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8145006-Collections-LIFO-no-NPE/webrev/ It's a small behavioural change (a matter of where the NPE will occur, earlier rather than later if the Queue is operated on), so it will also require a CCC. Paul. [1] *

    The methods of this class all throw a {@code NullPointerException} * if the collections or class objects provided to them are null. From Alan.Bateman at oracle.com Thu Dec 10 10:47:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Dec 2015 10:47:01 +0000 Subject: RFR [9] Remove sun.misc.Unsafe dependency from sun.nio.cs.StringUTF16 In-Reply-To: <56681416.1030406@oracle.com> References: <56681416.1030406@oracle.com> Message-ID: <56695825.2040102@oracle.com> On 09/12/2015 11:44, Chris Hegarty wrote: > Looks like the Compact Strings work inadvertently introduced a > dependency on sun.misc.Unsafe. ( just temporary confusion with > having two Unsafes until the jdk.unsupported module is defined ) Looks okay to me too, probably best to use the opportunity to add an import to avoid repeating the package name. -Alan From vyom.tewari at oracle.com Thu Dec 10 10:52:52 2015 From: vyom.tewari at oracle.com (vyom) Date: Thu, 10 Dec 2015 16:22:52 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <562A9DE1.4070208@oracle.com> References: <562A9DE1.4070208@oracle.com> Message-ID: <56695984.7030204@oracle.com> Hi All, Please review my changes for below bug. Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ This change ensure that length() does not temporarily changes the file pointer and it will make sure that there is no race condition in case of multi thread uses. Thanks, Vyom From timo.kinnunen at gmail.com Thu Dec 10 10:58:03 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Thu, 10 Dec 2015 11:58:03 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56693202.1060502@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> <56693202.1060502@gmail.com> Message-ID: <56695abd.e1aec20a.d732f.22bb@mx.google.com> This seems problematic to me, because it breaks the expectation that the most important part of the stack trace can be found at the bottom of the it. In this case, if someone subsequently wraps the original exception in their own Exception the causal chain then gets jumbled. I actually wish printStackTrace processed the exceptions in the main trace in reverse compared to how it is now. If, rather than finding this at the end of a stack trace: Caused by: org.osgi.framework.BundleException: Error starting module. at org.eclipse.osgi.container.Module.doStart(Module.java:580) at org.eclipse.osgi.container.Module.start(Module.java:439) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454) at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) ... 57 more Caused by: java.lang.NoClassDefFoundError: org/eclipse/jdt/debug/core/IJavaHotCodeReplaceListener at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) [snip] at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318) at org.eclipse.osgi.container.Module.doStart(Module.java:571) ... 60 more Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.debug.core.IJavaHotCodeReplaceListener cannot be found by org.eclipse.jdt.debug.ui_3.6.400.qualifier at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(Unknown Source) ... 69 more You would instead see it like this at the beginning of the stack trace: java.lang.ClassNotFoundException: org.eclipse.jdt.debug.core.IJavaHotCodeReplaceListener cannot be found by org.eclipse.jdt.debug.ui_3.6.400.qualifier at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160) at java.lang.ClassLoader.loadClass(Unknown Source) Causing: java.lang.NoClassDefFoundError: org/eclipse/jdt/debug/core/IJavaHotCodeReplaceListener at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) [snip] at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318) at org.eclipse.osgi.container.Module.doStart(Module.java:571) Causing: org.osgi.framework.BundleException: Error starting module. at org.eclipse.osgi.container.Module.doStart(Module.java:580) at org.eclipse.osgi.container.Module.start(Module.java:439) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454) at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) Causing: java.lang.ClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.jdt.debug.ui (186). at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:116) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:531) See how even the handoff from one handler to another is now readily apparent? The right place where the next part of the trace should appear is quite obvious. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Peter Levart Sent: Thursday, December 10, 2015 09:04 To: Martin Buchholz;Jason Mehrens;Doug Lea Cc: core-libs-dev Subject: Re: RFR: jsr166 jdk9 integration wave 2 Hi Martin, On 12/10/2015 12:18 AM, Martin Buchholz wrote: > I finally studied ForkJoinTask.getThrowableException - I was not aware > that we were doing reflection based exception cloning. In practice it > probably muddles through, but it just seems too hacky to use in a java > core library. We're relying on common conventions, but in principle > we are invoking random code with an unknown spec. The stack traces > created are fake in the sense that they are not created naturally, and > the thrown exception may differ from the original in significant ways, > most notably missing the message string. With heroic efforts we can > make it safer, e.g. examine the bytecode for the constructors we are > invoking, and check whether they call the super constructors in the > right way, but that will be a major engineering project by itself. I assume the aim of exception cloning in ForkJoinTask.getThrowableException is to provide the user with a stack-trace that originates in its own thread. This helps trace the origin of the exception in case it's handled way up in the call stack. In addition, the original stack trace is also preserved (original exception is added as a cause). This case does not suffer from the visibility of original exception before ForkJoinTask.getThrowableException is called, so perhaps the aim could be achieved in a slightly different manner: just return the original exception, but add a newly constructed CrossThreadPropagationException as a suppressed exception to it. Printing such augmented original exception would then reveal both stack traces. What do you think? > > For CompletableFuture.whenComplete: I also keep moving in the > direction of less magic. It is perfectly possible for a well-written > whenComplete action to catch all Throwables, add the source exception > as a suppressed exception, and rethrow. In fact, perhaps people have > already tried this and discovered we incorrectly throw the source > exception. I think we should really accept our mistake and switch to > throwing the action exception rather than the source exception. > Perhaps we should only call addSuppressed if the source exception is > not already in the list of suppressed exceptions. Less is more. I would even not bother with the additional logic of conditionally adding source exception to the list of suppressed exceptions. I doubt many codes out there do that in the whenComplete handler since such exception was ignored up until now. And if anybody does that, she will get the source exception listed twice - not a big deal. If javadoc describes the behavior, this will not happen frequently. Regards, Peter > > > On Thu, Dec 3, 2015 at 9:54 AM, Jason Mehrens wrote: >> Hi Peter, >> >> I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: >> 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) >> 2. Walk the type of the cause and super types by calling getConstructor(type of cause, String) (I've seen this but, I can't seem to find an example) >> 3. getConstructor(String) + initCause (java.io.InvalidObjectException) >> 4. Walk the type of the cause and super types by calling getConstructor(type of cause). (java.awt.print.PrinterIOException) >> 5. getConstructor() + initCause. (java.nio.BufferOverflowException) >> 6. Look at the return type of methods declared in the cause type and assume there is a constructor matching the type or no repeating types. (java.nio.charset.MalformedInputException, java.lang.EnumConstantNotPresentException, java.util.regex.PatternSyntaxException) >> >> In the end all of that can still fail. Exceptions can be private subclasses of public classes so that gets interesting with reflection too. >> >> Jason >> >> >> =========== >> What about the 4th option (keep current behavior, but try the >> best-effort with reflection to make new exception of the same type): >> >> ... >> } catch (Throwable ex) { >> if (x == null) { >> x = ex; >> } else { >> // try to create new exception with same: >> // type, cause, suppressed exceptions and >> stack-trace... >> Throwable nx; >> Class xClass = x.getClass(); >> try { >> Constructor xConstr = >> xClass.getConstructor(Throwable.class); >> nx = (Throwable) xConstr.newInstance(x.getCause()); >> } catch (Exception e1) { >> try { >> nx = (Throwable) xClass.newInstance(); >> nx.initCause(x.getCause()); >> } catch (Exception e2) { >> // no luck >> nx = null; >> } >> } >> if (nx != null) { >> // inherit stack-trace of original exception >> nx.setStackTrace(x.getStackTrace()); >> // inherit suppressed exceptions >> for (Throwable sx : x.getSuppressed()) { >> nx.addSuppressed(sx); >> } >> // add 'ex' as a final suppressed exception >> nx.addSuppressed(ex); >> x = nx; >> } >> } >> } >> completeThrowable(x, r); >> >> ... >> >> >> >> Note that such code and similar code in >> ForkJoinTask.getThrowableException will probably have to be modified for >> jigsaw to include dynamic addition of read-edge to the module of >> exception class... >> >> Regards, Peter >> From chris.hegarty at oracle.com Thu Dec 10 11:48:02 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Dec 2015 11:48:02 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: References: Message-ID: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> I received some comments from Paul offline about the test. Updated webrev: http://cr.openjdk.java.net/~chegar/8056152/01/webrev/ -Chris. On 8 Dec 2015, at 14:15, Chris Hegarty wrote: > Many threads created by the platform are short lived and perform some > simple async operation on behalf of the platform. These threads typically > use/extend sun.misc.ManagedLocalsThread. This is a convenient internal > API that can be used to create threads that do not wish to inherit initial > values from inheritable thread-local variables. > > I'd like to propose an additional java.lang.Thread constructor that exposes > the ability to explicitly "opt out" of inheriting these initial values ( from > inheritable thread-local variables ). This seems like useful general > functionality, given the amount of usage in the JDK of the internal API. > > This new public API can then be used to replace usages of the internal > sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted > the usage in the sources of the base module. Other modules can be done > as a follow up. > > Webrev: > http://cr.openjdk.java.net/~chegar/8056152/00/webrev/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8056152 From david.holmes at oracle.com Thu Dec 10 12:24:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Dec 2015 22:24:24 +1000 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56695984.7030204@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> Message-ID: <56696EF8.4060800@oracle.com> Hi Vyom, Should this be reviewed by the NIO folk? It isn't obvious whether this change impacts the interaction with the associated FileChannel - see also https://bugs.openjdk.java.net/browse/JDK-6371642 Thanks, David On 10/12/2015 8:52 PM, vyom wrote: > Hi All, > > Please review my changes for below bug. > > Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe > > Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ > > > This change ensure that length() does not temporarily changes the file > pointer and it will make sure that there is no race > condition in case of multi thread uses. > > Thanks, > Vyom > > > > From sergei.kovalev at oracle.com Thu Dec 10 13:28:18 2015 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 10 Dec 2015 16:28:18 +0300 Subject: RFR(S): 8078423: [TESTBUG] javax/print/PrintSEUmlauts/PrintSEUmlauts.java relies on system locale In-Reply-To: <56684CFA.8010706@oracle.com> References: <56684CFA.8010706@oracle.com> Message-ID: <56697DF2.3000006@oracle.com> Hi, Could you please review the following patch? Bug ID: https://bugs.openjdk.java.net/browse/JDK-8078423 Webrev: http://cr.openjdk.java.net/~skovalev/8078423/webrev.01/ Summary: Compilation of the test fails if system locale is not UTF-8. Description: Replace UTF-8 characters by Unicode escapes for non-ASCII characters Testing done: tested manually on problematic host. The test fails with LC_NAME="POSIX" without the fix, modified test passes. -- With best regards, Sergei From bitterfoxc at gmail.com Thu Dec 10 14:29:59 2015 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 10 Dec 2015 23:29:59 +0900 Subject: RFR 8144675: Add a filtering collector In-Reply-To: <5668E96C.2020101@oracle.com> References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> <5668E96C.2020101@oracle.com> Message-ID: Hi Stuart, Thank you for your review and comment. The doc comment is wonderful! I like it, it must be helpful to users when they understand this method and how the filtering collector works! I've updated the webrev: http://cr.openjdk.java.net/~shinyafox/8144675/webrev.04/ Could you confirm? Regards, shinyafox(Shinya Yoshida) 2015-12-10 11:54 GMT+09:00 Stuart Marks : > Hi Shinya, > > Thanks for doing this work. This looks very nice! (And thanks to Paul for > helping move it through the process.) > > I have only a minor comment, which is that it might be good to clarify in > the example why a filtering collector is necessary instead of just adding a > filter() step into the stream. (This is what prompted Henry Jen's question, > and it was my initial thought too.) > > Maybe it would be sufficient to add something like the following after the > example: > > ? A filtering collector differs from a stream's {@code filter()} > operation. In this example, suppose there are no employees whose salary is > above the threshold in some department. Using a filtering collector as > shown above would result in a mapping from that department to an empty > {@code Set}. If a stream {@code filter()} operation were done instead, > there would be no mapping for that department at all. ? > > s'marks > > > > > On 12/8/15 4:21 AM, ShinyaYoshida wrote: > >> Hi Stefan, >> Thank you for pointing out. >> I've just updated: >> http://cr.openjdk.java.net/~shinyafox/8144675/webrev.03/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2015-12-08 21:08 GMT+09:00 Stefan Zobel : >> >> Hi shinyafox, >>> >>> minor typo in the code example: >>> >>> >>> s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment >>> >>> >>> Regards, >>> Stefan >>> >>> >>> 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : >>> >>>> Thank you so much! >>>> I've updated in webrev.02. >>>> >>>> Best regard, >>>> shinyafox(Shinya Yoshida) >>>> >>>> >>> From ramanand.patil at oracle.com Thu Dec 10 15:36:02 2015 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 10 Dec 2015 07:36:02 -0800 (PST) Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: References: <75b86334-1d29-4889-b9ae-e2815462d711@default> Message-ID: <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> Hi all, Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 Regards, Ramanand. -----Original Message----- From: Stephen Colebourne [mailto:scolebourne at joda.org] Sent: Wednesday, December 09, 2015 4:46 PM To: core-libs-dev Cc: i18n-dev Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition The logic looks fine. In the main code, this part .getLong(INSTANT_SECONDS); can be replaced with .toEpochSecond(); which will be slightly faster. In the test case, this part .plus(15, ChronoUnit.MINUTES); can be replaced with .plusMinutes(15) And .with(ChronoField.OFFSET_SECONDS, ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) can be replaced with .with(ZoneOffset.of(offsetSamples[j])) In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. thanks for fixing this Stephen On 9 December 2015 at 07:44, Ramanand Patil wrote: > HI all, > > > > Please review a fix for Bug - HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 > > > > Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). > > > > Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ > > > > One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. > > > > > > Regards, > > Ramanand. From martinrb at google.com Thu Dec 10 15:51:28 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Dec 2015 07:51:28 -0800 Subject: RFR(S): 8078423: [TESTBUG] javax/print/PrintSEUmlauts/PrintSEUmlauts.java relies on system locale In-Reply-To: <56697DF2.3000006@oracle.com> References: <56684CFA.8010706@oracle.com> <56697DF2.3000006@oracle.com> Message-ID: Thanks! Looks good. For bonus points, one could check all the jdk test sources for non-ASCII characters. They should probably only ever be used in javac tests that are actually testing source file encoding. On Thu, Dec 10, 2015 at 5:28 AM, Sergei Kovalev wrote: > Hi, > > Could you please review the following patch? > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8078423 > Webrev: http://cr.openjdk.java.net/~skovalev/8078423/webrev.01/ > Summary: Compilation of the test fails if system locale is not UTF-8. > Description: Replace UTF-8 characters by Unicode escapes for non-ASCII > characters > > Testing done: tested manually on problematic host. The test fails with > LC_NAME="POSIX" without the fix, modified test passes. > > > -- With best regards, > Sergei > > From chris.hegarty at oracle.com Thu Dec 10 15:56:33 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Dec 2015 15:56:33 +0000 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util Message-ID: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> sun.misc.HexDumpEncoder is an internal private API that is used almost exclusively by the security library code. It should be moved out of sun.misc and into a package more appropriate to its use, sun.security.util. HexDumpEncoder extends CharacterEncoder, which is slated for later removal, so the minimal implementation was copied in-place ( no new code ). http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8144995 From scolebourne at joda.org Thu Dec 10 16:00:12 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 Dec 2015 16:00:12 +0000 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> Message-ID: I believe this is suitable for committing, thanks, other reviews welcome! Stephen On 10 December 2015 at 15:36, Ramanand Patil wrote: > Hi all, > > Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ > > I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. > > Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 > > > Regards, > Ramanand. > > -----Original Message----- > From: Stephen Colebourne [mailto:scolebourne at joda.org] > Sent: Wednesday, December 09, 2015 4:46 PM > To: core-libs-dev > Cc: i18n-dev > Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition > > The logic looks fine. > > In the main code, this part > .getLong(INSTANT_SECONDS); > can be replaced with > .toEpochSecond(); > which will be slightly faster. > > In the test case, this part > .plus(15, ChronoUnit.MINUTES); > can be replaced with > .plusMinutes(15) > > And > .with(ChronoField.OFFSET_SECONDS, > ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) > can be replaced with > .with(ZoneOffset.of(offsetSamples[j])) > > In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. > > thanks for fixing this > Stephen > > > > On 9 December 2015 at 07:44, Ramanand Patil wrote: >> HI all, >> >> >> >> Please review a fix for Bug - HYPERLINK >> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >> >> >> >> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). >> >> >> >> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >> >> >> >> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. >> >> >> >> >> >> Regards, >> >> Ramanand. From paul.sandoz at oracle.com Thu Dec 10 16:03:47 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Dec 2015 17:03:47 +0100 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> Message-ID: <6AF2B0FA-3AC4-4B39-9718-405BC0443889@oracle.com> Looks ok to me, Paul. > On 10 Dec 2015, at 16:56, Chris Hegarty wrote: > > sun.misc.HexDumpEncoder is an internal private API that is used almost > exclusively by the security library code. It should be moved out of sun.misc > and into a package more appropriate to its use, sun.security.util. > > HexDumpEncoder extends CharacterEncoder, which is slated for later > removal, so the minimal implementation was copied in-place ( no new > code ). > > http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8144995 From martinrb at google.com Thu Dec 10 16:21:58 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Dec 2015 08:21:58 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56693202.1060502@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> <56693202.1060502@gmail.com> Message-ID: On Thu, Dec 10, 2015 at 12:04 AM, Peter Levart wrote: > Hi Martin, > > On 12/10/2015 12:18 AM, Martin Buchholz wrote: >> >> I finally studied ForkJoinTask.getThrowableException - I was not aware >> that we were doing reflection based exception cloning. In practice it >> probably muddles through, but it just seems too hacky to use in a java >> core library. We're relying on common conventions, but in principle >> we are invoking random code with an unknown spec. The stack traces >> created are fake in the sense that they are not created naturally, and >> the thrown exception may differ from the original in significant ways, >> most notably missing the message string. With heroic efforts we can >> make it safer, e.g. examine the bytecode for the constructors we are >> invoking, and check whether they call the super constructors in the >> right way, but that will be a major engineering project by itself. > > > I assume the aim of exception cloning in ForkJoinTask.getThrowableException > is to provide the user with a stack-trace that originates in its own thread. > This helps trace the origin of the exception in case it's handled way up in > the call stack. In addition, the original stack trace is also preserved > (original exception is added as a cause). > > This case does not suffer from the visibility of original exception before > ForkJoinTask.getThrowableException is called, so perhaps the aim could be > achieved in a slightly different manner: just return the original exception, > but add a newly constructed CrossThreadPropagationException as a suppressed > exception to it. Printing such augmented original exception would then > reveal both stack traces. What do you think? I like it! Although we are bending the purpose of suppressed exceptions a bit. >> For CompletableFuture.whenComplete: I also keep moving in the >> direction of less magic. It is perfectly possible for a well-written >> whenComplete action to catch all Throwables, add the source exception >> as a suppressed exception, and rethrow. In fact, perhaps people have >> already tried this and discovered we incorrectly throw the source >> exception. I think we should really accept our mistake and switch to >> throwing the action exception rather than the source exception. >> Perhaps we should only call addSuppressed if the source exception is >> not already in the list of suppressed exceptions. > > > Less is more. I would even not bother with the additional logic of > conditionally adding source exception to the list of suppressed exceptions. > I doubt many codes out there do that in the whenComplete handler since such > exception was ignored up until now. And if anybody does that, she will get > the source exception listed twice - not a big deal. If javadoc describes the > behavior, this will not happen frequently. Perhaps we should even retreat further into "less is more" territory and trust the programmer, reducing our involvement to friendly advice in the javadoc. Version 0.1: """We recommend writing whenComplete actions thus: try { ... real code here ... } catch (Throwable t) { t.addSuppressed(source); throw t; } """ From martinrb at google.com Thu Dec 10 16:29:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Dec 2015 08:29:55 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56695abd.e1aec20a.d732f.22bb@mx.google.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <566009BA.50804@gmail.com> <56693202.1060502@gmail.com> <56695abd.e1aec20a.d732f.22bb@mx.google.com> Message-ID: On Thu, Dec 10, 2015 at 2:58 AM, Timo Kinnunen wrote: > This seems problematic to me, because it breaks the expectation that the > most important part of the stack trace can be found at the bottom of the it. > In this case, if someone subsequently wraps the original exception in their > own Exception the causal chain then gets jumbled. I actually wish > printStackTrace processed the exceptions in the main trace in reverse > compared to how it is now. If, rather than finding this at the end of a > stack trace: Timo, this is a new idea to me - I always read stacktraces "from the top". But I've never had to debug those large java apps that real java programmers maintain. I like having the top exception be the "real" one instead of one we fabricated to help the user. I think now I finally understand weird stacktraces in forkjoin tests that came from ForkJoinTask.getThrowableException where I was wondering why the exception appeared to be repeated and why the exception message was missing. From amaembo at gmail.com Thu Dec 10 16:31:56 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Thu, 10 Dec 2015 22:31:56 +0600 Subject: Producing streams in java.time? Message-ID: <851620702.20151210223156@gmail.com> Hello! Currently it seems that java.time package does not use Stream API in any way. I think it would be nice to add some methods which produce the streams. For example: - in class Year: // Returns sequential ordered stream of all months within this Year: Stream months(); // Returns sequential ordered stream of all days within this Year: Stream days(); // Returns sequential ordered stream of all years starting from this // Year until the supplied year, exclusive Stream yearsUntil(Temporal endExclusive); - in class YearMonth: // Returns sequential ordered stream of all days within this YearMonth: Stream days(); // Returns sequential ordered stream of all months starting from this // YearMonth until the supplied YearMonth, exclusive Stream monthsUntil(Temporal endExclusive); - in class LocalDate: // Returns sequential ordered stream of all months starting from this // LocalDate until the supplied LocalDate, exclusive Stream daysUntil(Temporal endExclusive); The implementation of these methods could be quite simple. For example: class Year { public Stream days() { return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); } } What do you think? With best regards, Tagir Valeev. From martinrb at google.com Thu Dec 10 17:46:17 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Dec 2015 09:46:17 -0800 Subject: question on jdk_collections group in jdk/test/TEST.groups In-Reply-To: <5668D9B4.5040408@oracle.com> References: <5668D9B4.5040408@oracle.com> Message-ID: I don't know how jdk_collections was defined. I recommend fixing it as below. The distinction between "maintained by JSR-166" and other collections is useful when knowing who to contact and whether to make changes to particular source files (or defer to JSR-166). But it's not useful for knowing what tests to run. (Also, jsr166 has taken over maintenance of some legacy tests). Personally I always run the concurrent tests together with the collection tests, as in: (cd ~/ws/jdk9/jdk/test && find java/util -type d \( \( -name concurrent -prune \) -o -name '*Set*' -o -name '*Map*' -o -name '*List*' -o -name '*Queue*' -o -name '*Deque*' -o -name '*Collection*' -o -name '*Vector*' -o -name '*Hashtable*' -o -name '*Array*' \) ) java/util/TreeMap java/util/Vector java/util/HashMap java/util/concurrent java/util/HashSet java/util/BitSet java/util/ArrayList java/util/EnumSet java/util/List java/util/PriorityQueue java/util/Arrays java/util/NavigableMap java/util/AbstractList java/util/Deque java/util/Collections java/util/IdentityHashMap java/util/EnumMap java/util/AbstractSequentialList java/util/Hashtable java/util/LinkedHashSet java/util/AbstractMap java/util/LinkedHashMap java/util/Collection java/util/Map java/util/LinkedList java/util/AbstractCollection java/util/WeakHashMap On Wed, Dec 9, 2015 at 5:47 PM, Stuart Marks wrote: > Hi, maybe somebody can fill me in on the history here. > > There's a nice test group called jdk_collections defined in > jdk/test/TEST.groups. It runs the tests for the collections in java/util > (but not java/util/concurrent) and it excludes all the stuff in java/util > that isn't collections-related. > > Well, not really. The jdk_collections group excludes the java/util/Deque and > java/util/PriorityQueue tests. Those are in the jdk_concurrent test group, > and there's a note there that those are maintained by "JSR-166 (Doug Lea et > al)". > > I'm dimly aware that some of the newer non-concurrent collections like Deque > and PQ came in via the various JSR-166 efforts. Is it still useful to > preserve this distinction in the TEST.groups file? It seems to me that, as > much as possible, the jdk_collections group should include the "core > collections" tests and the jdk_concurrent group should include the tests for > the j.u.c stuff. > > s'marks From stuart.marks at oracle.com Thu Dec 10 19:39:29 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Dec 2015 11:39:29 -0800 Subject: RFR 8145006 Collections.asLifoQueue(null) doesn't throw NPE as specified In-Reply-To: <0B977141-B218-4928-B600-F741CACB08AD@oracle.com> References: <0B977141-B218-4928-B600-F741CACB08AD@oracle.com> Message-ID: <5669D4F1.5030803@oracle.com> Hi Paul, Change looks good. Given that it cannot possibly work if null is passed, changing the timing of NPE seems like a reasonably compatible change. s'marks On 12/10/15 2:19 AM, Paul Sandoz wrote: > Hi, > > This is a small fix to Collections.asLifoQueue to throw an NPE if the deque passed is null as per the requirements on the class doc [1], rather than throwing an NPE when the Queue is operated on: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8145006-Collections-LIFO-no-NPE/webrev/ > > It's a small behavioural change (a matter of where the NPE will occur, earlier rather than later if the Queue is operated on), so it will also require a CCC. > > Paul. > > [1] > *

    The methods of this class all throw a {@code NullPointerException} > * if the collections or class objects provided to them are null. > From mandy.chung at oracle.com Thu Dec 10 19:59:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2015 11:59:02 -0800 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> References: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> Message-ID: <5669D986.30301@oracle.com> On 12/10/2015 03:48 AM, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8056152/01/webrev/ Looks good. Nit: 687 * the specified stack size, and inherits initial values for Not sure if italic font of stack size is intentional since this constructor doesn't emphasize on this parameter. Mandy From joel.borggren.franck at gmail.com Thu Dec 10 20:27:22 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Thu, 10 Dec 2015 20:27:22 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: <5668D0C9.6010806@oracle.com> References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> Message-ID: Hi Joe, Inline, On Thu, 10 Dec 2015 at 02:09 Joseph D. Darcy wrote: > Hi Joel, > > For the specification, it should seem reasonable to me to have the > default implementation of AnnotatedType.getAnnotatedOwnerType() to > return null rather than throwing an UnsupportedOperationException. > I disagree but I think this is a very theoretical point since with a very high probability there is exactly one implementation and we control that. Because of that I'm fine with either so I changed it. > Following experience with similar structures in the javax.lang.model > APIs, e.g. > > JDK-7015530: Reiterate API specializations in > javax.lang.model.element subinterfaces > http://cr.openjdk.java.net/~darcy/7015530.1/ > > I think it is clearer to readers of the specification if description of > behavior like > > // Supertype > > /** > * In these subtypes, do this. In these other subtypes, do that. > */ > void foo(); > > is additionally copied down and specialized into the subtypes, even if > trivial overriden methods are defined whose only purpose is to serve as > a hook to hang the javadoc. > > Sounds reasonable, I coped the supertypes doc and cut out pieces for unrelated subtypes (like Element/PackageElement for getSimpleName). Question, is it better to remove the throws clauses for the cases that return null? New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ Diff of patch 01 and patch 02 (a diff-diff): http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch cheers /Joel From joe.darcy at oracle.com Thu Dec 10 21:18:34 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 10 Dec 2015 13:18:34 -0800 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> Message-ID: <5669EC2A.1030308@oracle.com> Hi Joel, On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: > Hi Joe, > > Inline, > > On Thu, 10 Dec 2015 at 02:09 Joseph D. Darcy > wrote: > > Hi Joel, > > For the specification, it should seem reasonable to me to have the > default implementation of AnnotatedType.getAnnotatedOwnerType() to > return null rather than throwing an UnsupportedOperationException. > > > I disagree but I think this is a very theoretical point since with a > very high probability there is exactly one implementation and we > control that. Because of that I'm fine with either so I changed it. > > Following experience with similar structures in the javax.lang.model > APIs, e.g. > > JDK-7015530: Reiterate API specializations in > javax.lang.model.element subinterfaces > http://cr.openjdk.java.net/~darcy/7015530.1/ > > > I think it is clearer to readers of the specification if > description of > behavior like > > // Supertype > > /** > * In these subtypes, do this. In these other subtypes, do that. > */ > void foo(); > > is additionally copied down and specialized into the subtypes, even if > trivial overriden methods are defined whose only purpose is to > serve as > a hook to hang the javadoc. > > > Sounds reasonable, I coped the supertypes doc and cut out pieces for > unrelated subtypes (like Element/PackageElement for getSimpleName). > > Question, is it better to remove the throws clauses for the cases that > return null? I think so; they aren't applicable in those case and it is fine to remove exceptions in subtypes of course. Please also add @Override annotations to the methods in the subtypes as a check that a new method is not accidentally being declared. > > New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ > > Diff of patch 01 and patch 02 (a diff-diff): > http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch > > > Please add an @implSpec note in AnnotatedType saying that "this implementation returns null", or words to that effect. Shouldn't some of the implementation overrides in AnnotatedTypeFactory.java which throw null now be removed? Ah, I see the BaseImpl type is in the way. Is there an easy way to refactor that? (I'll take care of the ccc changes once the new spec is finalized.) Thanks, -Joe From stuart.marks at oracle.com Thu Dec 10 22:14:22 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Dec 2015 14:14:22 -0800 Subject: question on jdk_collections group in jdk/test/TEST.groups In-Reply-To: References: <5668D9B4.5040408@oracle.com> Message-ID: <5669F93E.4090609@oracle.com> Hi Martin, Thanks for looking at this. I also heard offline from Mike Duigou that the current grouping was meant to be an intermediate step. He mentioned plans to break it into multiple sub-groups, but that didn't happen. But cleaning up the jdk_collections group seems sensible. In any case it appears that the historic separation of Deque and PQ into jdk_concurrent is no longer useful. I'll move these two into jdk_collections. Cross-checking your recommendation against jdk_collections, I see that it's missing HashSet, but it includes Comparator, Iterator, and TimSort. I think it makes sense to leave those in. I'll also alphabetize the list. s'marks On 12/10/15 9:46 AM, Martin Buchholz wrote: > I don't know how jdk_collections was defined. I recommend fixing it as below. > > The distinction between "maintained by JSR-166" and other collections > is useful when knowing who to contact and whether to make changes to > particular source files (or defer to JSR-166). But it's not useful > for knowing what tests to run. (Also, jsr166 has taken over > maintenance of some legacy tests). Personally I always run the > concurrent tests together with the collection tests, as in: > > (cd ~/ws/jdk9/jdk/test && find java/util -type d \( \( -name > concurrent -prune \) -o -name '*Set*' -o -name '*Map*' -o -name > '*List*' -o -name '*Queue*' -o -name '*Deque*' -o -name '*Collection*' > -o -name '*Vector*' -o -name '*Hashtable*' -o -name '*Array*' \) ) > java/util/TreeMap > java/util/Vector > java/util/HashMap > java/util/concurrent > java/util/HashSet > java/util/BitSet > java/util/ArrayList > java/util/EnumSet > java/util/List > java/util/PriorityQueue > java/util/Arrays > java/util/NavigableMap > java/util/AbstractList > java/util/Deque > java/util/Collections > java/util/IdentityHashMap > java/util/EnumMap > java/util/AbstractSequentialList > java/util/Hashtable > java/util/LinkedHashSet > java/util/AbstractMap > java/util/LinkedHashMap > java/util/Collection > java/util/Map > java/util/LinkedList > java/util/AbstractCollection > java/util/WeakHashMap > > On Wed, Dec 9, 2015 at 5:47 PM, Stuart Marks wrote: >> Hi, maybe somebody can fill me in on the history here. >> >> There's a nice test group called jdk_collections defined in >> jdk/test/TEST.groups. It runs the tests for the collections in java/util >> (but not java/util/concurrent) and it excludes all the stuff in java/util >> that isn't collections-related. >> >> Well, not really. The jdk_collections group excludes the java/util/Deque and >> java/util/PriorityQueue tests. Those are in the jdk_concurrent test group, >> and there's a note there that those are maintained by "JSR-166 (Doug Lea et >> al)". >> >> I'm dimly aware that some of the newer non-concurrent collections like Deque >> and PQ came in via the various JSR-166 efforts. Is it still useful to >> preserve this distinction in the TEST.groups file? It seems to me that, as >> much as possible, the jdk_collections group should include the "core >> collections" tests and the jdk_concurrent group should include the tests for >> the j.u.c stuff. >> >> s'marks From brian.burkhalter at oracle.com Thu Dec 10 22:32:55 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 10 Dec 2015 14:32:55 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <5668DF5D.2040908@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> <5668DF5D.2040908@oracle.com> Message-ID: <05B25BA5-7E47-4900-A8AC-C768DE2A8FBF@oracle.com> A new version is here: http://cr.openjdk.java.net/~bpb/8032027/webrev.05/ I changed the test to verify these values: Stream.Builder sb = Stream.builder(); int maxExponent = Double.MAX_EXPONENT + 1; for (int i = 1; i <= maxExponent; i++) { BigInteger p2 = BigInteger.ONE.shiftLeft(i); sb.add(p2.subtract(BigInteger.ONE)); sb.add(p2); sb.add(p2.add(BigInteger.ONE)); } sb.add((new BigDecimal(Double.MAX_VALUE)).toBigInteger()); sb.add((new BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE)); report("squareRoot for 2^N and 2^N - 1, 1 <= N <= Double.MAX_EXPONENT", sb.build().collect(Collectors.summingInt(f))); At line 1892 of the current version of MutableBigInteger I changed "if (bitLength() < 63)" to "if (bitLength() <= 63)". I realized that in that case the entire calculation might as well be done in longs so I changed it accordingly. The modified test passes with this new revision. Thanks, Brian On Dec 9, 2015, at 6:11 PM, Joseph D. Darcy wrote: > New version looks good. > > One more case to try: start with a BigInteger that would overflow to Double.POSITIVE_INFINITY when the doubleValue method was called. If this case doesn't take too long to run, it would be a fine additional case to add to the test. 2^1024 should be fine input value. More precisely, > > (new BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE); > > should do the trick. If the code passes with this value, you're okay to push. Well, while you're at it, might as well verify > > (new BigDecimal(Double.MAX_VALUE)).toBigInteger() > > behaves well too ;-) On Dec 9, 2015, at 6:22 PM, Louis Wasserman wrote: > Guava's tests check the explicit definition of square root (mentioned by Joe above) on 2^n +/- 1 for all n up to Double.MAX_EXPONENT + 1, because why not? From stuart.marks at oracle.com Thu Dec 10 22:39:30 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Dec 2015 14:39:30 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups (was: question on jdk_collections group in jdk/test/TEST.groups) In-Reply-To: <5669F93E.4090609@oracle.com> References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> Message-ID: <5669FF22.6010705@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8145139 I've appended a patch below; please review. Thanks, s'marks # HG changeset patch # User smarks # Date 1449787050 28800 # Thu Dec 10 14:37:30 2015 -0800 # Node ID 5b630d0c118b115439672b29aff0d195132d4f96 # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 8145139: clean up jdk_collections and jdk_concurrent test groups Reviewed-by: XXX diff -r 7f644a5d554a -r 5b630d0c118b test/TEST.groups --- a/test/TEST.groups Wed Dec 09 15:27:21 2015 -0500 +++ b/test/TEST.groups Thu Dec 10 14:37:30 2015 -0800 @@ -95,13 +95,10 @@ -:jdk_concurrent \ -:jdk_stream -# java.util.concurrent (JSR-166) +# java.util.concurrent # Maintained by JSR-166 EG (Doug Lea et al) -# Deque and PriorityQueue are also generally maintained by JSR-166 jdk_concurrent = \ - java/util/concurrent \ - java/util/Deque \ - java/util/PriorityQueue + java/util/concurrent # Java Collections Framework jdk_collections = \ @@ -114,19 +111,22 @@ java/util/BitSet \ java/util/Collection \ java/util/Collections \ + java/util/Comparator \ + java/util/Deque \ java/util/EnumMap \ java/util/EnumSet \ - java/util/Comparator \ - java/util/Iterator \ java/util/HashMap \ + java/util/HashSet \ java/util/Hashtable \ java/util/IdentityHashMap \ - java/util/List \ + java/util/Iterator \ java/util/LinkedHashMap \ java/util/LinkedHashSet \ java/util/LinkedList \ + java/util/List \ java/util/Map \ java/util/NavigableMap \ + java/util/PriorityQueue \ java/util/TimSort \ java/util/TreeMap \ java/util/Vector \ From joe.darcy at oracle.com Thu Dec 10 22:56:58 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 10 Dec 2015 14:56:58 -0800 Subject: [9] RFR of 8032027: Add BigInteger square root methods In-Reply-To: <05B25BA5-7E47-4900-A8AC-C768DE2A8FBF@oracle.com> References: <75C5170A-11B1-437A-A411-C125D54406E9@oracle.com> <560FA21E.7050300@redhat.com> <99CFE478-9AED-415B-897F-F07CA79FF67D@oracle.com> <6D64676C-9A0B-42B7-905C-67CADC99F1DF@oracle.com> <564A19D7.7050600@oracle.com> <565B3D72.2070403@oracle.com> <7996109D-3F99-4AE2-978D-A071C9A9877F@oracle.com> <565E648C.9040304@oracle.com> <0FC0BE8E-30E3-41E4-8512-DF821D0BD2A3@oracle.com> <5668DF5D.2040908@oracle.com> <05B25BA5-7E47-4900-A8AC-C768DE2A8FBF@oracle.com> Message-ID: <566A033A.5030607@oracle.com> Looks good Brian; thanks, -Joe On 12/10/2015 2:32 PM, Brian Burkhalter wrote: > A new version is here: > > http://cr.openjdk.java.net/~bpb/8032027/webrev.05/ > > > I changed the test to verify these values: > > Stream.Builder sb = Stream.builder(); > int maxExponent = Double.MAX_EXPONENT + 1; > for (int i = 1; i <= maxExponent; i++) { > BigInteger p2 = BigInteger.ONE.shiftLeft(i); > sb.add(p2.subtract(BigInteger.ONE)); > sb.add(p2); > sb.add(p2.add(BigInteger.ONE)); > } > sb.add((new BigDecimal(Double.MAX_VALUE)).toBigInteger()); > sb.add((new > BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE)); > report("squareRoot for 2^N and 2^N - 1, 1 <= N <= Double.MAX_EXPONENT", > sb.build().collect(Collectors.summingInt(f))); > > At line 1892 of the current version of MutableBigInteger I changed "if > (bitLength() < 63)" to "if (bitLength() <= 63)". I realized that in > that case the entire calculation might as well be done in longs so I > changed it accordingly. The modified test passes with this new revision. > > Thanks, > > Brian > > On Dec 9, 2015, at 6:11 PM, Joseph D. Darcy > wrote: > >> New version looks good. >> >> One more case to try: start with a BigInteger that would overflow to >> Double.POSITIVE_INFINITY when the doubleValue method was called. If >> this case doesn't take too long to run, it would be a fine additional >> case to add to the test. 2^1024 should be fine input value. More >> precisely, >> >> (new >> BigDecimal(Double.MAX_VALUE)).toBigInteger().add(BigInteger.ONE); >> >> should do the trick. If the code passes with this value, you're okay >> to push. Well, while you're at it, might as well verify >> >> (new BigDecimal(Double.MAX_VALUE)).toBigInteger() >> >> behaves well too ;-) > > On Dec 9, 2015, at 6:22 PM, Louis Wasserman > wrote: > >> Guava's tests check the explicit definition of square root (mentioned >> by Joe above) on 2^n +/- 1 for all n up to Double.MAX_EXPONENT + 1, >> because why not? > From Roger.Riggs at Oracle.com Thu Dec 10 23:17:29 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 10 Dec 2015 18:17:29 -0500 Subject: RFR 4483582: Process needs NIO channels to multiplex in/out/err Message-ID: <566A0809.4030206@Oracle.com> The changes to enable using Selectable channels with Process input and output got hung up on an issue with the NIO Pipe implementation and behavior on Windows, the solution is elusive. At this point, I would like to proceed with the implementation on Unix variants and come back to the implementation Windows, possibly in JDK 9, possibly not. The implementation on Windows throws an IOException on ProcessBuilder.start if PIPE_CHANNEL redirection is selected in the builder. Please take a look at the API and implementation for Unix and comment. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-pipe-selector-4483582/ Thanks, Roger From vyom.tewari at oracle.com Fri Dec 11 06:46:58 2015 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Fri, 11 Dec 2015 12:16:58 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56696EF8.4060800@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56696EF8.4060800@oracle.com> Message-ID: <566A7162.2060805@oracle.com> +nio-dev On 12/10/2015 5:54 PM, David Holmes wrote: > Hi Vyom, > > Should this be reviewed by the NIO folk? It isn't obvious whether this > change impacts the interaction with the associated FileChannel - see > also https://bugs.openjdk.java.net/browse/JDK-6371642 > > Thanks, > David > > On 10/12/2015 8:52 PM, vyom wrote: >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >> >> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >> >> >> This change ensure that length() does not temporarily changes the file >> pointer and it will make sure that there is no race >> condition in case of multi thread uses. >> >> Thanks, >> Vyom >> >> >> >> From mandy.chung at oracle.com Fri Dec 11 07:18:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2015 23:18:10 -0800 Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com> Message-ID: <9F8FBD74-9FC7-4C54-950E-73E663E898FB@oracle.com> > On Dec 10, 2015, at 7:56 AM, Chris Hegarty wrote: > > sun.misc.HexDumpEncoder is an internal private API that is used almost > exclusively by the security library code. It should be moved out of sun.misc > and into a package more appropriate to its use, sun.security.util. > > HexDumpEncoder extends CharacterEncoder, which is slated for later > removal, so the minimal implementation was copied in-place ( no new > code ). > > http://cr.openjdk.java.net/~chegar/8144995/00/webrev/ Looks okay. Mandy From chris.hegarty at oracle.com Fri Dec 11 09:24:41 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Dec 2015 09:24:41 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <5669D986.30301@oracle.com> References: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> <5669D986.30301@oracle.com> Message-ID: <8213124C-C423-46F1-A7CF-1269CFC4F8C9@oracle.com> On 10 Dec 2015, at 19:59, Mandy Chung wrote: > On 12/10/2015 03:48 AM, Chris Hegarty wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~chegar/8056152/01/webrev/ > > Looks good. Thanks Mandy. > Nit: > 687 * the specified stack size, and inherits initial values for > Not sure if italic font of stack size is intentional since this constructor doesn't emphasize on this parameter. Right, replaced with: * the specified {@code stackSize}, and inherits initial values for -Chris. From paul.sandoz at oracle.com Fri Dec 11 09:36:58 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 Dec 2015 10:36:58 +0100 Subject: Reference.reachabilityFence In-Reply-To: <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> Message-ID: <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> Unless any strong objections are raised I plan to push the latest path on Monday. > > Updated: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html > > I think there is an opportunity to add further examples, but i would like to take a swing at that later on. > > >> - I now agree with you and Doug about calling this a "fence". Can we >> just name it "fence" rather than the wordier "reachabilityFence"? >> Looking at a typical invocation, >> >> Reference.reachabilityFence(); >> >> seems a bit redundant while >> >> Reference.fence(); >> >> reads quite nicely. Is there, or will there ever be, any other kind >> of reference-related fence? >> > > I doubt there will be another kind of reference fence, but it could be used in conjunction with other memory fences (currently on VarHandles) and if static imports are used it might look rather out of place as to what fence ?fence? actually refers to. That is why i prefer the longer more descriptive name. > > Paul. From nadeesh.tv at oracle.com Fri Dec 11 11:07:13 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 11 Dec 2015 16:37:13 +0530 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) Message-ID: <566AAE61.6060407@oracle.com> Hi all, Please review a fix for Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 Enhancement - Add java.time.Duration.dividedBy(Duration) webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ -- Thanks and Regards, Nadeesh TV From scolebourne at joda.org Fri Dec 11 11:15:11 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 11 Dec 2015 11:15:11 +0000 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: <566AAE61.6060407@oracle.com> References: <566AAE61.6060407@oracle.com> Message-ID: Missing blank line after the new method. Typo: "diviosr" Replace: Objects.requireNonNull(divisor, "divisor is null"); with Objects.requireNonNull(divisor, "divisor"); to match existing JSR-310 code. Test case looks fine. thanks Stephen On 11 December 2015 at 11:07, nadeesh tv wrote: > Hi all, > Please review a fix for > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 > > Enhancement - Add java.time.Duration.dividedBy(Duration) > > webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ > > -- > Thanks and Regards, > Nadeesh TV > From Alan.Bateman at oracle.com Fri Dec 11 11:17:20 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Dec 2015 11:17:20 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <8213124C-C423-46F1-A7CF-1269CFC4F8C9@oracle.com> References: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> <5669D986.30301@oracle.com> <8213124C-C423-46F1-A7CF-1269CFC4F8C9@oracle.com> Message-ID: <566AB0C0.9040000@oracle.com> On 11/12/2015 09:24, Chris Hegarty wrote: > : >> Nit: >> 687 * the specified stack size, and inherits initial values for >> Not sure if italic font of stack size is intentional since this constructor doesn't emphasize on this parameter. > Right, replaced with: > * the specified {@code stackSize}, and inherits initial values for > The latest webrev looks good to me. One small thing is that this patch chooses names for internal threads that didn't previously have useful names. In the case of fs.AbstractPoller and fs.PollingWatchService then "FileSystemWatchService" would be clearer. For WindowsSelectorImpl then "SelectorHelper" might be clearer. Cancellable is probably okay for now but it's too generic and probably needs a useful name to be passed in via runInterruptibly. -Alan From Alan.Bateman at oracle.com Fri Dec 11 11:24:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Dec 2015 11:24:36 +0000 Subject: [9] RFR of 8143394: PushbackReader throws NullPointerException In-Reply-To: References: <4D9A1B5B-842A-4A9B-942A-5790BF2D6855@oracle.com> <56617A37.3070408@oracle.com> <5666D9A0.5040705@oracle.com> Message-ID: <566AB274.7000405@oracle.com> On 08/12/2015 17:22, Brian Burkhalter wrote: > : > > An updated version with ?while? instead of ?if? is here: > > http://cr.openjdk.java.net/~bpb/8143394/webrev.02/ > > Looks okay to me now. -Alan From chris.hegarty at oracle.com Fri Dec 11 11:36:02 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Dec 2015 11:36:02 +0000 Subject: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals In-Reply-To: <566AB0C0.9040000@oracle.com> References: <55FE9D78-2BB6-4B6D-892A-BB208E38A2D2@oracle.com> <5669D986.30301@oracle.com> <8213124C-C423-46F1-A7CF-1269CFC4F8C9@oracle.com> <566AB0C0.9040000@oracle.com> Message-ID: <1DE83369-C3AF-4DD1-AD12-22D3D07776AC@oracle.com> On 11 Dec 2015, at 11:17, Alan Bateman wrote: > On 11/12/2015 09:24, Chris Hegarty wrote: >> : >>> Nit: >>> 687 * the specified stack size, and inherits initial values for >>> Not sure if italic font of stack size is intentional since this constructor doesn't emphasize on this parameter. >> Right, replaced with: >> * the specified {@code stackSize}, and inherits initial values for >> > The latest webrev looks good to me. Thanks for the review. > One small thing is that this patch chooses names for internal threads that didn't previously have useful names. In the case of fs.AbstractPoller and fs.PollingWatchService then "FileSystemWatchService" would be clearer. For WindowsSelectorImpl then "SelectorHelper" might be clearer. Cancellable is probably okay for now but it's too generic and probably needs a useful name to be passed in via runInterruptibly. I updated the names with your suggestions, in-place in the latest webrev.. -Chris. From sean.coffey at oracle.com Fri Dec 11 11:34:07 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 11 Dec 2015 11:34:07 +0000 Subject: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8 In-Reply-To: <5641CD9D.8080208@alexkasko.com> References: <561E7C96.9010207@azulsystems.com> <5627B1B8.6080307@azulsystems.com> <5641CD9D.8080208@alexkasko.com> Message-ID: <566AB4AF.60902@oracle.com> Hi Alex, I'm dropping jdk7u-dev mailing list for the moment. core-libs-dev is the mailing list where this review should happen. This fix would be required in JDK 9 first as per process. I think Sherman would be best to review if possible. Once it's soaked in JDK 9 for a few weeks, we could consider jdk8u and 7u backports. Regards, Sean. On 10/11/15 10:57, Alex Kashchenko wrote: > Hi, > > On 10/21/2015 04:39 PM, Nikolay Gorshkov wrote: >> Hi Sherman, >> >> Thank you for your reply! My answers are inlined. >> >> > Can you be more specific about the "class loading cases" above? >> Sounds >> > more like we have a memory leaking here (the real root cause)? for >> example >> > the inflateEnd() never gets called? >> >> I agree, the real root cause is probably the following issue that exists >> since the end of 2002: >> https://bugs.openjdk.java.net/browse/JDK-4797189 >> "Finalizers not called promptly enough" >> And it is "the absence of a general solution to the non-heap resource >> exhaustion problem". >> >> zlib's inflateEnd() function is called by >> void java.util.zip.Inflater.end(long addr) >> native method only, and this method, in turn, is called only by >> void java.util.zip.Inflater.end() >> and >> void java.util.zip.Inflater.finalize() >> methods. According to the experiments, the typical stack trace for >> instantiating java.util.zip.Inflater is: >> >> java.util.zip.Inflater.(Inflater.java:116) >> java.util.zip.ZipFile.getInflater(ZipFile.java:450) >> java.util.zip.ZipFile.getInputStream(ZipFile.java:369) >> java.util.jar.JarFile.getInputStream(JarFile.java:412) >> org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:222) >> >> >> >> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:592) >> >> >> java.security.AccessController.doPrivileged(Native Method) >> org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:591) >> >> >> >> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:447) >> >> >> java.lang.ClassLoader.loadClass(ClassLoader.java:358) >> java.lang.Class.forName0(Native Method) >> java.lang.Class.forName(Class.java:278) >> org.jboss.deployers.plugins.annotations.WeakClassLoaderHolder.loadClass(WeakClassLoaderHolder.java:72) >> >> >> >> >> It's quite hard to understand who is responsible for not calling >> Inflater.end() >> method explicitly; probably, it is the jboss/application's code. >> Unfortunately, >> we were in "it worked before and is broken now" customer situation >> here, so >> needed to fix it anyway. >> >> > From the doc/impl in inflate() it appears the proposed change >> should be >> > fine, though it's a little hacky, as you never know if it starts to >> return >> > Z_OK from some future release(s). Since the "current" implementation >> > never returns Z_OK, it might be worth considering to keep the Z_OK >> logic >> > asis in Inflater.c, together with the Z_BUF_ERROR, just in case? >> >> OK, I added handling of Z_OK code back. >> >> > I would be desired to add some words in Inflater.c to remind the >> > future maintainer why we switched from partial to finish and why to >> > check z_buf_error. >> >> I agree, added a comment. >> >> The updated webrev is available here: >> >> http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ >> > > The change looks good to me (not a Reviewer/Committer). > > Patched jdk7u also passes JCK-7 on RHEL 7.1. > > I forward-ported this patch to jdk9 (consulted with Nikolay Gorshkov > first), jtreg reproducer for jdk9 also works with jdk7u - > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003036.html > From nadeesh.tv at oracle.com Fri Dec 11 11:53:03 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 11 Dec 2015 17:23:03 +0530 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: References: <566AAE61.6060407@oracle.com> Message-ID: <566AB91E.7020903@oracle.com> Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ Regards, Nadeesh TV On 12/11/2015 4:45 PM, Stephen Colebourne wrote: > Missing blank line after the new method. > Typo: "diviosr" > Replace: > Objects.requireNonNull(divisor, "divisor is null"); > with > Objects.requireNonNull(divisor, "divisor"); > to match existing JSR-310 code. > > Test case looks fine. > > thanks > Stephen > > > On 11 December 2015 at 11:07, nadeesh tv wrote: >> Hi all, >> Please review a fix for >> >> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 >> >> Enhancement - Add java.time.Duration.dividedBy(Duration) >> >> webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From konstantin.shefov at oracle.com Fri Dec 11 11:54:00 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 11 Dec 2015 14:54:00 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <56588950.7050101@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> Message-ID: <566AB958.8010901@oracle.com> Hello Please review the new version on the patch. New webrev: Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 What has been changed: 1. Added tests for the new added methods. 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). Thanks -Konstantin On 11/27/2015 07:48 PM, Konstantin Shefov wrote: > Coleen, > Thanks for review > > On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >> >> I have a couple preliminary comments. First, there are no tests >> added with all this new functionality. Tests should be added with >> the functionality changeset, not promised afterward. > I will add tests. >> Secondly, I do not like that JDK code knows the implementation >> details of the JVM's constant pool tags. These should be only for >> internal use. > The package "sun.reflect" is for internal use only, so it shouldn?t be > a problem. >> My third comment is that I haven't looked carefully at this constant >> pool implementation but it seems very unsafe if the class is >> redefined and relies on an implementation detail in the JVM that can >> change. I will have more comments once I look more at the jvmti >> specification. >> >> thanks, >> Coleen >> >> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>> Hello >>> >>> Please, review modified webrev. >>> >>> I have added methods >>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>> index from a method, field or indy entry index; >>> getClassRefIndexAt(int index) - to get class entry index from a >>> method or field entry index; >>> >>> I removed previously added method >>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>> >>> New webrev: >>> Webrev hotspot: >>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>> >>> Thanks >>> -Konstantin >>> >>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>> Remi, >>>> >>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>> May be it also has sense to make a method >>>> "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type >>>> entry index for methods also. >>>> >>>> -Konstantin >>>> >>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>> Hi Konstantin, >>>>> Technically, getInvokedynamicRefInfoAt should be >>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the >>>>> nameAndType value of the InvokeDynamicRef. >>>>> >>>>> In term of API, I think it's better to decompose the API, i.e. to >>>>> have a method >>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>> that returns the nameAndType index and to reuse >>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of >>>>> Strings. >>>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Christian Thalinger" >>>>>> ?: "Konstantin Shefov" >>>>>> Cc: "hotspot-dev developers" , >>>>>> core-libs-dev at openjdk.java.net >>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>> sun.reflect.ConstantPool >>>>>> >>>>>> [CC'ing core-libs-dev] >>>>>> >>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>> wrote: >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Please review an enhancement to add three new methods to >>>>>>> sun.reflect.ConstantPool class. >>>>>>> The following methods are suggested: >>>>>>> >>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>> representation of name and type from a NameAndType constant pool >>>>>>> entry >>>>>>> with the specified index >>>>>>> >>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns >>>>>>> string >>>>>>> representation of name and type from an InvokeDynamic constant >>>>>>> pool entry >>>>>>> with the specified index >>>>>>> >>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of >>>>>>> a constant >>>>>>> pool entry with the specified index >>>>>>> >>>>>>> These three methods could be used for testing API working with >>>>>>> constant >>>>>>> pool, e.g. JVMCI. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>> Webrev hotspot: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>> Webrev jdk: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>> >>>>>>> Thanks >>>>>>> -Konstantin >>>>>> >>>> >>> >> > From scolebourne at joda.org Fri Dec 11 12:14:34 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 11 Dec 2015 12:14:34 +0000 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: <566AB91E.7020903@oracle.com> References: <566AAE61.6060407@oracle.com> <566AB91E.7020903@oracle.com> Message-ID: Fine by me. Stephen On 11 December 2015 at 11:53, nadeesh tv wrote: > > Hi all, > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ > Regards, > Nadeesh TV > > > On 12/11/2015 4:45 PM, Stephen Colebourne wrote: >> >> Missing blank line after the new method. >> Typo: "diviosr" >> Replace: >> Objects.requireNonNull(divisor, "divisor is null"); >> with >> Objects.requireNonNull(divisor, "divisor"); >> to match existing JSR-310 code. >> >> Test case looks fine. >> >> thanks >> Stephen >> >> >> On 11 December 2015 at 11:07, nadeesh tv wrote: >>> >>> Hi all, >>> Please review a fix for >>> >>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 >>> >>> Enhancement - Add java.time.Duration.dividedBy(Duration) >>> >>> webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > > -- > Thanks and Regards, > Nadeesh TV > From vitalyd at gmail.com Fri Dec 11 15:52:58 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Dec 2015 10:52:58 -0500 Subject: Reference.reachabilityFence In-Reply-To: <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> Message-ID: Hi Paul, No objections, but just wanted to summarize a couple of possible key performance issues that were raised on the concurrency-interest thread. You may have picked them up already, so pardon the repetition: 1) current impl/prototype is purposely barred from inlining - this will be a compiler optimization fence, particularly bad in loops 2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); }" idiom will significantly increase bytecode size, possibly impacting inlining. I'm sure you guys will address this in the end, but just wanted to reiterate those just in case :). Thanks sent from my phone On Dec 11, 2015 4:37 AM, "Paul Sandoz" wrote: > Unless any strong objections are raised I plan to push the latest path on > Monday. > > > > > Updated: > > > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html > < > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html > > > > > > I think there is an opportunity to add further examples, but i would > like to take a swing at that later on. > > > > > >> - I now agree with you and Doug about calling this a "fence". Can we > >> just name it "fence" rather than the wordier "reachabilityFence"? > >> Looking at a typical invocation, > >> > >> Reference.reachabilityFence(); > >> > >> seems a bit redundant while > >> > >> Reference.fence(); > >> > >> reads quite nicely. Is there, or will there ever be, any other kind > >> of reference-related fence? > >> > > > > I doubt there will be another kind of reference fence, but it could be > used in conjunction with other memory fences (currently on VarHandles) and > if static imports are used it might look rather out of place as to what > fence ?fence? actually refers to. That is why i prefer the longer more > descriptive name. > > > > Paul. > > From Roger.Riggs at Oracle.com Fri Dec 11 15:54:06 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Dec 2015 10:54:06 -0500 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: References: <566AAE61.6060407@oracle.com> <566AB91E.7020903@oracle.com> Message-ID: <566AF19E.1080500@Oracle.com> Hi Nadeesh, The API looks fine. I think the tests would be more readable if the Durations being tested were created in the data provider. Without a comment, it just looks like a lot of numbers. The test methods arguments would then be (Duration dividend, Duration divisor, long expected). + @DataProvider(name="dividedByDur_provider") + Object[][] provider_dividedByDur() { + return new Object[][] { + {new Duration.ofSeconds(0, 0), new Duration.ofSeconds(1, 0), 0}, etc. Thanks, Roger On 12/11/2015 7:14 AM, Stephen Colebourne wrote: > Fine by me. > > Stephen > > On 11 December 2015 at 11:53, nadeesh tv wrote: >> Hi all, >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ >> Regards, >> Nadeesh TV >> >> >> On 12/11/2015 4:45 PM, Stephen Colebourne wrote: >>> Missing blank line after the new method. >>> Typo: "diviosr" >>> Replace: >>> Objects.requireNonNull(divisor, "divisor is null"); >>> with >>> Objects.requireNonNull(divisor, "divisor"); >>> to match existing JSR-310 code. >>> >>> Test case looks fine. >>> >>> thanks >>> Stephen >>> >>> >>> On 11 December 2015 at 11:07, nadeesh tv wrote: >>>> Hi all, >>>> Please review a fix for >>>> >>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 >>>> >>>> Enhancement - Add java.time.Duration.dividedBy(Duration) >>>> >>>> webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> -- >> Thanks and Regards, >> Nadeesh TV >> From vitalyd at gmail.com Fri Dec 11 15:59:42 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Dec 2015 10:59:42 -0500 Subject: Reference.reachabilityFence In-Reply-To: References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> Message-ID: Sorry, one more point I forgot to mention: 3) what impact will this have, if any, on register allocation when a ref's lifetime is artificially extended without any "real" use. The thinking here is compiler should spill it and never reload, but it was unclear if it will do the right thing in its current form. sent from my phone On Dec 11, 2015 10:52 AM, "Vitaly Davidovich" wrote: > Hi Paul, > > No objections, but just wanted to summarize a couple of possible key > performance issues that were raised on the concurrency-interest thread. > You may have picked them up already, so pardon the repetition: > > 1) current impl/prototype is purposely barred from inlining - this will be > a compiler optimization fence, particularly bad in loops > > 2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); > }" idiom will significantly increase bytecode size, possibly impacting > inlining. > > I'm sure you guys will address this in the end, but just wanted to > reiterate those just in case :). > > Thanks > > sent from my phone > On Dec 11, 2015 4:37 AM, "Paul Sandoz" wrote: > >> Unless any strong objections are raised I plan to push the latest path on >> Monday. >> >> > >> > Updated: >> > >> > >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html >> < >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html >> > >> > >> > I think there is an opportunity to add further examples, but i would >> like to take a swing at that later on. >> > >> > >> >> - I now agree with you and Doug about calling this a "fence". Can we >> >> just name it "fence" rather than the wordier "reachabilityFence"? >> >> Looking at a typical invocation, >> >> >> >> Reference.reachabilityFence(); >> >> >> >> seems a bit redundant while >> >> >> >> Reference.fence(); >> >> >> >> reads quite nicely. Is there, or will there ever be, any other kind >> >> of reference-related fence? >> >> >> > >> > I doubt there will be another kind of reference fence, but it could be >> used in conjunction with other memory fences (currently on VarHandles) and >> if static imports are used it might look rather out of place as to what >> fence ?fence? actually refers to. That is why i prefer the longer more >> descriptive name. >> > >> > Paul. >> >> From chris.hegarty at oracle.com Fri Dec 11 16:30:47 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Dec 2015 16:30:47 +0000 Subject: RFR [9] Remove sun.misc.Request and RequestProcessor Message-ID: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> sun.misc.Request and RequestProcessor are not used by the JDK, and I can find no usage outside the JDK either. I would like to propose their removal. $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java $ hg rm src/java.base/share/classes/sun/misc/Request.java -Chris. From martinrb at google.com Fri Dec 11 17:00:05 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Dec 2015 09:00:05 -0800 Subject: Is setting -Dsun.jnu.encoding from the command line supposed to work? In-Reply-To: References: Message-ID: IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis wrote: > Hi, > > is setting -Dsun.jnu.encoding from the command line supposed to work > (i.e. if it should have any impact)? > > I'm just asking, because currently it doesn't make any difference. > While the command line arguments get parsed very early during VM > startup in Arguments::parse_each_vm_init_arg() they are only added to > the actual list of system properties later when > Java_java_lang_System_initProperties() (at System.c:398) calls > JVM_InitProperties(): > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xe50cfc] set_property(Handle, char const*, char > const*, Thread*)+0x30 > V [libjvm.so+0xe510ec] JVM_InitProperties+0xff4cd404 > C [libjava.so+0x25860] > Java_java_lang_System_initProperties+0xfffc3d50 (System.c:398) > j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 > j java.lang.System.initializeSystemClass()V+13 > v ~StubRoutines::call_stub > V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x628 > V [libjvm.so+0x11500d0] os::os_exception_wrapper(void > (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), > JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 > V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle > const&, JavaCallArguments*, Thread*)+0xb4 > V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c > V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, > KlassHandle, Symbol*, Symbol*, Thread*)+0x7c > V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 > V [libjvm.so+0x13656a4] > Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 > V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 > V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 > V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c > C [libjli.so+0x108e4] InitializeJVM+0x1b4 > C [libjli.so+0xda54] JavaMain+0xcc > > Unfortunately that's a little too late, because the "sun.jnu.encoding" > property is already set just at the beginning of > Java_java_lang_System_initProperties() (in System.c:189) by calling > GetJavaProperties() which in turn sets the property to the value > detected by ParseLocale(). This finally is either the result of > setlocale(LC_CTYPE, NULL) on Unix or "UTF-8 on MacOS X. > > C [libjava.so+0x2d734] ParseLocale+0x34 > C [libjava.so+0x2e070] GetJavaProperties+0x220 > C [libjava.so+0x211d8] > Java_java_lang_System_initProperties+0xfffbf6c8 (System.c:189) > j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 > j java.lang.System.initializeSystemClass()V+13 > v ~StubRoutines::call_stub > V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x628 > V [libjvm.so+0x11500d0] os::os_exception_wrapper(void > (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), > JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 > V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle > const&, JavaCallArguments*, Thread*)+0xb4 > V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c > V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, > KlassHandle, Symbol*, Symbol*, Thread*)+0x7c > V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 > V [libjvm.so+0x13656a4] > Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 > V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 > V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 > V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c > C [libjli.so+0x108e4] InitializeJVM+0x1b4 > C [libjli.so+0xda54] JavaMain+0xcc > > But between the calls to GetJavaProperties() and JVM_InitProperties() > the jdk already initializes the platform encoding ('fastEncoding' or > 'jnuEncoding' in jni_util.c) when it first calls > JNU_NewStringPlatform(): > > #0 initializeEncoding () at jni_util.c:626 > #1 JNU_NewStringPlatform () at jni_util.c:727 > #2 GetStringPlatform () at java_props_md.c:601 > #3 Java_java_lang_System_initProperties () at System.c:371 > > There it evaluates the value of the "sun.jnu.encoding" property (which > was taken from the the result of setlocale(LC_CTYPE, NULL) in > ParseLocale()). These values aren't changed any more after the value > of "sun.jnu.encoding" will be changed trough the call of > JVM_InitProperties() to the value set from the command line. > > Is this the way how it is supposed to work? > > I personally think it would be useful to be able to change > "sun.jnu.encoding" from the command line (even if this would be only > used for testing). But that would probably mean that we would have to > already handle -Dsun.jnu.encoding specially in the launcher. What do > you think? > > Regards, > Volker From Roger.Riggs at Oracle.com Fri Dec 11 17:01:49 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Dec 2015 12:01:49 -0500 Subject: RFR [9] Remove sun.misc.Request and RequestProcessor In-Reply-To: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> References: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> Message-ID: <566B017D.6060208@Oracle.com> +1 I looked at those a while back and though to look for more; definitely dead wood. Roger On 12/11/2015 11:30 AM, Chris Hegarty wrote: > sun.misc.Request and RequestProcessor are not used by the JDK, and I can > find no usage outside the JDK either. I would like to propose their removal. > > $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java > $ hg rm src/java.base/share/classes/sun/misc/Request.java > > -Chris. From volker.simonis at gmail.com Fri Dec 11 17:03:39 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Dec 2015 18:03:39 +0100 Subject: Is setting -Dsun.jnu.encoding from the command line supposed to work? In-Reply-To: References: Message-ID: It seems like you haven't complained loud enough :) On Fri, Dec 11, 2015 at 6:00 PM, Martin Buchholz wrote: > IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... > > On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis > wrote: >> Hi, >> >> is setting -Dsun.jnu.encoding from the command line supposed to work >> (i.e. if it should have any impact)? >> >> I'm just asking, because currently it doesn't make any difference. >> While the command line arguments get parsed very early during VM >> startup in Arguments::parse_each_vm_init_arg() they are only added to >> the actual list of system properties later when >> Java_java_lang_System_initProperties() (at System.c:398) calls >> JVM_InitProperties(): >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xe50cfc] set_property(Handle, char const*, char >> const*, Thread*)+0x30 >> V [libjvm.so+0xe510ec] JVM_InitProperties+0xff4cd404 >> C [libjava.so+0x25860] >> Java_java_lang_System_initProperties+0xfffc3d50 (System.c:398) >> j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> Unfortunately that's a little too late, because the "sun.jnu.encoding" >> property is already set just at the beginning of >> Java_java_lang_System_initProperties() (in System.c:189) by calling >> GetJavaProperties() which in turn sets the property to the value >> detected by ParseLocale(). This finally is either the result of >> setlocale(LC_CTYPE, NULL) on Unix or "UTF-8 on MacOS X. >> >> C [libjava.so+0x2d734] ParseLocale+0x34 >> C [libjava.so+0x2e070] GetJavaProperties+0x220 >> C [libjava.so+0x211d8] >> Java_java_lang_System_initProperties+0xfffbf6c8 (System.c:189) >> j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> But between the calls to GetJavaProperties() and JVM_InitProperties() >> the jdk already initializes the platform encoding ('fastEncoding' or >> 'jnuEncoding' in jni_util.c) when it first calls >> JNU_NewStringPlatform(): >> >> #0 initializeEncoding () at jni_util.c:626 >> #1 JNU_NewStringPlatform () at jni_util.c:727 >> #2 GetStringPlatform () at java_props_md.c:601 >> #3 Java_java_lang_System_initProperties () at System.c:371 >> >> There it evaluates the value of the "sun.jnu.encoding" property (which >> was taken from the the result of setlocale(LC_CTYPE, NULL) in >> ParseLocale()). These values aren't changed any more after the value >> of "sun.jnu.encoding" will be changed trough the call of >> JVM_InitProperties() to the value set from the command line. >> >> Is this the way how it is supposed to work? >> >> I personally think it would be useful to be able to change >> "sun.jnu.encoding" from the command line (even if this would be only >> used for testing). But that would probably mean that we would have to >> already handle -Dsun.jnu.encoding specially in the launcher. What do >> you think? >> >> Regards, >> Volker From chris.hegarty at oracle.com Fri Dec 11 17:05:23 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Dec 2015 17:05:23 +0000 Subject: RFR [9] Remove sun.misc.Request and RequestProcessor In-Reply-To: <566B017D.6060208@Oracle.com> References: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> <566B017D.6060208@Oracle.com> Message-ID: <456E5A75-9014-4824-BCCD-E1A937D802A0@oracle.com> On 11 Dec 2015, at 17:01, Roger Riggs wrote: > +1 Thanks Roger. > I looked at those a while back and though to look for more; definitely dead wood. There is some more dead wood, but these are logically connected and don?t touch any other areas. I?ll follow up on additional cleanups later. -Chris. > Roger > > > On 12/11/2015 11:30 AM, Chris Hegarty wrote: >> sun.misc.Request and RequestProcessor are not used by the JDK, and I can >> find no usage outside the JDK either. I would like to propose their removal. >> >> $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java >> $ hg rm src/java.base/share/classes/sun/misc/Request.java >> >> -Chris. > From Alan.Bateman at oracle.com Fri Dec 11 17:10:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Dec 2015 17:10:55 +0000 Subject: RFR [9] Remove sun.misc.Request and RequestProcessor In-Reply-To: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> References: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> Message-ID: <566B039F.8060308@oracle.com> On 11/12/2015 16:30, Chris Hegarty wrote: > sun.misc.Request and RequestProcessor are not used by the JDK, and I can > find no usage outside the JDK either. I would like to propose their removal. > > $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java > $ hg rm src/java.base/share/classes/sun/misc/Request.java > I think this is a case of shoot first, ask questions later. Good for it. -Alan From fjordmaze33 at gmail.com Mon Dec 7 19:38:00 2015 From: fjordmaze33 at gmail.com (Mike Dever Google) Date: Mon, 7 Dec 2015 14:38:00 -0500 Subject: RFR 8143404: Remove apple script engine code in jdk repository Message-ID: <9F2E67E7-55D2-4314-8894-AB931885BA32@gmail.com> Is there a work around? That really limits, actually kills a lot of functionality. From nikolay at azulsystems.com Fri Dec 11 12:09:16 2015 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Fri, 11 Dec 2015 15:09:16 +0300 Subject: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8 In-Reply-To: <566AB4AF.60902@oracle.com> References: <561E7C96.9010207@azulsystems.com> <5627B1B8.6080307@azulsystems.com> <5641CD9D.8080208@alexkasko.com> <566AB4AF.60902@oracle.com> Message-ID: <566ABCEC.90502@azulsystems.com> Hi Sean, Thank you for your attention to this matter! Actually, the code review request was sent to core-libs-dev alias a month ago: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036463.html Unfortunately, we haven't got any feedback yet. Thanks, Nikolay On 11.12.2015 14:34, Se?n Coffey wrote: > Hi Alex, > > I'm dropping jdk7u-dev mailing list for the moment. core-libs-dev is the > mailing list where this review should happen. This fix would be required in JDK > 9 first as per process. I think Sherman would be best to review if possible. > > Once it's soaked in JDK 9 for a few weeks, we could consider jdk8u and 7u > backports. > > Regards, > Sean. > > On 10/11/15 10:57, Alex Kashchenko wrote: >> Hi, >> >> On 10/21/2015 04:39 PM, Nikolay Gorshkov wrote: >>> Hi Sherman, >>> >>> Thank you for your reply! My answers are inlined. >>> >>> > Can you be more specific about the "class loading cases" above? Sounds >>> > more like we have a memory leaking here (the real root cause)? for >>> example >>> > the inflateEnd() never gets called? >>> >>> I agree, the real root cause is probably the following issue that exists >>> since the end of 2002: >>> https://bugs.openjdk.java.net/browse/JDK-4797189 >>> "Finalizers not called promptly enough" >>> And it is "the absence of a general solution to the non-heap resource >>> exhaustion problem". >>> >>> zlib's inflateEnd() function is called by >>> void java.util.zip.Inflater.end(long addr) >>> native method only, and this method, in turn, is called only by >>> void java.util.zip.Inflater.end() >>> and >>> void java.util.zip.Inflater.finalize() >>> methods. According to the experiments, the typical stack trace for >>> instantiating java.util.zip.Inflater is: >>> >>> java.util.zip.Inflater.(Inflater.java:116) >>> java.util.zip.ZipFile.getInflater(ZipFile.java:450) >>> java.util.zip.ZipFile.getInputStream(ZipFile.java:369) >>> java.util.jar.JarFile.getInputStream(JarFile.java:412) >>> org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:222) >>> >>> >>> >>> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:592) >>> >>> java.security.AccessController.doPrivileged(Native Method) >>> org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:591) >>> >>> >>> >>> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:447) >>> >>> >>> java.lang.ClassLoader.loadClass(ClassLoader.java:358) >>> java.lang.Class.forName0(Native Method) >>> java.lang.Class.forName(Class.java:278) >>> org.jboss.deployers.plugins.annotations.WeakClassLoaderHolder.loadClass(WeakClassLoaderHolder.java:72) >>> >>> >>> >>> >>> It's quite hard to understand who is responsible for not calling >>> Inflater.end() >>> method explicitly; probably, it is the jboss/application's code. >>> Unfortunately, >>> we were in "it worked before and is broken now" customer situation here, so >>> needed to fix it anyway. >>> >>> > From the doc/impl in inflate() it appears the proposed change should be >>> > fine, though it's a little hacky, as you never know if it starts to >>> return >>> > Z_OK from some future release(s). Since the "current" implementation >>> > never returns Z_OK, it might be worth considering to keep the Z_OK logic >>> > asis in Inflater.c, together with the Z_BUF_ERROR, just in case? >>> >>> OK, I added handling of Z_OK code back. >>> >>> > I would be desired to add some words in Inflater.c to remind the >>> > future maintainer why we switched from partial to finish and why to >>> > check z_buf_error. >>> >>> I agree, added a comment. >>> >>> The updated webrev is available here: >>> >>> http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ >>> >> >> The change looks good to me (not a Reviewer/Committer). >> >> Patched jdk7u also passes JCK-7 on RHEL 7.1. >> >> I forward-ported this patch to jdk9 (consulted with Nikolay Gorshkov first), >> jtreg reproducer for jdk9 also works with jdk7u - >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003036.html >> > From chris.hegarty at oracle.com Fri Dec 11 17:22:46 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Dec 2015 17:22:46 +0000 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections Message-ID: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> More technical debt in sun.misc? Java SE has had support for Queues in Collections for many major releases, sun.misc.Queue seems to predate that. I cannot find any usages outside of the JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to provide the necessary minimum functionality required by AppletPanel, FIFO blocking operations. The changes are quite small so I just included the diffs inline. Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion either way. $ hg rm src/java.base/share/classes/sun/misc/Queue.java diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java @@ -38,6 +38,7 @@ import java.security.*; import java.util.*; import java.util.Locale; +import java.util.concurrent.LinkedBlockingQueue; import sun.awt.AWTAccessor; import sun.awt.AppContext; import sun.awt.EmbeddedFrame; @@ -45,7 +46,6 @@ import sun.misc.ManagedLocalsThread; import sun.misc.MessageUtils; import sun.misc.PerformanceLogger; -import sun.misc.Queue; import sun.security.util.SecurityConstants; /** @@ -247,8 +247,7 @@ /** * AppletEvent Queue */ - private Queue queue = null; - + private LinkedBlockingQueue queue = null; public synchronized void addAppletListener(AppletListener l) { listeners = AppletEventMulticaster.add(listeners, l); @@ -276,10 +275,10 @@ synchronized(this) { if (queue == null) { //System.out.println("SEND0= " + id); - queue = new Queue<>(); + queue = new LinkedBlockingQueue<>(); } - Integer eventId = Integer.valueOf(id); - queue.enqueue(eventId); + boolean inserted = queue.offer(id); + assert inserted; notifyAll(); } if (id == APPLET_QUIT) { @@ -303,8 +302,8 @@ while (queue == null || queue.isEmpty()) { wait(); } - Integer eventId = queue.dequeue(); - return new AppletEvent(this, eventId.intValue(), null); + int eventId = queue.take(); + return new AppletEvent(this, eventId, null); } boolean emptyEventQueue() { -Chris. From xueming.shen at oracle.com Fri Dec 11 17:53:31 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 11 Dec 2015 09:53:31 -0800 Subject: Is setting -Dsun.jnu.encoding from the command line supposed to work? In-Reply-To: References: Message-ID: <566B0D9B.90501@oracle.com> Don't do it, that's all I would suggest :-) same as "file.encoding", they are both supposed to be informative read-only system property. Here is the history of sun.jnu.encoding http://ccc.us.oracle.com/4958170 -sherman On 12/11/2015 09:00 AM, Martin Buchholz wrote: > IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... > > On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis > wrote: >> Hi, >> >> is setting -Dsun.jnu.encoding from the command line supposed to work >> (i.e. if it should have any impact)? >> >> I'm just asking, because currently it doesn't make any difference. >> While the command line arguments get parsed very early during VM >> startup in Arguments::parse_each_vm_init_arg() they are only added to >> the actual list of system properties later when >> Java_java_lang_System_initProperties() (at System.c:398) calls >> JVM_InitProperties(): >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xe50cfc] set_property(Handle, char const*, char >> const*, Thread*)+0x30 >> V [libjvm.so+0xe510ec] JVM_InitProperties+0xff4cd404 >> C [libjava.so+0x25860] >> Java_java_lang_System_initProperties+0xfffc3d50 (System.c:398) >> j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> Unfortunately that's a little too late, because the "sun.jnu.encoding" >> property is already set just at the beginning of >> Java_java_lang_System_initProperties() (in System.c:189) by calling >> GetJavaProperties() which in turn sets the property to the value >> detected by ParseLocale(). This finally is either the result of >> setlocale(LC_CTYPE, NULL) on Unix or "UTF-8 on MacOS X. >> >> C [libjava.so+0x2d734] ParseLocale+0x34 >> C [libjava.so+0x2e070] GetJavaProperties+0x220 >> C [libjava.so+0x211d8] >> Java_java_lang_System_initProperties+0xfffbf6c8 (System.c:189) >> j java.lang.System.initProperties(Ljava/util/Properties;)Ljava/util/Properties;+0 >> j java.lang.System.initializeSystemClass()V+13 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xdbc940] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x628 >> V [libjvm.so+0x11500d0] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x68 >> V [libjvm.so+0xdbc2d0] JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*)+0xb4 >> V [libjvm.so+0xdbbef0] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13c >> V [libjvm.so+0xdbc010] JavaCalls::call_static(JavaValue*, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x7c >> V [libjvm.so+0x135be0c] call_initializeSystemClass(Thread*)+0xd0 >> V [libjvm.so+0x13656a4] >> Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x294 >> V [libjvm.so+0x1365ff4] Threads::create_vm(JavaVMInitArgs*, bool*)+0x630 >> V [libjvm.so+0xe15674] JNI_CreateJavaVM_inner(JavaVM_**, void**, void*)+0x100 >> V [libjvm.so+0xe15954] JNI_CreateJavaVM+0xff493a9c >> C [libjli.so+0x108e4] InitializeJVM+0x1b4 >> C [libjli.so+0xda54] JavaMain+0xcc >> >> But between the calls to GetJavaProperties() and JVM_InitProperties() >> the jdk already initializes the platform encoding ('fastEncoding' or >> 'jnuEncoding' in jni_util.c) when it first calls >> JNU_NewStringPlatform(): >> >> #0 initializeEncoding () at jni_util.c:626 >> #1 JNU_NewStringPlatform () at jni_util.c:727 >> #2 GetStringPlatform () at java_props_md.c:601 >> #3 Java_java_lang_System_initProperties () at System.c:371 >> >> There it evaluates the value of the "sun.jnu.encoding" property (which >> was taken from the the result of setlocale(LC_CTYPE, NULL) in >> ParseLocale()). These values aren't changed any more after the value >> of "sun.jnu.encoding" will be changed trough the call of >> JVM_InitProperties() to the value set from the command line. >> >> Is this the way how it is supposed to work? >> >> I personally think it would be useful to be able to change >> "sun.jnu.encoding" from the command line (even if this would be only >> used for testing). But that would probably mean that we would have to >> already handle -Dsun.jnu.encoding specially in the launcher. What do >> you think? >> >> Regards, >> Volker From mandy.chung at oracle.com Fri Dec 11 17:45:15 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Dec 2015 09:45:15 -0800 Subject: RFR [9] Remove sun.misc.Request and RequestProcessor In-Reply-To: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> References: <3DB7D26B-18EE-462F-AD92-FBF5BE01FAA0@oracle.com> Message-ID: <566B0BAB.8080502@oracle.com> On 12/11/2015 08:30 AM, Chris Hegarty wrote: > sun.misc.Request and RequestProcessor are not used by the JDK, and I can > find no usage outside the JDK either. I would like to propose their removal. > > $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java > $ hg rm src/java.base/share/classes/sun/misc/Request.java +1 Mandy From huizhe.wang at oracle.com Fri Dec 11 17:54:22 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 11 Dec 2015 09:54:22 -0800 Subject: RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x Message-ID: <566B0DCE.5060606@oracle.com> This is a fix for an edge case. All tests passed after the fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8068839 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8068839/webrev/ Thanks, Joe From Roger.Riggs at Oracle.com Fri Dec 11 18:02:22 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Dec 2015 13:02:22 -0500 Subject: RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x In-Reply-To: <566B0DCE.5060606@oracle.com> References: <566B0DCE.5060606@oracle.com> Message-ID: <566B0FAE.9050307@Oracle.com> Hi Joe, Looks fine. Roger On 12/11/2015 12:54 PM, huizhe wang wrote: > This is a fix for an edge case. All tests passed after the fix. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8068839 > > webrev: > http://cr.openjdk.java.net/~joehw/jdk9/8068839/webrev/ > > Thanks, > Joe > From xueming.shen at oracle.com Fri Dec 11 18:14:54 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 11 Dec 2015 10:14:54 -0800 Subject: Is setting -Dsun.jnu.encoding from the command line supposed to work? In-Reply-To: <566B0D9B.90501@oracle.com> References: <566B0D9B.90501@oracle.com> Message-ID: <566B129E.80801@oracle.com> On 12/11/2015 09:53 AM, Xueming Shen wrote: > Don't do it, that's all I would suggest :-) same as "file.encoding", they are > both supposed to be informative read-only system property. > > Here is the history of sun.jnu.encoding > http://ccc.us.oracle.com/4958170 > My apology, forgot the "ccc" is still an internal site. Here is the copy/paste of the history. It's mainly to solve the Windows' user/system locale setting issue. It is supposed to be an informative system property to help the jvm to communicate with the underlying os with the appropriate encoding. Its value should be absolutely obtained from the system setting not set from the command line. While it might be desired in some use scenario to have the file.encoding set to a different value, I'm not convinced that the sun.jnu.encoding need to be customized -sherman -------------------------------------------------------------------------------------------------------------- Problem This request addresses the following 3 bugs. 4958170: javaw does not retrieve the user locale 4891531: javaw and java get different default locale from OS 4989534: Regional / Language setting improperly detected with a multi-user PC Windows has 2 locale settings called User Locale and System Locale. According to Microsoft's documentation System Locale is a legacy compatibility mode rather than a true locale and User Locale is what Windows really use for formatting dates, times, currentcy and large numbers. JDK's documentation has expressly stated that these two must be the same to be supported, but users do not always follow this and JDK is internally inconsistent if these settings are different depending on how java is launched. Also an incorrect change to javaw in 1.4.2 to attempt to fix one observed inconsistent case of different System Locale and User Locale setting created yet another internal inconsistency. These JDK bugs and inconsistencies need to be resolved. Background: (1)From the very beginning we have 2 groups of end user on W2k/XP who have different(opposite) opinions on how the java default locale should be set, based on their different use scenarios. One group believes the default java locale should be the same as what Windows System Locale is and other prefers that it should be the same as Windows User Locale. Until recently we have been purposely avoiding to face this issue directly (because the reality that java runtime is NOT a real win32 Unicode app) by insisting the SUPPORTED use scenario is to set both UserLocale and SystemLocale to the same locale/language on W2K/XP. The related doc is at http://java.sun.com/j2se/1.4.2/docs/guide/intl/locale.doc.html#jfc However we've started to see more and more bugs get filed to complain this restriction (guess this is mostly because more and more apps/ users have been migrating to W2K/XP, which is a real multilingual environment compared to previous OSs) and we believe we need to make it clear in Tiger that the java default locale should be set solely based on Windows User Locale setting in ControlPanel's RegionSetting, from the perspective of what User Locale is defined on Windows and what java default Locale is defined on Java platform. You can find the official MS definition of System Locale, User Locale and Thread Locale at http://www.microsoft.com/globaldev/reference/localetable.mspx The highlights of some concepts we care are: (a)Windows Locale A locale is either a language or a language in combination with a country that a user wants to use for formatting dates, times, currency, and large numbers. (b)Windows User Locale The user locale determines, which default settings a user wants to use for formatting dates, times, currency, and large numbers. (c)Windows System Locale The system locale is not really a locale. It determines which codepages (ANSI, DOS, and Macintosh) are used on the system by default. ... If it weren't be so long the system locale should be called legacy applications compatibility setting, because that is really what it is. (d)Windows Thread Locale The thread locale defaults to the user locale and determines the formatting dates, times, currency, and large numbers for the thread. It can be changed programmatically using the API SetThreadLocale. In most cases the thread locale should not be overwritten And "java locale" is defined as A Locale object represents a specific geographical, political, or cultural region. An operation that requires a Locale to perform its task is called locale-sensitive and uses the Locale to tailor information for the user. For example, displaying a number is a locale-sensitive operation--the number should be formatted according to the customs/conventions of the user's native country, region, or culture. So it's clear that Windows System Locale actually has nothing to do with locale and java locale at all, java locale definitely should not derived from Windows System Locale setting. Having said that the fact java runtime is a "Ansi" non-unicode app forces java runtime to still have heavy dependency on Windows System Locale setting. More specifically the def of system property "file.encoidng" and some of its usage in j2se's implementation (jni_util.c), currently this system property is derived from the same setting of what the default java locale comes from. It's not a problem when System Locale and User locale are the same, but when these 2 setting are incompatible, some usages of "file.encoding" will be problematic (Considering when you system locale is Japanese and user locale is English and you, as a Ansi app, try to speak with the System by using English). The list of some of these user locale/System Locale setting related bugs is at http://javaweb.sfbay/~sherman/Win32_locale_setting_bugs.html (2)The "Inconsistency" of Windows API doc and Windows implementation of GetThreadLocale() when launching app from Dos/Command Prompt as a console app (in java's case, launch java from "java") Based on Windows document, GetThreadLocale() should return the Locale of this thread and it should be the "User Locale", it's true for most of the cases. But in scenario like -System Locale is set to a DBCS locale (like Japanese or Chinese) -User Locale is set to a SBCS locale (like English) -Start the app from Dos Prompt (as a concole app) The GetThreadLocale() will not return the value set in User Locale (English) but what set in System Locale (Japanese), my guess is that this is because the Dos Prompt/Command Prompt itself is a Ansi/non-Uniocde app and it is doing something special when the system locale is a DBCS locale. (3)Starting from JDK1.4.2 the default locale of java runtime will be set to different values when launched from "javaw" or "java" on W2K and XP, if the User Locale and System Locale settings of the underlying Windows system are different. More specifically, if java runtime is launched from "javaw", the default locale will be set based on Windows System Locale setting and if launched from "java" the java default locale will be set based on Windows User Locale setting. This causes big confusion for developers and end users who work on multilingual W2K/XP environment. The direct trigger of #4891531 is the fix for bug#4629351 which in launcher's win32 java_md.c we added one line code in WinMain SetThreadLocale(GetSystemDefaultLCID()); to force the java runtime's thread locale to be Windows System Locale, the result of this change is that the java default locale will be set to whatever set in Windows System Locale. But this line of code will never be executed if we launch java runtime through "java" command, this is where the inconsistency comes from. Solution To the fullest extent possible, make the User Locale the default locale used by the JRE. The basic fix for this is to call the correct Windows API and use that as the basis for setting the Java locale and system property file.encoding. This will make the windows behavior consistent with the experience on Solaris and Linux. However since some parts of the JRE are still a "windows legacy application" that cannot always use the user locale (ie not all of the JRE is a unicode application in the windows meaning of the term) then some additional measures need to be, so the proposed fixes are (1)Removed the inappropriate fix of #4629351 (from java_md.c). The java default locale (language, country) and the file.encoding system property will be solely based on what the User Locale is (use GetUserDefaultLCID() in java_props.md). (2)We will not change our public position in Tiger to claim official support for runtime environment with different (incompatibal) System Locale and User Locale setting on XP/W2K because we are still running java runtime as a non-Unicode app and the sequence that there are still issues left in some places that can not be solved before we migrate vm and launcher code to a pure unicode-based implementaiton (3)Introduce in a new "internal use only" system property sun.jnu.encoding to be used in jni_util.c to replace the file.encoding in method "initializeEncoding(JNIEnv *env)", this change will affect 2 jni_util.c methods on Windows NewStringPlatform GetPlatformStringChar Compared to file.encoding, the sun.jnu.encoding property will be set based on what Windows System Locale is on Windows platforms. On Solaris/Linux this priority will remain the same as file.encoding. The reasons why we need to introduce this new property and use it in jni_util.c are (1)NewStringPlatform and GetPlatformStringChar are 2 methods used internally by j2se impl to do the text encoding conversion when need to talk with underlying platform (again, this is because our runtime is not a win32 Unicode app). This "platform encoding" must be the encoding that matches what the System Locale setting is. It does not make any sense (and it does not work either) to use the encoding derived from the User Locale setting, the Windows system will simply not understand it if System Locale and User Locale setting are not compatible. (2)We want to have file.encoding derived from what the Windows User Locale setting is (when have different System Locale and User Locale settings), file.encoding which will mostly be used to set the default encoding for "contents" of input/output stream should always match what the default java locale is (which is from User Locale setting now). You can find all usages of NewStringPlatform and GetPlatformString inside j2se at http://javaweb.sfbay/~sherman/NewStringPlatform_GetStringPlatformChar and the usage of "file.encoding" at http://javaweb.sfbay/~sherman/file_encoding The webrev for proposed fix for your reference is at http://javaweb.sfbay/~sherman/Webrevs/webrev_4891531_4958170 (regression test cases will be added) Interface summary exported private property file.encoding will be solely derived from User Locale setting on Windows internal property sun.jnu.encoding will be solely derivied from System Locale setting on Windows imported external other GetUserDefaultLCID, GetSystemDefaultLCID, GetThreadLocale exported external method java.util.Locale.getDefault() and java.nio.charset.Charset.defaultCharset() Specification (1)sun.jnu.encoding: An internal use only system property that derived from what Windows System Locale setting is on Windows platform. It has the same value as file.encoding on Solaris and Linux platform. (2)java.util.Locale.getDefault() java.nio.charset.Charset.defaultCharset() We never publicly documented how the values returned by these 2 methods are derived from the host env setting and still are not going to document it. However, the return values of these 2 methods are now consistently derived on Windows from the user locale as reported by GetUserDefaultLCID. (3)file.encoding We never publicly documented how this property value is derived from the host environment settings and still are not going to document it. However, this value is now consistently derived on Windows from the user locale as reported by GetUserDefaultLCID. Compatibility risk: low First of all the proposed solution should NOT have any compatibility impact to our "official supported" use scenario in which the Windows System locale and User locale are set to the same language. What we are trying to do is to make the java runtime behave more consistent in scenarios that we dont officially support but more and more end users are running into. In these scenarios our launcher "java" and "javaw" have severe inconsistent behavior which I think we have to pay a price to fix. Followings are the impact that we know we will have with the proposed solution. (1)file.encoding will always be derived from User Locale setting. Compared to current impl, file.encoding in proposed change will always be derived from user locale setting, this will cause a incompatible behavior to some apps (if they depend on the assumption that file.encoding will always be derived from System Locale setting)when the System Locale and User Locale settings are not "compatible" (even this is not an official supported scenario on Java/JDK i18n document mentioned before) But given the fact that our current impl already breaks this assumption in some env scenarios and have severe inconsistency here and there, I believe this is a decision/choice we must to make and a risk we have to face with, if we want to address the inconsistency (2)concern of adding a sun.jnu.encoding and using it instead of file.encoding in jni_util.c The win32 FileSystem and awt has been migrated to MSLU, so there is no compatibility issue in this 2 big chunks. Other than that j2se currently does not have heavily dependency on these 2 methods, I've scanned all places (see url above) where these 2 jni_util methods are being used, my conclusion is that it makes more sense to use the encoding from "System Locale" setting instead of the "User Locale" setting in all of the places. The only places that I would have little concern of compatibility are (1)in System.c when converting those system properties such as usr.name, usr.dir from platform encoding to uncode encoding and (2)in launcher code when parsing the command line args to unicode encoded args for java main class, in scenario like -System Locale is set to English -User Locale is set to Japanese -Someone tries to pass in a command line option/properties/flag in Japanese like -Dxxx=yyyy (which yyyy is in Japanese) Since the "sun.jnu.encoding" now is "English"/cp1252, this Japanese option/flag/properties will not be converted correctly into java runtime. But given the fact the Windows System Locale now is "English /cp1252", even you are able to input the Japanese from command line (in this case the "dos prompt app" is in English/cp1252 mode, it does not work well with Japanese, though you can use copy/paste...), this Japanese text has been collapsed already even before java gets a hand on it, means the text in args from C main and from getenv is collapsed already. So this should not be an issue. It does not work anyway, even in current impl. 3)What we have in 1.4.1, 1.4.2 and in proposed 1.5 when the Windows settings are different. a)UserLocale=Japanese/SystemLocale=English java Java file.encoding sun.jnu.encoding launcher Locale property property 1.4.1/java Ja MS932 1.4.1/javaw ja MS932 1.4.2/java ja MS932 1.4.2/javaw en Cp1252 1.5.0/java ja MS932 Cp1252 1.5.0/javaw ja MS932 Cp1252 b)UserLocale=English/SystemLocale=Japanese java Java file.encoding sun.jnu.encoding launcher Locale property property 1.4.1/java ja MS932 1.4.1/javaw en Cp1252 1.4.2/java ja MS932 1.4.2/javaw ja MS932 1.5.0/java en Cp1252 MS932 1.5.0/javaw en Cp1252 MS932 From lance.andersen at oracle.com Fri Dec 11 18:07:51 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 11 Dec 2015 13:07:51 -0500 Subject: RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x In-Reply-To: <566B0DCE.5060606@oracle.com> References: <566B0DCE.5060606@oracle.com> Message-ID: Hi Joe, I think this looks OK. My only suggestion is I am not a fan of creating a one-off type of test vs integrating if at all possible a test such as this into existing test(s). The reason is it can get out of control the number of one off tests and makes it a bit harder to know the coverage if you have a slew of files to review. Again, feel free to push, and ignore me :-) Best Lance On Dec 11, 2015, at 12:54 PM, huizhe wang wrote: > This is a fix for an edge case. All tests passed after the fix. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8068839 > > webrev: > http://cr.openjdk.java.net/~joehw/jdk9/8068839/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Fri Dec 11 19:34:48 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Dec 2015 11:34:48 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups (was: question on jdk_collections group in jdk/test/TEST.groups) In-Reply-To: <5669FF22.6010705@oracle.com> References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> <5669FF22.6010705@oracle.com> Message-ID: This is "fine", but jsr166 maintainers won't use it - we maintain our own list of tests to run. There's enough collection/concurrency overlap and too much testing ad-hoc-ery in existing jtreg tests. Eg. MOAT should be run for changes to any collection. If this is a test set you personally like, sure go ahead and commit. On Thu, Dec 10, 2015 at 2:39 PM, Stuart Marks wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8145139 > > I've appended a patch below; please review. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1449787050 28800 > # Thu Dec 10 14:37:30 2015 -0800 > # Node ID 5b630d0c118b115439672b29aff0d195132d4f96 > # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 > 8145139: clean up jdk_collections and jdk_concurrent test groups > Reviewed-by: XXX > > diff -r 7f644a5d554a -r 5b630d0c118b test/TEST.groups > --- a/test/TEST.groups Wed Dec 09 15:27:21 2015 -0500 > +++ b/test/TEST.groups Thu Dec 10 14:37:30 2015 -0800 > @@ -95,13 +95,10 @@ > -:jdk_concurrent \ > -:jdk_stream > > -# java.util.concurrent (JSR-166) > +# java.util.concurrent > # Maintained by JSR-166 EG (Doug Lea et al) > -# Deque and PriorityQueue are also generally maintained by JSR-166 > jdk_concurrent = \ > - java/util/concurrent \ > - java/util/Deque \ > - java/util/PriorityQueue > + java/util/concurrent > > # Java Collections Framework > jdk_collections = \ > @@ -114,19 +111,22 @@ > java/util/BitSet \ > java/util/Collection \ > java/util/Collections \ > + java/util/Comparator \ > + java/util/Deque \ > java/util/EnumMap \ > java/util/EnumSet \ > - java/util/Comparator \ > - java/util/Iterator \ > java/util/HashMap \ > + java/util/HashSet \ > java/util/Hashtable \ > java/util/IdentityHashMap \ > - java/util/List \ > + java/util/Iterator \ > java/util/LinkedHashMap \ > java/util/LinkedHashSet \ > java/util/LinkedList \ > + java/util/List \ > java/util/Map \ > java/util/NavigableMap \ > + java/util/PriorityQueue \ > java/util/TimSort \ > java/util/TreeMap \ > java/util/Vector \ > From Roger.Riggs at Oracle.com Fri Dec 11 20:07:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Dec 2015 15:07:26 -0500 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> Message-ID: <566B2CFE.3030802@Oracle.com> Hi, Stephen, can you confirm that the added text and test in DateTimeFormatter is not a specification change? Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed. test/java/time/tck/java/time/TCKZonedDateTime.java Ramanand, some comments on the new test: - The 'private' qualifier on the tests and data providers is not used in the current tests and is not consistently present in the new one. Since it has little/no function, the tests would be a bit cleaner without it. - Typically, test that have data dependencies (such as the timezone data) cannot be used for compatibility to the specification, but the data is stable and it seems unavoidable in this case. - Are all of the data cases necessary to validate the specification? Redundant cases extend the testing time without adding more confidence to the quality. Thanks, Roger On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > I believe this is suitable for committing, thanks, other reviews welcome! > Stephen > > > > On 10 December 2015 at 15:36, Ramanand Patil wrote: >> Hi all, >> >> Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >> >> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. >> >> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >> >> >> Regards, >> Ramanand. >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Wednesday, December 09, 2015 4:46 PM >> To: core-libs-dev >> Cc: i18n-dev >> Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition >> >> The logic looks fine. >> >> In the main code, this part >> .getLong(INSTANT_SECONDS); >> can be replaced with >> .toEpochSecond(); >> which will be slightly faster. >> >> In the test case, this part >> .plus(15, ChronoUnit.MINUTES); >> can be replaced with >> .plusMinutes(15) >> >> And >> .with(ChronoField.OFFSET_SECONDS, >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >> can be replaced with >> .with(ZoneOffset.of(offsetSamples[j])) >> >> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. >> >> thanks for fixing this >> Stephen >> >> >> >> On 9 December 2015 at 07:44, Ramanand Patil wrote: >>> HI all, >>> >>> >>> >>> Please review a fix for Bug - HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>> >>> >>> >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). >>> >>> >>> >>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>> >>> >>> >>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Ramanand. From stuart.marks at oracle.com Fri Dec 11 20:10:36 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Dec 2015 12:10:36 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups In-Reply-To: References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> <5669FF22.6010705@oracle.com> Message-ID: <566B2DBC.4030305@oracle.com> Hm, not really a ringing endorsement. On a second look, are the new test groups sufficiently close to the ones the JSR 166 maintainers would want to run? For example, your little 'find' script > (cd ~/ws/jdk9/jdk/test && find java/util -type d \( \( -name > concurrent -prune \) -o -name '*Set*' -o -name '*Map*' -o -name > '*List*' -o -name '*Queue*' -o -name '*Deque*' -o -name '*Collection*' > -o -name '*Vector*' -o -name '*Hashtable*' -o -name '*Array*' \) ) produces a list of tests that's quite close to the union of the jdk_collections and jdk_concurrent groups. The only difference is that the test groups include four additional tests: +java/util/Comparator/BasicTest.java +java/util/Comparator/TypeTest.java +java/util/Iterator/IteratorDefaults.java +java/util/Iterator/PrimitiveIteratorDefaults.java I did this by comparing the results of "jtreg -listtests": 1. jtreg -listtests $(find ...) 2. jtreg -listtests :jdk_collections :jdk_concurrent s'marks On 12/11/15 11:34 AM, Martin Buchholz wrote: > This is "fine", but jsr166 maintainers won't use it - we maintain our > own list of tests to run. There's enough collection/concurrency > overlap and too much testing ad-hoc-ery in existing jtreg tests. Eg. > MOAT should be run for changes to any collection. If this is a test > set you personally like, sure go ahead and commit. > > > On Thu, Dec 10, 2015 at 2:39 PM, Stuart Marks wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145139 >> >> I've appended a patch below; please review. >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1449787050 28800 >> # Thu Dec 10 14:37:30 2015 -0800 >> # Node ID 5b630d0c118b115439672b29aff0d195132d4f96 >> # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 >> 8145139: clean up jdk_collections and jdk_concurrent test groups >> Reviewed-by: XXX >> >> diff -r 7f644a5d554a -r 5b630d0c118b test/TEST.groups >> --- a/test/TEST.groups Wed Dec 09 15:27:21 2015 -0500 >> +++ b/test/TEST.groups Thu Dec 10 14:37:30 2015 -0800 >> @@ -95,13 +95,10 @@ >> -:jdk_concurrent \ >> -:jdk_stream >> >> -# java.util.concurrent (JSR-166) >> +# java.util.concurrent >> # Maintained by JSR-166 EG (Doug Lea et al) >> -# Deque and PriorityQueue are also generally maintained by JSR-166 >> jdk_concurrent = \ >> - java/util/concurrent \ >> - java/util/Deque \ >> - java/util/PriorityQueue >> + java/util/concurrent >> >> # Java Collections Framework >> jdk_collections = \ >> @@ -114,19 +111,22 @@ >> java/util/BitSet \ >> java/util/Collection \ >> java/util/Collections \ >> + java/util/Comparator \ >> + java/util/Deque \ >> java/util/EnumMap \ >> java/util/EnumSet \ >> - java/util/Comparator \ >> - java/util/Iterator \ >> java/util/HashMap \ >> + java/util/HashSet \ >> java/util/Hashtable \ >> java/util/IdentityHashMap \ >> - java/util/List \ >> + java/util/Iterator \ >> java/util/LinkedHashMap \ >> java/util/LinkedHashSet \ >> java/util/LinkedList \ >> + java/util/List \ >> java/util/Map \ >> java/util/NavigableMap \ >> + java/util/PriorityQueue \ >> java/util/TimSort \ >> java/util/TreeMap \ >> java/util/Vector \ >> From martinrb at google.com Fri Dec 11 20:23:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Dec 2015 12:23:55 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups In-Reply-To: <566B2DBC.4030305@oracle.com> References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> <5669FF22.6010705@oracle.com> <566B2DBC.4030305@oracle.com> Message-ID: I added Iterator and Comparator to "my" list of tests. Thanks! The key difference is that we don't try to separate concurrent and non-concurrent collections, so my "collections test set" includes all of /java/util/concurrent even though it's technically overkill. But we've optimized those tests so they run much more quickly now! So I encourage you to also make jdk_concurrent a subset of jdk_collections if that's compatible with the makefile conventions. On Fri, Dec 11, 2015 at 12:10 PM, Stuart Marks wrote: > Hm, not really a ringing endorsement. > > On a second look, are the new test groups sufficiently close to the ones the > JSR 166 maintainers would want to run? For example, your little 'find' > script > >> (cd ~/ws/jdk9/jdk/test && find java/util -type d \( \( -name >> concurrent -prune \) -o -name '*Set*' -o -name '*Map*' -o -name >> '*List*' -o -name '*Queue*' -o -name '*Deque*' -o -name '*Collection*' >> -o -name '*Vector*' -o -name '*Hashtable*' -o -name '*Array*' \) ) > > > produces a list of tests that's quite close to the union of the > jdk_collections and jdk_concurrent groups. The only difference is that the > test groups include four additional tests: > > +java/util/Comparator/BasicTest.java > +java/util/Comparator/TypeTest.java > +java/util/Iterator/IteratorDefaults.java > +java/util/Iterator/PrimitiveIteratorDefaults.java > > I did this by comparing the results of "jtreg -listtests": > > 1. jtreg -listtests $(find ...) > 2. jtreg -listtests :jdk_collections :jdk_concurrent > > s'marks > > > > > > On 12/11/15 11:34 AM, Martin Buchholz wrote: >> >> This is "fine", but jsr166 maintainers won't use it - we maintain our >> own list of tests to run. There's enough collection/concurrency >> overlap and too much testing ad-hoc-ery in existing jtreg tests. Eg. >> MOAT should be run for changes to any collection. If this is a test >> set you personally like, sure go ahead and commit. >> >> >> On Thu, Dec 10, 2015 at 2:39 PM, Stuart Marks >> wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145139 >>> >>> I've appended a patch below; please review. >>> >>> Thanks, >>> >>> s'marks >>> >>> # HG changeset patch >>> # User smarks >>> # Date 1449787050 28800 >>> # Thu Dec 10 14:37:30 2015 -0800 >>> # Node ID 5b630d0c118b115439672b29aff0d195132d4f96 >>> # Parent 7f644a5d554a67457f3dd535c4435643d3f65569 >>> 8145139: clean up jdk_collections and jdk_concurrent test groups >>> Reviewed-by: XXX >>> >>> diff -r 7f644a5d554a -r 5b630d0c118b test/TEST.groups >>> --- a/test/TEST.groups Wed Dec 09 15:27:21 2015 -0500 >>> +++ b/test/TEST.groups Thu Dec 10 14:37:30 2015 -0800 >>> @@ -95,13 +95,10 @@ >>> -:jdk_concurrent \ >>> -:jdk_stream >>> >>> -# java.util.concurrent (JSR-166) >>> +# java.util.concurrent >>> # Maintained by JSR-166 EG (Doug Lea et al) >>> -# Deque and PriorityQueue are also generally maintained by JSR-166 >>> jdk_concurrent = \ >>> - java/util/concurrent \ >>> - java/util/Deque \ >>> - java/util/PriorityQueue >>> + java/util/concurrent >>> >>> # Java Collections Framework >>> jdk_collections = \ >>> @@ -114,19 +111,22 @@ >>> java/util/BitSet \ >>> java/util/Collection \ >>> java/util/Collections \ >>> + java/util/Comparator \ >>> + java/util/Deque \ >>> java/util/EnumMap \ >>> java/util/EnumSet \ >>> - java/util/Comparator \ >>> - java/util/Iterator \ >>> java/util/HashMap \ >>> + java/util/HashSet \ >>> java/util/Hashtable \ >>> java/util/IdentityHashMap \ >>> - java/util/List \ >>> + java/util/Iterator \ >>> java/util/LinkedHashMap \ >>> java/util/LinkedHashSet \ >>> java/util/LinkedList \ >>> + java/util/List \ >>> java/util/Map \ >>> java/util/NavigableMap \ >>> + java/util/PriorityQueue \ >>> java/util/TimSort \ >>> java/util/TreeMap \ >>> java/util/Vector \ >>> > From mandy.chung at oracle.com Fri Dec 11 22:33:51 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Dec 2015 14:33:51 -0800 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections In-Reply-To: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> References: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> Message-ID: <02AC4D47-F6AA-42CA-91AC-0F63944D91C8@oracle.com> cc'ing awt-dev. This change looks okay. Mandy > On Dec 11, 2015, at 9:22 AM, Chris Hegarty wrote: > > More technical debt in sun.misc? > > Java SE has had support for Queues in Collections for many major releases, > sun.misc.Queue seems to predate that. I cannot find any usages outside of the > JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to > provide the necessary minimum functionality required by AppletPanel, FIFO > blocking operations. > > The changes are quite small so I just included the diffs inline. > > Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion > either way. > > $ hg rm src/java.base/share/classes/sun/misc/Queue.java > > diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java > --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java > +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java > @@ -38,6 +38,7 @@ > import java.security.*; > import java.util.*; > import java.util.Locale; > +import java.util.concurrent.LinkedBlockingQueue; > import sun.awt.AWTAccessor; > import sun.awt.AppContext; > import sun.awt.EmbeddedFrame; > @@ -45,7 +46,6 @@ > import sun.misc.ManagedLocalsThread; > import sun.misc.MessageUtils; > import sun.misc.PerformanceLogger; > -import sun.misc.Queue; > import sun.security.util.SecurityConstants; > > /** > @@ -247,8 +247,7 @@ > /** > * AppletEvent Queue > */ > - private Queue queue = null; > - > + private LinkedBlockingQueue queue = null; > > public synchronized void addAppletListener(AppletListener l) { > listeners = AppletEventMulticaster.add(listeners, l); > @@ -276,10 +275,10 @@ > synchronized(this) { > if (queue == null) { > //System.out.println("SEND0= " + id); > - queue = new Queue<>(); > + queue = new LinkedBlockingQueue<>(); > } > - Integer eventId = Integer.valueOf(id); > - queue.enqueue(eventId); > + boolean inserted = queue.offer(id); > + assert inserted; > notifyAll(); > } > if (id == APPLET_QUIT) { > @@ -303,8 +302,8 @@ > while (queue == null || queue.isEmpty()) { > wait(); > } > - Integer eventId = queue.dequeue(); > - return new AppletEvent(this, eventId.intValue(), null); > + int eventId = queue.take(); > + return new AppletEvent(this, eventId, null); > } > > boolean emptyEventQueue() { > > -Chris. From stuart.marks at oracle.com Sat Dec 12 01:15:52 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Dec 2015 17:15:52 -0800 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> <5668E96C.2020101@oracle.com> Message-ID: <566B7548.5030307@oracle.com> Hi Shinya, Thanks for updating the webrev. It looks fine. s'marks On 12/10/15 6:29 AM, ShinyaYoshida wrote: > Hi Stuart, > Thank you for your review and comment. > The doc comment is wonderful! > I like it, it must be helpful to users when they understand this method and > how the filtering collector works! > > I've updated the webrev: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.04/ > > > Could you confirm? > > Regards, > shinyafox(Shinya Yoshida) > > > 2015-12-10 11:54 GMT+09:00 Stuart Marks >: > > Hi Shinya, > > Thanks for doing this work. This looks very nice! (And thanks to Paul for > helping move it through the process.) > > I have only a minor comment, which is that it might be good to clarify in > the example why a filtering collector is necessary instead of just adding > a filter() step into the stream. (This is what prompted Henry Jen's > question, and it was my initial thought too.) > > Maybe it would be sufficient to add something like the following after the > example: > > ? A filtering collector differs from a stream's {@code filter()} > operation. In this example, suppose there are no employees whose salary is > above the threshold in some department. Using a filtering collector as > shown above would result in a mapping from that department to an empty > {@code Set}. If a stream {@code filter()} operation were done instead, > there would be no mapping for that department at all. ? > > s'marks > > > > > On 12/8/15 4:21 AM, ShinyaYoshida wrote: > > Hi Stefan, > Thank you for pointing out. > I've just updated: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.03/ > > > Regards, > shinyafox(Shinya Yoshida) > > 2015-12-08 21:08 GMT+09:00 Stefan Zobel >: > > Hi shinyafox, > > minor typo in the code example: > > > s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment > > > Regards, > Stefan > > > 2015-12-08 13:04 GMT+01:00 ShinyaYoshida >: > > Thank you so much! > I've updated in webrev.02. > > Best regard, > shinyafox(Shinya Yoshida) > > > From igor.ignatyev at oracle.com Sat Dec 12 02:10:30 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 12 Dec 2015 05:10:30 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566AB958.8010901@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> Message-ID: <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> Hi Konstantin, the fix and tests look good to me, but I think you have to wait for OK from Coleen. One minor thing ?it looks like there are no tests for other s.r.CP methods, could you please file an RFE against core-libs/j.l.reflect to cover them? Thanks, ? Igor > On Dec 11, 2015, at 2:54 PM, Konstantin Shefov wrote: > > Hello > > Please review the new version on the patch. > > New webrev: > Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 > > What has been changed: > 1. Added tests for the new added methods. > 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). > > Thanks > -Konstantin > > On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >> Coleen, >> Thanks for review >> >> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>> >>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >> I will add tests. >>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>> >>> thanks, >>> Coleen >>> >>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please, review modified webrev. >>>> >>>> I have added methods >>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>> >>>> I removed previously added method >>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>> >>>> New webrev: >>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>> Remi, >>>>> >>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>> >>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Christian Thalinger" >>>>>>> ?: "Konstantin Shefov" >>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>> >>>>>>> [CC'ing core-libs-dev] >>>>>>> >>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review an enhancement to add three new methods to >>>>>>>> sun.reflect.ConstantPool class. >>>>>>>> The following methods are suggested: >>>>>>>> >>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>> pool entry with the specified index >>>>>>>> >>>>>>>> These three methods could be used for testing API working with constant >>>>>>>> pool, e.g. JVMCI. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>> Webrev hotspot: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Sat Dec 12 11:27:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Dec 2015 12:27:22 +0100 Subject: Reference.reachabilityFence In-Reply-To: <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> Message-ID: <566C049A.90406@gmail.com> Hi Paul, Your latest code does not build with jdk9/dev as it uses @jdk.internal.vm.annotation.DontInline, but in jdk9/dev the @DontInline is still in java.lang.invoke. Is there a plan to push the move of DontInline annotation before this change as I haven's seen any RFR for the move yet? Regards, Peter On 12/11/2015 10:36 AM, Paul Sandoz wrote: > Unless any strong objections are raised I plan to push the latest path on Monday. > >> Updated: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html >> >> I think there is an opportunity to add further examples, but i would like to take a swing at that later on. >> >> >>> - I now agree with you and Doug about calling this a "fence". Can we >>> just name it "fence" rather than the wordier "reachabilityFence"? >>> Looking at a typical invocation, >>> >>> Reference.reachabilityFence(); >>> >>> seems a bit redundant while >>> >>> Reference.fence(); >>> >>> reads quite nicely. Is there, or will there ever be, any other kind >>> of reference-related fence? >>> >> I doubt there will be another kind of reference fence, but it could be used in conjunction with other memory fences (currently on VarHandles) and if static imports are used it might look rather out of place as to what fence ?fence? actually refers to. That is why i prefer the longer more descriptive name. >> >> Paul. From chris.hegarty at oracle.com Sat Dec 12 11:42:35 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 12 Dec 2015 11:42:35 +0000 Subject: Reference.reachabilityFence In-Reply-To: <566C049A.90406@gmail.com> References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> <566C049A.90406@gmail.com> Message-ID: > On 12 Dec 2015, at 11:27 a.m., Peter Levart wrote: > > Hi Paul, > > Your latest code does not build with jdk9/dev as it uses @jdk.internal.vm.annotation.DontInline, but in jdk9/dev the @DontInline is still in java.lang.invoke. > > Is there a plan to push the move of DontInline annotation before this change as I haven's seen any RFR for the move yet? https://bugs.openjdk.java.net/browse/JDK-8144223 The change is making its way through hs-comp. -Chris. > Regards, Peter > >> On 12/11/2015 10:36 AM, Paul Sandoz wrote: >> Unless any strong objections are raised I plan to push the latest path on Monday. >> >>> Updated: >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html >>> >>> I think there is an opportunity to add further examples, but i would like to take a swing at that later on. >>> >>> >>>> - I now agree with you and Doug about calling this a "fence". Can we >>>> just name it "fence" rather than the wordier "reachabilityFence"? >>>> Looking at a typical invocation, >>>> >>>> Reference.reachabilityFence(); >>>> >>>> seems a bit redundant while >>>> >>>> Reference.fence(); >>>> >>>> reads quite nicely. Is there, or will there ever be, any other kind >>>> of reference-related fence? >>> I doubt there will be another kind of reference fence, but it could be used in conjunction with other memory fences (currently on VarHandles) and if static imports are used it might look rather out of place as to what fence ?fence? actually refers to. That is why i prefer the longer more descriptive name. >>> >>> Paul. > From peter.levart at gmail.com Sat Dec 12 11:44:49 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 12 Dec 2015 12:44:49 +0100 Subject: Reference.reachabilityFence In-Reply-To: References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> <566C049A.90406@gmail.com> Message-ID: <566C08B1.6090909@gmail.com> On 12/12/2015 12:42 PM, Chris Hegarty wrote: >> On 12 Dec 2015, at 11:27 a.m., Peter Levart wrote: >> >> Hi Paul, >> >> Your latest code does not build with jdk9/dev as it uses @jdk.internal.vm.annotation.DontInline, but in jdk9/dev the @DontInline is still in java.lang.invoke. >> >> Is there a plan to push the move of DontInline annotation before this change as I haven's seen any RFR for the move yet? > https://bugs.openjdk.java.net/browse/JDK-8144223 > > The change is making its way through hs-comp. > > -Chris. Thanks Chris. Regards, Peter >> Regards, Peter >> >>> On 12/11/2015 10:36 AM, Paul Sandoz wrote: >>> Unless any strong objections are raised I plan to push the latest path on Monday. >>> >>>> Updated: >>>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html >>>> >>>> I think there is an opportunity to add further examples, but i would like to take a swing at that later on. >>>> >>>> >>>>> - I now agree with you and Doug about calling this a "fence". Can we >>>>> just name it "fence" rather than the wordier "reachabilityFence"? >>>>> Looking at a typical invocation, >>>>> >>>>> Reference.reachabilityFence(); >>>>> >>>>> seems a bit redundant while >>>>> >>>>> Reference.fence(); >>>>> >>>>> reads quite nicely. Is there, or will there ever be, any other kind >>>>> of reference-related fence? >>>> I doubt there will be another kind of reference fence, but it could be used in conjunction with other memory fences (currently on VarHandles) and if static imports are used it might look rather out of place as to what fence ?fence? actually refers to. That is why i prefer the longer more descriptive name. >>>> >>>> Paul. From yasuenag at gmail.com Sat Dec 12 12:23:03 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 12 Dec 2015 21:23:03 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: References: <565FB732.4090401@oracle.com> Message-ID: <566C11A7.1070309@gmail.com> Hi Sherman, Our proposal is affected by JDK-8142508. We have to change ZipFile.java and and ZipFile.c . Thus we will create a new webrev for current (after 8142508) jdk9/dev repos. Do you have any comments about current webrev? http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ If you have comments, we will fix them in new webrev. Thanks, Yasumasa On 2015/12/03 16:51, KUBOTA Yuji wrote: > Hi Sherman, > > Thanks for your quick response :) > > I aimed to implement the "traditional" at this proposal by the below reasons. > > * We want to prepare API for encrypted zip files at first. > * Many people use the "traditional" in problem-free scope like a > temporary file. > * We do not know which implementation of the "stronger" is best for openjdk. > * PKWare claims that they have patents about the "stronger" on Zip[1]. > * OTOH, WinZip have the alternative implementation of the "stronger" [2][3]. > * Instead, we prepared the extensibility by ZipCryption interface to > implement other encrypt engine, such as the AES based. > > Thus, I think this PoC should support the "traditional" only. > In the future, anyone who want to implement the "stronger" can easily > add their code by virtue of this proposal. > > [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT > (1.4 Permitted Use & 7.0 Strong Encryption Specification) > [2] https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy > [3] http://www.winzip.com/aes_info.htm > > Thanks, > Yuji > > 2015-12-03 12:29 GMT+09:00 Xueming Shen : >> >> Hi Yuji, >> >> I will take a look at your PoC. Might need some time and even bring in the >> security guy >> to evaluate the proposal. It seems like you are only interested in the >> "traditional PKWare >> decryption", which is, based on the wiki, "known to be seriously flawed, and >> in particular >> is vulnerable to known-plaintext attacks":-) Any request to support >> "stronger" encryption >> mechanism, such as the AES based? >> >> Regards, >> Sherman >> >> >> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>> >>> Hi all, >>> >>> We need reviewer(s) for this PoC. >>> Could you please review this proposal and PoC ? >>> >>> Thanks, >>> Yuji >>> >>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>> >>>> Hi all, >>>> >>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>> a response of subscription confirmation of core-libs-dev. >>>> >>>> Our customers have to handle password-protected zip files. However, >>>> Java SE does not provide the APIs to handle it yet, so we must use >>>> third party library so far. >>>> >>>> Recently, we found JDK-4347142: "Need method to set Password >>>> protection to Zip entries", and we tried to implement it. >>>> >>>> The current zlib in JDK is completely unaffected by this proposal. The >>>> traditional zip encryption encrypts a data after it is has been >>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>> implementation. >>>> >>>> We've created PoC and uploaded it as webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>> >>>> Test code is as below. This code will let you know how this PoC >>>> works. >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>> >>>> In NTT, a Japanese telecommunications company. We are providing many >>>> enterprise systems to customers. Some of them, we need to implement to >>>> handle password-protected zip file. I guess that this proposal is >>>> desired for many developers and users. >>>> >>>> I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). >>>> We want to implement it if this proposal accepted. >>>> >>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>> (6.0 Traditional PKWARE Encryption) >>>> >>>> Thanks, >>>> Yuji >> >> From nadeesh.tv at oracle.com Sat Dec 12 15:14:01 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Sat, 12 Dec 2015 20:44:01 +0530 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: <566AF19E.1080500@Oracle.com> References: <566AAE61.6060407@oracle.com> <566AB91E.7020903@oracle.com> <566AF19E.1080500@Oracle.com> Message-ID: <566C39B9.9010502@oracle.com> HI all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8032510/webrev.04/ Changes: chnaged the data provider as suggested Regards, Nadeesh On 12/11/2015 9:24 PM, Roger Riggs wrote: > Hi Nadeesh, > > The API looks fine. > > I think the tests would be more readable if the Durations being tested > were created in the data provider. > Without a comment, it just looks like a lot of numbers. > The test methods arguments would then be (Duration dividend, Duration > divisor, long expected). > > + @DataProvider(name="dividedByDur_provider") > + Object[][] provider_dividedByDur() { > + return new Object[][] { > + {new Duration.ofSeconds(0, 0), new Duration.ofSeconds(1, 0), 0}, > > etc. > > Thanks, Roger > > On 12/11/2015 7:14 AM, Stephen Colebourne wrote: >> Fine by me. >> >> Stephen >> >> On 11 December 2015 at 11:53, nadeesh tv wrote: >>> Hi all, >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ >>> Regards, >>> Nadeesh TV >>> >>> >>> On 12/11/2015 4:45 PM, Stephen Colebourne wrote: >>>> Missing blank line after the new method. >>>> Typo: "diviosr" >>>> Replace: >>>> Objects.requireNonNull(divisor, "divisor is null"); >>>> with >>>> Objects.requireNonNull(divisor, "divisor"); >>>> to match existing JSR-310 code. >>>> >>>> Test case looks fine. >>>> >>>> thanks >>>> Stephen >>>> >>>> >>>> On 11 December 2015 at 11:07, nadeesh tv >>>> wrote: >>>>> Hi all, >>>>> Please review a fix for >>>>> >>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 >>>>> >>>>> Enhancement - Add java.time.Duration.dividedBy(Duration) >>>>> >>>>> webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > -- Thanks and Regards, Nadeesh TV From Roger.Riggs at Oracle.com Sat Dec 12 16:11:42 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sat, 12 Dec 2015 11:11:42 -0500 Subject: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration) In-Reply-To: <566C39B9.9010502@oracle.com> References: <566AAE61.6060407@oracle.com> <566AB91E.7020903@oracle.com> <566AF19E.1080500@Oracle.com> <566C39B9.9010502@oracle.com> Message-ID: <566C473E.5030804@Oracle.com> Hi Nadeesh, Looks good. I'll integrate next week. Thanks, Roger On 12/12/2015 10:14 AM, nadeesh tv wrote: > HI all, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8032510/webrev.04/ > > Changes: chnaged the data provider as suggested > > Regards, > Nadeesh > On 12/11/2015 9:24 PM, Roger Riggs wrote: >> Hi Nadeesh, >> >> The API looks fine. >> >> I think the tests would be more readable if the Durations being >> tested were created in the data provider. >> Without a comment, it just looks like a lot of numbers. >> The test methods arguments would then be (Duration dividend, >> Duration divisor, long expected). >> >> + @DataProvider(name="dividedByDur_provider") >> + Object[][] provider_dividedByDur() { >> + return new Object[][] { >> + {new Duration.ofSeconds(0, 0), new Duration.ofSeconds(1, 0), 0}, >> >> etc. >> >> Thanks, Roger >> >> On 12/11/2015 7:14 AM, Stephen Colebourne wrote: >>> Fine by me. >>> >>> Stephen >>> >>> On 11 December 2015 at 11:53, nadeesh tv wrote: >>>> Hi all, >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ >>>> Regards, >>>> Nadeesh TV >>>> >>>> >>>> On 12/11/2015 4:45 PM, Stephen Colebourne wrote: >>>>> Missing blank line after the new method. >>>>> Typo: "diviosr" >>>>> Replace: >>>>> Objects.requireNonNull(divisor, "divisor is null"); >>>>> with >>>>> Objects.requireNonNull(divisor, "divisor"); >>>>> to match existing JSR-310 code. >>>>> >>>>> Test case looks fine. >>>>> >>>>> thanks >>>>> Stephen >>>>> >>>>> >>>>> On 11 December 2015 at 11:07, nadeesh tv >>>>> wrote: >>>>>> Hi all, >>>>>> Please review a fix for >>>>>> >>>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 >>>>>> >>>>>> Enhancement - Add java.time.Duration.dividedBy(Duration) >>>>>> >>>>>> webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/ >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> > From xueming.shen at oracle.com Sat Dec 12 18:43:49 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 12 Dec 2015 10:43:49 -0800 Subject: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2] In-Reply-To: <5643A368.7010207@oracle.com> References: <5643A368.7010207@oracle.com> Message-ID: <566C6AE5.3040207@oracle.com> Hi, The changeset for JDK-8142508 had been backout because it triggers jtreg fails in -avm mode with testng tests. Here is the updated version that fixes the problem. I'm using a different issue to trace this update change. issue: https://bugs.openjdk.java.net/browse/JDK-8145260 webrev: http://cr.openjdk.java.net/~sherman/8145260/webrev/ diff: http://cr.openjdk.java.net/~sherman/8145260/diff (diff to the latest 8142508 version) The root cause/direct trigger that causes the jtreg failure is the overlook in the new implementation. The flag "locsig" was implemented as this.locsig = (LOCSIG(buf) != LOCSIG); while it really should be this.locsig = (LOCSIG(buf) == LOCSIG); This is the flag that sun.misc.URLClassPath uses to check if a jar file stars with the correct LOC (throws away if not) in certain circumstance (security manager + !disable_jar_checking). This has been fixed in the new webrev, and I also renamed the field to be more straightforward (locsig -> startsWithLoc) Other than that, there are two small updates (1) wrap the zip file initialization code with a try{} block and close the raw file if any exception (2) reorder of "len <=0" check in ZipFileInputStream.read() All tests seem to pass now. Thanks, Sherman On 11/11/15 12:22 PM, Xueming Shen wrote: > Hi > > Please help review the changes for JDK-8142508 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 > webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev > > Mainly to address the issues in current j.u.z.ZipFile implementation > as listed > below > > (1) The ZIP file format support code is in native C (shared with the > VM via > ZipFile.c -> zip_util.c). Any entry lookup, creation operation > requires multiple > round-trips of expensive jni calls. > > (2) The native C implementation which uses mmap to map in the central > directory > table appears to be a big risk of vm crash when the underlying > jar file gets > overwritten with new contents while it is still being used by > other ZipFile. The > crash reports keep coming in even after we have introduced in > system flag > to disable it (sun.zip.disableMemoryMapping). > > (3) The use of "filename + lastModified()" cache (zip_util.c) appears > to be broken > if the timestamp is in low resolution/precision > (File.getModified() for example, > might only have "second" ersolution on solaris/linux), and/or the > file is being > overwritten. > > The clean solution appears to bring the ZIP format support code > completely from > native to Java to remove the jni invocation cost and the mmap risk. > Also to use > the fileKey and lastModified from > java.nio.file.attribute.BasicFileAttributes to have > better/correct cache matching. > > Benchmark: > > This simple jmh measurement suggests a big boost of the performance of > ZipFile.getEntry()/entries()/getStream() which are basically entry > related > accesses (the "open only" has some regression, which is expected as we > switched from the mmap to simply read the cen table in into a byte[]) > > http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java > > # JDK9 base > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op > MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op > MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op > MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op > MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op > MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op > -------------------------------------------------------------------------------------- > > # JDK9 ZipFile without jni invocation > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op > MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op > MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op > MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op > MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op > MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op > --------------------------------------------------------------------------------------- > > > Test: > http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html > > > Verified the new ZipFile runs as expected when the underlying jar/zip > file get > deleted/overwritten when the zip still be used. The "old" ZipFile > fails to continue > to work but no crash, and the "new" one works correctly on updated zip > file > without problem (The test runs a little long, have not decided if it > should be > checked in as unit test). > > -Sherman > From Sergey.Bylokhov at oracle.com Sun Dec 13 11:16:25 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 13 Dec 2015 14:16:25 +0300 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections In-Reply-To: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> References: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> Message-ID: <566D5389.20709@oracle.com> Hi, Chris. What is the reason to use assertion? If the problem is not theoretical, then probably OOM(or something like that) will be better? On 11/12/15 20:22, Chris Hegarty wrote: > More technical debt in sun.misc? > > Java SE has had support for Queues in Collections for many major releases, > sun.misc.Queue seems to predate that. I cannot find any usages outside of the > JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to > provide the necessary minimum functionality required by AppletPanel, FIFO > blocking operations. > > The changes are quite small so I just included the diffs inline. > > Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion > either way. > > $ hg rm src/java.base/share/classes/sun/misc/Queue.java > > diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java > --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java > +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java > @@ -38,6 +38,7 @@ > import java.security.*; > import java.util.*; > import java.util.Locale; > +import java.util.concurrent.LinkedBlockingQueue; > import sun.awt.AWTAccessor; > import sun.awt.AppContext; > import sun.awt.EmbeddedFrame; > @@ -45,7 +46,6 @@ > import sun.misc.ManagedLocalsThread; > import sun.misc.MessageUtils; > import sun.misc.PerformanceLogger; > -import sun.misc.Queue; > import sun.security.util.SecurityConstants; > > /** > @@ -247,8 +247,7 @@ > /** > * AppletEvent Queue > */ > - private Queue queue = null; > - > + private LinkedBlockingQueue queue = null; > > public synchronized void addAppletListener(AppletListener l) { > listeners = AppletEventMulticaster.add(listeners, l); > @@ -276,10 +275,10 @@ > synchronized(this) { > if (queue == null) { > //System.out.println("SEND0= " + id); > - queue = new Queue<>(); > + queue = new LinkedBlockingQueue<>(); > } > - Integer eventId = Integer.valueOf(id); > - queue.enqueue(eventId); > + boolean inserted = queue.offer(id); > + assert inserted; > notifyAll(); > } > if (id == APPLET_QUIT) { > @@ -303,8 +302,8 @@ > while (queue == null || queue.isEmpty()) { > wait(); > } > - Integer eventId = queue.dequeue(); > - return new AppletEvent(this, eventId.intValue(), null); > + int eventId = queue.take(); > + return new AppletEvent(this, eventId, null); > } > > boolean emptyEventQueue() { > > -Chris. > -- Best regards, Sergey. From joel.borggren.franck at gmail.com Sun Dec 13 20:26:33 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Sun, 13 Dec 2015 20:26:33 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: <5669EC2A.1030308@oracle.com> References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> <5669EC2A.1030308@oracle.com> Message-ID: Hi Joe, Thanks for the comments, On Thu, 10 Dec 2015 at 22:18 joe darcy wrote: > Hi Joel, > > On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: > > Question, is it better to remove the throws clauses for the cases that > return null? > > > I think so; they aren't applicable in those case and it is fine to remove > exceptions in subtypes of course. > > Done. > Please also add @Override annotations to the methods in the subtypes as a > check that a new method is not accidentally being declared. > > Doh! Fixed. > > New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ > Diff of patch 01 and patch 02 (a diff-diff): > http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch > > > > Please add an @implSpec note in AnnotatedType saying that "this > implementation returns null", or words to that effect. > > Done. > Shouldn't some of the implementation overrides in > AnnotatedTypeFactory.java which throw null now be removed? Ah, I see the > BaseImpl type is in the way. Is there an easy way to refactor that? > > I think it deserves a separate commit. I have another bugfix lined up, then I plan to refactor refactor the code a bit and clean up and improve testing. > (I'll take care of the ccc changes once the new spec is finalized.) > > Thanks! New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.03/ Delta vs 01: http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v3.patch cheers /Joel From chris.hegarty at oracle.com Sun Dec 13 21:38:57 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 13 Dec 2015 21:38:57 +0000 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections In-Reply-To: <566D5389.20709@oracle.com> References: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> <566D5389.20709@oracle.com> Message-ID: <8FAF464A-C9A8-4E65-AE14-2F08593B6A5D@oracle.com> Thanks for looking at this Sergey. > On 13 Dec 2015, at 11:16, Sergey Bylokhov wrote: > > Hi, Chris. > What is the reason to use assertion? If the problem is not theoretical, Hmm? The queue is ?unbounded?, but actually has a capacity of Integer.MAX_VALUE. I suspect that this will never be reached, but I accept your comment. Maybe add(E) is more appropriate? add() either succeeds, or fails with IllegalStateException. > then probably OOM(or something like that) will be better? I don?t think OOM is quite right. Maybe ISE, as above is better? -Chris. > On 11/12/15 20:22, Chris Hegarty wrote: >> More technical debt in sun.misc? >> >> Java SE has had support for Queues in Collections for many major releases, >> sun.misc.Queue seems to predate that. I cannot find any usages outside of the >> JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to >> provide the necessary minimum functionality required by AppletPanel, FIFO >> blocking operations. >> >> The changes are quite small so I just included the diffs inline. >> >> Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion >> either way. >> >> $ hg rm src/java.base/share/classes/sun/misc/Queue.java >> >> diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >> --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java >> +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >> @@ -38,6 +38,7 @@ >> import java.security.*; >> import java.util.*; >> import java.util.Locale; >> +import java.util.concurrent.LinkedBlockingQueue; >> import sun.awt.AWTAccessor; >> import sun.awt.AppContext; >> import sun.awt.EmbeddedFrame; >> @@ -45,7 +46,6 @@ >> import sun.misc.ManagedLocalsThread; >> import sun.misc.MessageUtils; >> import sun.misc.PerformanceLogger; >> -import sun.misc.Queue; >> import sun.security.util.SecurityConstants; >> >> /** >> @@ -247,8 +247,7 @@ >> /** >> * AppletEvent Queue >> */ >> - private Queue queue = null; >> - >> + private LinkedBlockingQueue queue = null; >> >> public synchronized void addAppletListener(AppletListener l) { >> listeners = AppletEventMulticaster.add(listeners, l); >> @@ -276,10 +275,10 @@ >> synchronized(this) { >> if (queue == null) { >> //System.out.println("SEND0= " + id); >> - queue = new Queue<>(); >> + queue = new LinkedBlockingQueue<>(); >> } >> - Integer eventId = Integer.valueOf(id); >> - queue.enqueue(eventId); >> + boolean inserted = queue.offer(id); >> + assert inserted; >> notifyAll(); >> } >> if (id == APPLET_QUIT) { >> @@ -303,8 +302,8 @@ >> while (queue == null || queue.isEmpty()) { >> wait(); >> } >> - Integer eventId = queue.dequeue(); >> - return new AppletEvent(this, eventId.intValue(), null); >> + int eventId = queue.take(); >> + return new AppletEvent(this, eventId, null); >> } >> >> boolean emptyEventQueue() { >> >> -Chris. >> > > > -- > Best regards, Sergey. From ramanand.patil at oracle.com Mon Dec 14 08:14:13 2015 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 14 Dec 2015 00:14:13 -0800 (PST) Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <566B2CFE.3030802@Oracle.com> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> Message-ID: <96b1ddd9-e543-42e5-8597-9b466225f854@default> Hi Roger and all, Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066982 Roger, please see my comments about new tests: - All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this. - I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data. - I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()). But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases. I have created the dataProvider kepping in mind the below cases for 2 DST zones. 1. Time before overlap 2. Time during Overlap 3. Time after overlap 4. Valid Offsets for each of these times 5. Zero Offset for each time 6. Few Positive and negative invalid offsets for each time Regards, Ramanand. -----Original Message----- From: Roger Riggs Sent: Saturday, December 12, 2015 1:37 AM To: HYPERLINK "mailto:core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net Cc: HYPERLINK "mailto:i18n-dev at openjdk.java.net" i18n-dev at openjdk.java.net Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition Hi, Stephen, can you confirm that the added text and test in DateTimeFormatter is not a specification change? Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed. test/java/time/tck/java/time/TCKZonedDateTime.java Ramanand, some comments on the new test: - The 'private' qualifier on the tests and data providers is not used in the current tests and is not consistently present in the new one. Since it has little/no function, the tests would be a bit cleaner without it. - Typically, test that have data dependencies (such as the timezone data) cannot be used for compatibility to the specification, but the data is stable and it seems unavoidable in this case. - Are all of the data cases necessary to validate the specification? Redundant cases extend the testing time without adding more confidence to the quality. Thanks, Roger On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > I believe this is suitable for committing, thanks, other reviews welcome! > Stephen > > > > On 10 December 2015 at 15:36, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote: >> Hi all, >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >> >> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. >> >> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >> >> >> Regards, >> Ramanand. >> >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Wednesday, December 09, 2015 4:46 PM >> To: core-libs-dev >> Cc: i18n-dev >> Subject: Re: Review request for JDK-8066982: >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall >> transition >> >> The logic looks fine. >> >> In the main code, this part >> .getLong(INSTANT_SECONDS); >> can be replaced with >> .toEpochSecond(); >> which will be slightly faster. >> >> In the test case, this part >> .plus(15, ChronoUnit.MINUTES); >> can be replaced with >> .plusMinutes(15) >> >> And >> .with(ChronoField.OFFSET_SECONDS, >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >> can be replaced with >> .with(ZoneOffset.of(offsetSamples[j])) >> >> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. >> >> thanks for fixing this >> Stephen >> >> >> >> On 9 December 2015 at 07:44, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote: >>> HI all, >>> >>> >>> >>> Please review a fix for Bug - HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>> >>> >>> >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). >>> >>> >>> >>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>> >>> >>> >>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Ramanand. From paul.sandoz at oracle.com Mon Dec 14 08:43:23 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Dec 2015 09:43:23 +0100 Subject: RFR 8144675: Add a filtering collector In-Reply-To: References: <50F6A752-602C-4FB4-9BCA-002010CB72E1@oracle.com> <56620E47.1060907@oracle.com> <44760F1D-A3AC-49FD-B658-8DC86FB4863D@oracle.com> <8CDFF884-57F6-4318-9AB6-0AD7E7C51571@oracle.com> <0EDFDB22-EC67-4CCB-B7D5-F6A927CA1D33@oracle.com> <2155BA81-5066-44E2-BEF5-E85DD6A87504@oracle.com> <5668E96C.2020101@oracle.com> Message-ID: <53B19A2B-62EA-4C2A-BA52-7D76EF55501A@oracle.com> > On 10 Dec 2015, at 15:29, ShinyaYoshida wrote: > > Hi Stuart, > Thank you for your review and comment. > The doc comment is wonderful! > I like it, it must be helpful to users when they understand this method and > how the filtering collector works! > > I've updated the webrev: > http://cr.openjdk.java.net/~shinyafox/8144675/webrev.04/ > Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bf153b12450b I took the liberty of tweaking the parameters and return tags to better align with the notion of predicate: + * @param downstream a collector which will accept values that match the + * predicate + * @return a collector which applies the predicate to the input elements + * and provides matching elements to the downstream collector Thanks, Paul. From Alan.Bateman at oracle.com Mon Dec 14 08:55:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Dec 2015 08:55:18 +0000 Subject: RFR 8143404: Remove apple script engine code in jdk repository In-Reply-To: <9F2E67E7-55D2-4314-8894-AB931885BA32@gmail.com> References: <9F2E67E7-55D2-4314-8894-AB931885BA32@gmail.com> Message-ID: <566E83F6.7010504@oracle.com> On 07/12/2015 19:38, Mike Dever Google wrote: > Is there a work around? > That really limits, actually kills a lot of functionality. The JDK 7 and JDK 8 builds don't declare AppleScript in the services configuration file (META-INF/services/javax.script.ScriptEngineFactory). This means that if you've never had Apple's JDK bits on your system then jrunscript -q will not locate the AppleScript implementation. On the other hand, if your system has /System/Library/Java/Extensions/AppleScriptEngine.jar then jrunscript -q will locate it and print out something like "Language AppleScript 2.4 implementation ...". The fact that it actually loads the version in rt.jar is a bit odd of course. In any case, JDK 9 drops the legacy extension mechanism (JEP 220 has the more details, the deprecation of this mechanism was also announced in the maintenance release of JSR 337). This means that service lookup will not look in the system directories like /System/Library/Java/Extensions and so the services configuration file in AppleScriptEngine.jar will not be found. So irrespective of Sundar's proposal to just remove the code, you will find that jrunscript in JDK 9 build has not located the AppleScript implementation for a long time (more than a year). As regards workaround then all I can suggest is to add /System/Library/Java/Extensions/AppleScriptEngine.jar to your class path and then it will use the AppleScript implementation from Apple's JDK 6. As regards maintaining this code then there probably is an opportunity for someone to run it as as a standalone project/library. -Alan. From konstantin.shefov at oracle.com Mon Dec 14 08:58:20 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 14 Dec 2015 11:58:20 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <936BAB55-5004-440C-A980-E7F9D2DBBF13@oracle.com> Message-ID: <566E84AC.8010204@oracle.com> Hi Igor I have filed an RFE you asked about https://bugs.openjdk.java.net/browse/JDK-8145297. -Konstantin On 12/12/2015 05:10 AM, Igor Ignatyev wrote: > Hi Konstantin, > > the fix and tests look good to me, but I think you have to wait for OK from Coleen. > > One minor thing ?it looks like there are no tests for other s.r.CP methods, could you please file an RFE against core-libs/j.l.reflect to cover them? > > Thanks, > ? Igor > >> On Dec 11, 2015, at 2:54 PM, Konstantin Shefov wrote: >> >> Hello >> >> Please review the new version on the patch. >> >> New webrev: >> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> >> What has been changed: >> 1. Added tests for the new added methods. >> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >> >> Thanks >> -Konstantin >> >> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>> Coleen, >>> Thanks for review >>> >>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>> I will add tests. >>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please, review modified webrev. >>>>> >>>>> I have added methods >>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>> >>>>> I removed previously added method >>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>> Remi, >>>>>> >>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>> >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>> Hi Konstantin, >>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>> >>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>> >>>>>>> cheers, >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>>> De: "Christian Thalinger" >>>>>>>> ?: "Konstantin Shefov" >>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>> >>>>>>>> [CC'ing core-libs-dev] >>>>>>>> >>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>> The following methods are suggested: >>>>>>>>> >>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>> pool entry with the specified index >>>>>>>>> >>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>> pool, e.g. JVMCI. >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>> Webrev hotspot: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin From sean.coffey at oracle.com Mon Dec 14 09:13:05 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 14 Dec 2015 09:13:05 +0000 Subject: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2] In-Reply-To: <566C6AE5.3040207@oracle.com> References: <5643A368.7010207@oracle.com> <566C6AE5.3040207@oracle.com> Message-ID: <566E8821.5010504@oracle.com> Sherman, Changes look fine. One suggestion in ZipFile around line 956. Would you be better off managing the RandomAccessFile via try-with-resources. That would clean up your exception handling. Regards, Sean. On 12/12/2015 18:43, Xueming Shen wrote: > Hi, > > The changeset for JDK-8142508 had been backout because it triggers > jtreg fails in -avm mode > with testng tests. Here is the updated version that fixes the problem. > I'm using a different issue > to trace this update change. > > issue: https://bugs.openjdk.java.net/browse/JDK-8145260 > webrev: http://cr.openjdk.java.net/~sherman/8145260/webrev/ > diff: http://cr.openjdk.java.net/~sherman/8145260/diff (diff to the > latest 8142508 version) > > The root cause/direct trigger that causes the jtreg failure is the > overlook in the new implementation. > The flag "locsig" was implemented as > > this.locsig = (LOCSIG(buf) != LOCSIG); > > while it really should be > > this.locsig = (LOCSIG(buf) == LOCSIG); > > This is the flag that sun.misc.URLClassPath uses to check if a jar > file stars with the correct > LOC (throws away if not) in certain circumstance (security manager + > !disable_jar_checking). > > This has been fixed in the new webrev, and I also renamed the field to > be more straightforward > (locsig -> startsWithLoc) > > Other than that, there are two small updates > > (1) wrap the zip file initialization code with a try{} block and close > the raw file if any exception > (2) reorder of "len <=0" check in ZipFileInputStream.read() > > All tests seem to pass now. > > Thanks, > Sherman > > On 11/11/15 12:22 PM, Xueming Shen wrote: >> Hi >> >> Please help review the changes for JDK-8142508 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 >> webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev >> >> Mainly to address the issues in current j.u.z.ZipFile implementation >> as listed >> below >> >> (1) The ZIP file format support code is in native C (shared with the >> VM via >> ZipFile.c -> zip_util.c). Any entry lookup, creation operation >> requires multiple >> round-trips of expensive jni calls. >> >> (2) The native C implementation which uses mmap to map in the central >> directory >> table appears to be a big risk of vm crash when the underlying >> jar file gets >> overwritten with new contents while it is still being used by >> other ZipFile. The >> crash reports keep coming in even after we have introduced in >> system flag >> to disable it (sun.zip.disableMemoryMapping). >> >> (3) The use of "filename + lastModified()" cache (zip_util.c) appears >> to be broken >> if the timestamp is in low resolution/precision >> (File.getModified() for example, >> might only have "second" ersolution on solaris/linux), and/or >> the file is being >> overwritten. >> >> The clean solution appears to bring the ZIP format support code >> completely from >> native to Java to remove the jni invocation cost and the mmap risk. >> Also to use >> the fileKey and lastModified from >> java.nio.file.attribute.BasicFileAttributes to have >> better/correct cache matching. >> >> Benchmark: >> >> This simple jmh measurement suggests a big boost of the performance of >> ZipFile.getEntry()/entries()/getStream() which are basically entry >> related >> accesses (the "open only" has some regression, which is expected as we >> switched from the mmap to simply read the cen table in into a byte[]) >> >> http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java >> >> # JDK9 base >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op >> MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op >> MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op >> MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op >> MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op >> MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op >> -------------------------------------------------------------------------------------- >> >> # JDK9 ZipFile without jni invocation >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op >> MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op >> MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op >> MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op >> MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op >> MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op >> --------------------------------------------------------------------------------------- >> >> >> Test: >> http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html >> >> >> Verified the new ZipFile runs as expected when the underlying jar/zip >> file get >> deleted/overwritten when the zip still be used. The "old" ZipFile >> fails to continue >> to work but no crash, and the "new" one works correctly on updated >> zip file >> without problem (The test runs a little long, have not decided if it >> should be >> checked in as unit test). >> >> -Sherman >> > From scolebourne at joda.org Mon Dec 14 09:20:55 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 14 Dec 2015 09:20:55 +0000 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <566B2CFE.3030802@Oracle.com> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> Message-ID: The added text and tests represent a spec clarification. The behaviour in this area was not precisely defined before. The bug itself was clear due to the expected round-trip behaviour of toString() and parse(). While this is a slightly more tricky backport than some, it is really quite broken in one of the most important areas for a date-time library, the DST overlap. IMO, the two extra spec

  • elements probably should not be backported. However the rest should be. I'm not sure whether the "TCK" test classes are still used as the TCK, so it is possible that the backport should have tests located in a different place. Hope that helps Stephen On 11 December 2015 at 20:07, Roger Riggs wrote: > Hi, > > Stephen, can you confirm that the added text and test in DateTimeFormatter > is not a specification change? > Our processes have a bit more to do if it is a spec change and it would > limit the backport to JDK 8. > > This bug fix will cause an existing TCK/JCK test to fail but that is > considered also a bug and is fixed. > test/java/time/tck/java/time/TCKZonedDateTime.java > > Ramanand, some comments on the new test: > - The 'private' qualifier on the tests and data providers is not used in > the current tests and > is not consistently present in the new one. > Since it has little/no function, the tests would be a bit cleaner > without it. > > - Typically, test that have data dependencies (such as the timezone data) > cannot be used for > compatibility to the specification, but the data is stable and it seems > unavoidable in this case. > > - Are all of the data cases necessary to validate the specification? > Redundant cases extend the testing time without adding more confidence to > the quality. > > Thanks, Roger > > > > On 12/10/2015 11:00 AM, Stephen Colebourne wrote: >> >> I believe this is suitable for committing, thanks, other reviews welcome! >> Stephen >> >> >> >> On 10 December 2015 at 15:36, Ramanand Patil >> wrote: >>> >>> Hi all, >>> >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >>> >>> I have modified the fix and test cases as per inputs given by Stephen. >>> Also, I have added the javadocs changes in this patch which were proposed in >>> the bug. >>> >>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >>> >>> >>> Regards, >>> Ramanand. >>> >>> -----Original Message----- >>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>> Sent: Wednesday, December 09, 2015 4:46 PM >>> To: core-libs-dev >>> Cc: i18n-dev >>> Subject: Re: Review request for JDK-8066982: >>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition >>> >>> The logic looks fine. >>> >>> In the main code, this part >>> .getLong(INSTANT_SECONDS); >>> can be replaced with >>> .toEpochSecond(); >>> which will be slightly faster. >>> >>> In the test case, this part >>> .plus(15, ChronoUnit.MINUTES); >>> can be replaced with >>> .plusMinutes(15) >>> >>> And >>> .with(ChronoField.OFFSET_SECONDS, >>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >>> can be replaced with >>> .with(ZoneOffset.of(offsetSamples[j])) >>> >>> In addition to the looping tests, I'd like to see the examples from the >>> bug report as test cases. Those tests would be simple to follow and explain, >>> whereas the looping tests are a little hard to follow. >>> >>> thanks for fixing this >>> Stephen >>> >>> >>> >>> On 9 December 2015 at 07:44, Ramanand Patil >>> wrote: >>>> >>>> HI all, >>>> >>>> >>>> >>>> Please review a fix for Bug - HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>>> >>>> >>>> >>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone >>>> offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime >>>> (different offset). This error starts exactly at the transition time >>>> (included) and ends one hour later (excluded). >>>> >>>> >>>> >>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>>> >>>> >>>> >>>> One existing test case in TCKZonedDateTime.java is also modified, >>>> because - when offset is invalid the local time is changed to make the >>>> result valid. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ramanand. > > From scolebourne at joda.org Mon Dec 14 09:21:48 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 14 Dec 2015 09:21:48 +0000 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <96b1ddd9-e543-42e5-8597-9b466225f854@default> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> <96b1ddd9-e543-42e5-8597-9b466225f854@default> Message-ID: I remain happy with the webrev Stephen On 14 December 2015 at 08:14, Ramanand Patil wrote: > Hi Roger and all, > > Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066982 > > > Roger, please see my comments about new tests: > > - All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this. > > - I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data. > > - I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()). > But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases. > I have created the dataProvider kepping in mind the below cases for 2 DST zones. > 1. Time before overlap > 2. Time during Overlap > 3. Time after overlap > 4. Valid Offsets for each of these times > 5. Zero Offset for each time > 6. Few Positive and negative invalid offsets for each time > > > Regards, > Ramanand. > > > -----Original Message----- > From: Roger Riggs > Sent: Saturday, December 12, 2015 1:37 AM > To: HYPERLINK "mailto:core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net > Cc: HYPERLINK "mailto:i18n-dev at openjdk.java.net" i18n-dev at openjdk.java.net > Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition > > Hi, > > Stephen, can you confirm that the added text and test in DateTimeFormatter is not a specification change? > Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. > > This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed. > test/java/time/tck/java/time/TCKZonedDateTime.java > > Ramanand, some comments on the new test: > - The 'private' qualifier on the tests and data providers is not used in the current tests and > is not consistently present in the new one. > Since it has little/no function, the tests would be a bit cleaner without it. > > - Typically, test that have data dependencies (such as the timezone > data) cannot be used for > compatibility to the specification, but the data is stable and it seems unavoidable in this case. > > - Are all of the data cases necessary to validate the specification? > Redundant cases extend the testing time without adding more confidence to the quality. > > Thanks, Roger > > > On 12/10/2015 11:00 AM, Stephen Colebourne wrote: >> I believe this is suitable for committing, thanks, other reviews welcome! >> Stephen >> >> >> >> On 10 December 2015 at 15:36, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote: >>> Hi all, >>> >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >>> >>> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. >>> >>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >>> >>> >>> Regards, >>> Ramanand. >>> >>> -----Original Message----- >>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>> Sent: Wednesday, December 09, 2015 4:46 PM >>> To: core-libs-dev >>> Cc: i18n-dev >>> Subject: Re: Review request for JDK-8066982: >>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall >>> transition >>> >>> The logic looks fine. >>> >>> In the main code, this part >>> .getLong(INSTANT_SECONDS); >>> can be replaced with >>> .toEpochSecond(); >>> which will be slightly faster. >>> >>> In the test case, this part >>> .plus(15, ChronoUnit.MINUTES); >>> can be replaced with >>> .plusMinutes(15) >>> >>> And >>> .with(ChronoField.OFFSET_SECONDS, >>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >>> can be replaced with >>> .with(ZoneOffset.of(offsetSamples[j])) >>> >>> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. >>> >>> thanks for fixing this >>> Stephen >>> >>> >>> >>> On 9 December 2015 at 07:44, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote: >>>> HI all, >>>> >>>> >>>> >>>> Please review a fix for Bug - HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>>> >>>> >>>> >>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). >>>> >>>> >>>> >>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>>> >>>> >>>> >>>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ramanand. > From paul.sandoz at oracle.com Mon Dec 14 09:45:30 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Dec 2015 10:45:30 +0100 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections In-Reply-To: <8FAF464A-C9A8-4E65-AE14-2F08593B6A5D@oracle.com> References: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> <566D5389.20709@oracle.com> <8FAF464A-C9A8-4E65-AE14-2F08593B6A5D@oracle.com> Message-ID: <66E32A01-D61A-4CB8-8BC4-5C3D07A3BFCA@oracle.com> > On 13 Dec 2015, at 22:38, Chris Hegarty wrote: > > Thanks for looking at this Sergey. > >> On 13 Dec 2015, at 11:16, Sergey Bylokhov wrote: >> >> Hi, Chris. >> What is the reason to use assertion? If the problem is not theoretical, > That was tricky to spot :-) nearly missed it. > Hmm? The queue is ?unbounded?, but actually has a capacity of > Integer.MAX_VALUE. I suspect that this will never be reached, but > I accept your comment. Maybe add(E) is more appropriate? add() > either succeeds, or fails with IllegalStateException. Since the queue is not "capacity-restricted" i think add(E) is the more appropriate choice, as is the ISE in this context. It?s hard to imagine the applet event queue reaching the MAX_VALUE limit, if so it suggests there are other problems. ? I suspect this use of queues in AppletPanel could be cleaned up given the usages of with synchronised blocks (and the sun.misc.Queue style is probably a hangover from the java.util.Vector days). Anyway, that?s for another day if the AWT devs want to take that on :-) Paul. > >> then probably OOM(or something like that) will be better? > > I don?t think OOM is quite right. Maybe ISE, as above is better? > > -Chris. > > >> On 11/12/15 20:22, Chris Hegarty wrote: >>> More technical debt in sun.misc? >>> >>> Java SE has had support for Queues in Collections for many major releases, >>> sun.misc.Queue seems to predate that. I cannot find any usages outside of the >>> JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to >>> provide the necessary minimum functionality required by AppletPanel, FIFO >>> blocking operations. >>> >>> The changes are quite small so I just included the diffs inline. >>> >>> Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion >>> either way. >>> >>> $ hg rm src/java.base/share/classes/sun/misc/Queue.java >>> >>> diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>> --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>> +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>> @@ -38,6 +38,7 @@ >>> import java.security.*; >>> import java.util.*; >>> import java.util.Locale; >>> +import java.util.concurrent.LinkedBlockingQueue; >>> import sun.awt.AWTAccessor; >>> import sun.awt.AppContext; >>> import sun.awt.EmbeddedFrame; >>> @@ -45,7 +46,6 @@ >>> import sun.misc.ManagedLocalsThread; >>> import sun.misc.MessageUtils; >>> import sun.misc.PerformanceLogger; >>> -import sun.misc.Queue; >>> import sun.security.util.SecurityConstants; >>> >>> /** >>> @@ -247,8 +247,7 @@ >>> /** >>> * AppletEvent Queue >>> */ >>> - private Queue queue = null; >>> - >>> + private LinkedBlockingQueue queue = null; >>> >>> public synchronized void addAppletListener(AppletListener l) { >>> listeners = AppletEventMulticaster.add(listeners, l); >>> @@ -276,10 +275,10 @@ >>> synchronized(this) { >>> if (queue == null) { >>> //System.out.println("SEND0= " + id); >>> - queue = new Queue<>(); >>> + queue = new LinkedBlockingQueue<>(); >>> } >>> - Integer eventId = Integer.valueOf(id); >>> - queue.enqueue(eventId); >>> + boolean inserted = queue.offer(id); >>> + assert inserted; >>> notifyAll(); >>> } >>> if (id == APPLET_QUIT) { >>> @@ -303,8 +302,8 @@ >>> while (queue == null || queue.isEmpty()) { >>> wait(); >>> } >>> - Integer eventId = queue.dequeue(); >>> - return new AppletEvent(this, eventId.intValue(), null); >>> + int eventId = queue.take(); >>> + return new AppletEvent(this, eventId, null); >>> } >>> >>> boolean emptyEventQueue() { >>> >>> -Chris. >>> >> >> >> -- >> Best regards, Sergey. > From volker.simonis at gmail.com Mon Dec 14 10:23:40 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Dec 2015 11:23:40 +0100 Subject: Is setting -Dsun.jnu.encoding from the command line supposed to work? In-Reply-To: <566B129E.80801@oracle.com> References: <566B0D9B.90501@oracle.com> <566B129E.80801@oracle.com> Message-ID: Hi Sherman, thanks for providing the detailed history to this issue. At least for testing purpose it could be definitely nice to set sun.jnu.encoding. It may be also useful on platforms where setlocale() returns bogus values. But I won't insist in changing this until we don't have a real problem with it. Regards, Volker On Fri, Dec 11, 2015 at 7:14 PM, Xueming Shen wrote: > On 12/11/2015 09:53 AM, Xueming Shen wrote: >> >> Don't do it, that's all I would suggest :-) same as "file.encoding", they >> are >> both supposed to be informative read-only system property. >> >> Here is the history of sun.jnu.encoding >> http://ccc.us.oracle.com/4958170 >> > > My apology, forgot the "ccc" is still an internal site. Here is the > copy/paste of > the history. It's mainly to solve the Windows' user/system locale setting > issue. > It is supposed to be an informative system property to help the jvm to > communicate with the underlying os with the appropriate encoding. Its value > should be absolutely obtained from the system setting not set from the > command > line. While it might be desired in some use scenario to have the > file.encoding set > to a different value, I'm not convinced that the sun.jnu.encoding need to be > customized > > -sherman > > -------------------------------------------------------------------------------------------------------------- > Problem > This request addresses the following 3 bugs. > > 4958170: javaw does not retrieve the user locale > 4891531: javaw and java get different default locale from OS > 4989534: Regional / Language setting improperly detected with a multi-user > PC > > Windows has 2 locale settings called User Locale and System Locale. > According to Microsoft's documentation System Locale is a legacy > compatibility mode rather than a true locale and User Locale is what > Windows really use for formatting dates, times, currentcy and large > numbers. JDK's documentation has expressly stated that these > two must be the same to be supported, but users do not always follow > this and JDK is internally inconsistent if these settings are > different depending on how java is launched. > > Also an incorrect change to javaw in 1.4.2 to attempt to fix one > observed inconsistent case of different System Locale and User > Locale setting created yet another internal inconsistency. > > These JDK bugs and inconsistencies need to be resolved. > > Background: > > (1)From the very beginning we have 2 groups of end user on W2k/XP who > have different(opposite) opinions on how the java default locale > should be set, based on their different use scenarios. One group > believes the default java locale should be the same as what Windows > System Locale is and other prefers that it should be the same as > Windows User Locale. > Until recently we have been purposely avoiding to face this issue > directly (because the reality that java runtime is NOT a real win32 > Unicode app) by insisting the SUPPORTED use scenario is to set both > UserLocale and SystemLocale to the same locale/language on W2K/XP. > > The related doc is at > http://java.sun.com/j2se/1.4.2/docs/guide/intl/locale.doc.html#jfc > > However we've started to see more and more bugs get filed to complain > this restriction (guess this is mostly because more and more apps/ > users have been migrating to W2K/XP, which is a real multilingual > environment compared to previous OSs) and we believe we need to make > it clear in Tiger that the java default locale should be set solely > based on Windows User Locale setting in ControlPanel's RegionSetting, > from the perspective of what User Locale is defined on Windows and > what java default Locale is defined on Java platform. > > You can find the official MS definition of System Locale, User Locale > and Thread Locale at > http://www.microsoft.com/globaldev/reference/localetable.mspx > > The highlights of some concepts we care are: > (a)Windows Locale > A locale is either a language or a language in combination with > a country that a user wants to use for formatting dates, times, > currency, and large numbers. > > (b)Windows User Locale > The user locale determines, which default settings a user wants > to use for formatting dates, times, currency, and large numbers. > > (c)Windows System Locale > The system locale is not really a locale. It determines which > codepages (ANSI, DOS, and Macintosh) are used on the system by > default. > ... > If it weren't be so long the system locale should be called > legacy applications compatibility setting, because that is > really what it is. > > (d)Windows Thread Locale > The thread locale defaults to the user locale and determines the > formatting dates, times, currency, and large numbers for the > thread. It can be changed programmatically using the API > SetThreadLocale. In most cases the thread locale should not be > overwritten > > And "java locale" is defined as > > A Locale object represents a specific geographical, political, or > cultural region. An operation that requires a Locale to perform its > task is called locale-sensitive and uses the Locale to tailor > information for the user. For example, displaying a number is a > locale-sensitive operation--the number should be formatted according > to the customs/conventions of the user's native country, region, or > culture. > > So it's clear that Windows System Locale actually has nothing to do > with locale and java locale at all, java locale definitely should > not derived from Windows System Locale setting. > > Having said that the fact java runtime is a "Ansi" non-unicode app > forces java runtime to still have heavy dependency on Windows > System Locale setting. More specifically the def of system property > "file.encoidng" and some of its usage in j2se's implementation > (jni_util.c), currently this system property is derived from the > same setting of what the default java locale comes from. It's not > a problem when System Locale and User locale are the same, but when > these 2 setting are incompatible, some usages of "file.encoding" > will be problematic (Considering when you system locale is Japanese > and user locale is English and you, as a Ansi app, try to speak > with the System by using English). > > The list of some of these user locale/System Locale setting related > bugs is at > http://javaweb.sfbay/~sherman/Win32_locale_setting_bugs.html > > (2)The "Inconsistency" of Windows API doc and Windows implementation > of GetThreadLocale() when launching app from Dos/Command Prompt as > a console app (in java's case, launch java from "java") > > Based on Windows document, GetThreadLocale() should return the > Locale of this thread and it should be the "User Locale", it's > true for most of the cases. But in scenario like > > -System Locale is set to a DBCS locale (like Japanese or Chinese) > -User Locale is set to a SBCS locale (like English) > -Start the app from Dos Prompt (as a concole app) > > The GetThreadLocale() will not return the value set in User Locale > (English) but what set in System Locale (Japanese), my guess is > that this is because the Dos Prompt/Command Prompt itself is a > Ansi/non-Uniocde app and it is doing something special when the > system locale is a DBCS locale. > > (3)Starting from JDK1.4.2 the default locale of java runtime will be > set to different values when launched from "javaw" or "java" on > W2K and XP, if the User Locale and System Locale settings of the > underlying Windows system are different. More specifically, if java > runtime is launched from "javaw", the default locale will be set > based on Windows System Locale setting and if launched from "java" > the java default locale will be set based on Windows User Locale > setting. This causes big confusion for developers and end users who > work on multilingual W2K/XP environment. The direct trigger of > #4891531 is the fix for bug#4629351 which in launcher's win32 > java_md.c we added one line code in WinMain > > SetThreadLocale(GetSystemDefaultLCID()); > > to force the java runtime's thread locale to be Windows System > Locale, the result of this change is that the java default locale > will be set to whatever set in Windows System Locale. But this line > of code will never be executed if we launch java runtime through > "java" command, this is where the inconsistency comes from. > > > Solution > To the fullest extent possible, make the User Locale the default > locale used by the JRE. The basic fix for this is to call the correct > Windows API and use that as the basis for setting the Java locale and > system property file.encoding. This will make the windows behavior > consistent with the experience on Solaris and Linux. > > However since some parts of the JRE are still a "windows legacy > application" that cannot always use the user locale (ie not all > of the JRE is a unicode application in the windows meaning of the > term) then some additional measures need to be, so the proposed > fixes are > > (1)Removed the inappropriate fix of #4629351 (from java_md.c). The > java default locale (language, country) and the file.encoding > system property will be solely based on what the User Locale is > (use GetUserDefaultLCID() in java_props.md). > > (2)We will not change our public position in Tiger to claim official > support for runtime environment with different (incompatibal) > System Locale and User Locale setting on XP/W2K because we are > still running java runtime as a non-Unicode app and the sequence > that there are still issues left in some places that can not be > solved before we migrate vm and launcher code to a pure > unicode-based implementaiton > > (3)Introduce in a new "internal use only" system property > > sun.jnu.encoding > > to be used in jni_util.c to replace the file.encoding in method > "initializeEncoding(JNIEnv *env)", this change will affect 2 > jni_util.c methods on Windows > > NewStringPlatform > GetPlatformStringChar > > Compared to file.encoding, the sun.jnu.encoding property will be > set based on what Windows System Locale is on Windows platforms. > On Solaris/Linux this priority will remain the same as > file.encoding. > > The reasons why we need to introduce this new property and use it > in jni_util.c are > > (1)NewStringPlatform and GetPlatformStringChar are 2 methods used > internally by j2se impl to do the text encoding conversion when > need to talk with underlying platform (again, this is because our > runtime is not a win32 Unicode app). This "platform encoding" must > be the encoding that matches what the System Locale setting is. It > does not make any sense (and it does not work either) to use the > encoding derived from the User Locale setting, the Windows system > will simply not understand it if System Locale and User Locale > setting are not compatible. > > (2)We want to have file.encoding derived from what the Windows User > Locale setting is (when have different System Locale and User > Locale settings), file.encoding which will mostly be used to set > the default encoding for "contents" of input/output stream should > always match what the default java locale is (which is from User > Locale setting now). > > You can find all usages of NewStringPlatform and GetPlatformString > inside j2se at > http://javaweb.sfbay/~sherman/NewStringPlatform_GetStringPlatformChar > and the usage of "file.encoding" at > http://javaweb.sfbay/~sherman/file_encoding > > The webrev for proposed fix for your reference is at > http://javaweb.sfbay/~sherman/Webrevs/webrev_4891531_4958170 > (regression test cases will be added) > > Interface summary > exported private property file.encoding will be solely > derived from User Locale setting on Windows > internal property sun.jnu.encoding will be solely derivied > from System Locale setting on Windows > imported external other GetUserDefaultLCID, > GetSystemDefaultLCID, GetThreadLocale > exported external method java.util.Locale.getDefault() > and java.nio.charset.Charset.defaultCharset() > > Specification > (1)sun.jnu.encoding: > An internal use only system property that derived from what Windows > System Locale setting is on Windows platform. It has the same value > as file.encoding on Solaris and Linux platform. > > (2)java.util.Locale.getDefault() > java.nio.charset.Charset.defaultCharset() > > We never publicly documented how the values returned by these 2 > methods are derived from the host env setting and still are not > going to document it. However, the return values of these 2 methods > are now consistently derived on Windows from the user locale > as reported by GetUserDefaultLCID. > > (3)file.encoding > > We never publicly documented how this property value is derived from the > host environment settings and still are not going to document it. However, > this value is now consistently derived on Windows from the user locale as > reported by GetUserDefaultLCID. > > Compatibility risk: low > First of all the proposed solution should NOT have any compatibility > impact to our "official supported" use scenario in which the Windows > System locale and User locale are set to the same language. What we > are trying to do is to make the java runtime behave more consistent > in scenarios that we dont officially support but more and more end > users are running into. In these scenarios our launcher "java" and > "javaw" have severe inconsistent behavior which I think we have to > pay a price to fix. Followings are the impact that we know we will > have with the proposed solution. > > > (1)file.encoding will always be derived from User Locale setting. > > Compared to current impl, file.encoding in proposed change will > always be derived from user locale setting, this will cause a > incompatible behavior to some apps (if they depend on the > assumption that file.encoding will always be derived from System > Locale setting)when the System Locale and User Locale settings > are not "compatible" (even this is not an official supported > scenario on Java/JDK i18n document mentioned before) But given > the fact that our current impl already breaks this assumption in > some env scenarios and have severe inconsistency here and there, > I believe this is a decision/choice we must to make and a risk we > have to face with, if we want to address the inconsistency > > (2)concern of adding a sun.jnu.encoding and using it instead of > file.encoding in jni_util.c > > The win32 FileSystem and awt has been migrated to MSLU, so there > is no compatibility issue in this 2 big chunks. Other than that > j2se currently does not have heavily dependency on these 2 > methods, I've scanned all places (see url above) where these 2 > jni_util methods are being used, my conclusion is that it makes > more sense to use the encoding from "System Locale" setting > instead of the "User Locale" setting in all of the places. The > only places that I would have little concern of compatibility are > (1)in System.c when converting those system properties such as > usr.name, usr.dir from platform encoding to uncode encoding and > (2)in launcher code when parsing the command line args to > unicode encoded args for java main class, in scenario like > > -System Locale is set to English > -User Locale is set to Japanese > -Someone tries to pass in a command line option/properties/flag > in Japanese like -Dxxx=yyyy (which yyyy is in Japanese) > > Since the "sun.jnu.encoding" now is "English"/cp1252, this Japanese > option/flag/properties will not be converted correctly into java > runtime. > > But given the fact the Windows System Locale now is "English > /cp1252", even you are able to input the Japanese from command > line (in this case the "dos prompt app" is in English/cp1252 mode, > it does not work well with Japanese, though you can use > copy/paste...), this Japanese text has been collapsed already even > before java gets a hand on it, means the text in args from C main > and from getenv is collapsed already. So this should not be an > issue. It does not work anyway, even in current impl. > > > 3)What we have in 1.4.1, 1.4.2 and in proposed 1.5 when the Windows > settings are different. > > > a)UserLocale=Japanese/SystemLocale=English > > java Java file.encoding sun.jnu.encoding > launcher Locale property property > 1.4.1/java Ja MS932 > 1.4.1/javaw ja MS932 > 1.4.2/java ja MS932 > 1.4.2/javaw en Cp1252 > 1.5.0/java ja MS932 Cp1252 > 1.5.0/javaw ja MS932 Cp1252 > > > b)UserLocale=English/SystemLocale=Japanese > > java Java file.encoding sun.jnu.encoding > launcher Locale property property > 1.4.1/java ja MS932 > 1.4.1/javaw en Cp1252 > 1.4.2/java ja MS932 > 1.4.2/javaw ja MS932 > 1.5.0/java en Cp1252 MS932 > 1.5.0/javaw en Cp1252 MS932 From paul.sandoz at oracle.com Mon Dec 14 10:26:07 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Dec 2015 11:26:07 +0100 Subject: Reference.reachabilityFence In-Reply-To: References: <2D27BCFB-77ED-4C83-985E-102DC4B41C97@oracle.com> <0CCC1C56-EDC9-47C4-B170-5A66A6C81495@oracle.com> <7B0271EB-A012-435F-95D2-4F9E64E20220@oracle.com> <20151207095825.952677@eggemoggin.niobe.net> <430729B7-AA2B-499A-8660-C0BBFFC69E5E@oracle.com> <2AE57802-9204-4E48-81E0-98E65D43F1E0@oracle.com> Message-ID: > On 11 Dec 2015, at 16:52, Vitaly Davidovich wrote: > > Hi Paul, > > No objections, but just wanted to summarize a couple of possible key performance issues that were raised on the concurrency-interest thread. You may have picked them up already, so pardon the repetition: > > Thanks, that?s a useful summary from a very long thread. I have added those (and that in your other email) as a comment on the current issue with links to the discussion: https://bugs.openjdk.java.net/browse/JDK-8133348?focusedCommentId=13877606&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13877606 Paul. > 1) current impl/prototype is purposely barred from inlining - this will be a compiler optimization fence, particularly bad in loops > > 2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); }" idiom will significantly increase bytecode size, possibly impacting inlining. > > I'm sure you guys will address this in the end, but just wanted to reiterate those just in case :). > > Thanks > From cheleswer.sahu at oracle.com Mon Dec 14 10:49:08 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Mon, 14 Dec 2015 16:19:08 +0530 Subject: Need help to understand TLS behavior Message-ID: <566E9EA4.202@oracle.com> Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code /jdk8u-cpu /jdk /src /solaris /classes /java /lang /UNIXProcess.java 227 ThreadFactory threadFactory =grimReaper -> { 228 // Our thread stack requirement is quite modest. 229 Thread t =*new* Thread (systemThreadGroup ,grimReaper , 230 "process reaper",32768); Here reaper thread is created with fixed stack size "32768 ", which causes StackOverFlowError when TLS is set to 32k around. If I remove this fixed size and make it default, test works fine. Thread t =*new* Thread (systemThreadGroup ,grimReaper , 230 "process reaper"); I have run several test with TLS size 32k , 64k ,128k and more . The interesting part, it works well with 64k and 128k TLS size but not with 32k. So my questions are as follows: > What is the motivation behind the fixed thread stack size ? > will it be ok to replace the fixed stack size with default or stack size setting is platform sensitive? > How TLS sizes are interpreted internally, which allows 64k and 128k to work but not to 32k ? I would really appreciate, if anyone have any opinion on this. Regards, Cheleswer From cheleswer.sahu at oracle.com Mon Dec 14 12:34:14 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Mon, 14 Dec 2015 18:04:14 +0530 Subject: Need help to understand TLS behavior In-Reply-To: <566EB5A4.5080102@oracle.com> References: <566EB5A4.5080102@oracle.com> Message-ID: <566EB746.3040801@oracle.com> Hi, I am investigating an issue, in which test with TLS size set to 32K is failing with StackOverFlowError. During investigation I found the below code http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java ThreadFactory threadFactory = grimReaper -> { // Our thread stack requirement is quite modest. Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper", 32768); Here reaper thread is created with fixed stack size "32768 ", which causes StackOverFlowError when TLS is set to 32k around. If I remove this fixed size and make it default, test works fine. Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper"); I have run several test with TLS size 32k , 64k ,128k and more . The interesting part, it works well with 64k and 128k TLS size but not with 32k. So my questions are as follows: > What is the motivation behind the fixed thread stack size ? > will it be ok to replace the fixed stack size with default or stack size setting is platform sensitive? > How TLS sizes are interpreted internally, which allows 64k and 128k to work but not to 32k ? I would really appreciate, if anyone have any opinion on this. Regards, Cheleswer From david.holmes at oracle.com Mon Dec 14 12:59:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 22:59:23 +1000 Subject: Need help to understand TLS behavior In-Reply-To: <566EB746.3040801@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> Message-ID: <566EBD2B.9010803@oracle.com> What is TLS in this context? Thanks, David On 14/12/2015 10:34 PM, cheleswer sahu wrote: > Hi, > > I am investigating an issue, in which test with TLS size set to 32K is > failing with StackOverFlowError. During investigation I found the below > code > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java > > > ThreadFactory threadFactory = grimReaper -> { > // Our thread stack requirement is quite modest. > Thread t = new Thread(systemThreadGroup, grimReaper, > "process reaper", 32768); > > Here reaper thread is created with fixed stack size "32768 ", which > causes StackOverFlowError when TLS is set to 32k around. > If I remove this fixed size and make it default, test works fine. > > Thread t = new Thread(systemThreadGroup, grimReaper, > "process reaper"); > > I have run several test with TLS size 32k , 64k ,128k and more . > The interesting part, it works well with 64k and 128k TLS size but not > with 32k. > So my questions are as follows: >> What is the motivation behind the fixed thread stack size ? >> will it be ok to replace the fixed stack size with default or stack > size setting is platform sensitive? >> How TLS sizes are interpreted internally, which allows 64k and 128k > to work but not to 32k ? > > I would really appreciate, if anyone have any opinion on this. > > Regards, > Cheleswer > > > From cheleswer.sahu at oracle.com Mon Dec 14 13:06:08 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Mon, 14 Dec 2015 18:36:08 +0530 Subject: Need help to understand TLS behavior In-Reply-To: <566EBD2B.9010803@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> Message-ID: <566EBEC0.1000609@oracle.com> Hi David, TLS is thread local storage. In test program it is defined using #define TLS_SIZE 32 int __thread XYZ[TLS_SIZE * 1024]; Regards, Cheleswer On 12/14/2015 6:29 PM, David Holmes wrote: > What is TLS in this context? > > Thanks, > David > > On 14/12/2015 10:34 PM, cheleswer sahu wrote: >> Hi, >> >> I am investigating an issue, in which test with TLS size set to 32K is >> failing with StackOverFlowError. During investigation I found the below >> code >> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >> >> >> >> ThreadFactory threadFactory = grimReaper -> { >> // Our thread stack requirement is quite modest. >> Thread t = new Thread(systemThreadGroup, grimReaper, >> "process reaper", 32768); >> >> Here reaper thread is created with fixed stack size "32768 ", which >> causes StackOverFlowError when TLS is set to 32k around. >> If I remove this fixed size and make it default, test works fine. >> >> Thread t = new Thread(systemThreadGroup, grimReaper, >> "process reaper"); >> >> I have run several test with TLS size 32k , 64k ,128k and more . >> The interesting part, it works well with 64k and 128k TLS size but not >> with 32k. >> So my questions are as follows: >>> What is the motivation behind the fixed thread stack size ? >>> will it be ok to replace the fixed stack size with default or stack >> size setting is platform sensitive? >>> How TLS sizes are interpreted internally, which allows 64k and 128k >> to work but not to 32k ? >> >> I would really appreciate, if anyone have any opinion on this. >> >> Regards, >> Cheleswer >> >> >> From frederic.parain at oracle.com Mon Dec 14 13:23:41 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 14:23:41 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> Message-ID: <566EC2DD.5000404@oracle.com> Karen, Thank you for your review. Fred On 23/11/2015 20:10, Karen Kinnear wrote: > Frederic, > > Looks good. > > Many thanks. > Karen > >> On Nov 23, 2015, at 12:44 PM, Frederic Parain >> > wrote: >> >> Karen, >> >> Thank you for your review, my answers are in-lined below. >> >> New Webrevs (including some fixes suggested by Paul Sandoz): >> >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >> >> On 20/11/2015 19:44, Karen Kinnear wrote: >>> Frederic, >>> >>> Code review for web revs you sent out. >>> Code looks good. I am not as familiar with the compiler code. >>> >>> I realize you need to check in at least a subset of the >>> java.util.concurrent changes for >>> the test to work, so maybe I should not have asked Doug about his >>> preference there. >>> Sorry. >>> >>> I am impressed you found a way to make a reproducible test! >>> >>> Comments/questions: >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >> >> Fixed >> >>> 2. IIRC, due to another bug with windows handling of our guard pages, >>> this >>> is disabled for Windows. Would it be worth putting a comment in the >>> bug , 8067946, that once this is fixed, the reserved stack logic on >>> windows >>> will need testing before enabling? >> >> More than testing, the implementation would have to be completed on >> Windows. I've added a comment to JDK-8067946. >> >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>> this is in interpreter code, you explicitly return the Java sender >>> of the current frame. I was expecting to see that on Solaris_sparc >>> and Windows >>> as well? I do see the assertion in caller that you do have a java frame. >> >> It doesn't make sense to check the current frame (no bytecode has been >> executed yet, so risk of partially executed critical section). I did the >> change but not for all platforms. This is now fixed for Solaris_SPARC >> and Windows too. >> >>> 4. test line 83 ?writtent? -> ?written? >> >> Fixed >> >>> 5. I like the way you set up the preallocated exception and then set >>> the message - we may >>> try that for default methods in future. >>> >>> 6. I had a memory that you had found a bug in safe_for_sender - did >>> you already check that in? >> >> I've fixed x86 platforms in JDK-8068655. >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >> I had hoped it would have been silently accepted :-) >> >> >>> 7. I see the change in trace.xml, and I see an include added to >>> SharedRuntime.cpp, >>> but I didn?t see where it was used - did I just miss it? >> >> trace.xml changes define a new event. >> This event is created at sharedRuntime.cpp::3006 and it is used >> in the next 3 lines. > Thanks. I must have mistyped when I searched for it. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email:Frederic.Parain at oracle.com > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From Roger.Riggs at Oracle.com Mon Dec 14 14:15:55 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Dec 2015 09:15:55 -0500 Subject: Need help to understand TLS behavior In-Reply-To: <566EBEC0.1000609@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> Message-ID: <566ECF1B.80406@Oracle.com> Hi, The reaper thread that waits for process exit has minimal stack requirements, and if possible should not consume all of the memory for a full stack. The 32k number is a guess at a small stack. It has worked so far except in cases where the VM configuration or parameters increase the size of stack the VM needs. $.02, Roger On 12/14/2015 8:06 AM, cheleswer sahu wrote: > Hi David, > TLS is thread local storage. In test program it is defined using > > #define TLS_SIZE 32 > int __thread XYZ[TLS_SIZE * 1024]; > > Regards, > Cheleswer > On 12/14/2015 6:29 PM, David Holmes wrote: >> What is TLS in this context? >> >> Thanks, >> David >> >> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >>> Hi, >>> >>> I am investigating an issue, in which test with TLS size set to 32K is >>> failing with StackOverFlowError. During investigation I found the below >>> code >>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >>> >>> >>> >>> ThreadFactory threadFactory = grimReaper -> { >>> // Our thread stack requirement is quite modest. >>> Thread t = new Thread(systemThreadGroup, grimReaper, >>> "process reaper", 32768); >>> >>> Here reaper thread is created with fixed stack size "32768 ", which >>> causes StackOverFlowError when TLS is set to 32k around. >>> If I remove this fixed size and make it default, test works fine. >>> >>> Thread t = new Thread(systemThreadGroup, grimReaper, >>> "process reaper"); >>> >>> I have run several test with TLS size 32k , 64k ,128k and more . >>> The interesting part, it works well with 64k and 128k TLS size but not >>> with 32k. >>> So my questions are as follows: >>>> What is the motivation behind the fixed thread stack size ? >>>> will it be ok to replace the fixed stack size with default or stack >>> size setting is platform sensitive? >>>> How TLS sizes are interpreted internally, which allows 64k and 128k >>> to work but not to 32k ? >>> >>> I would really appreciate, if anyone have any opinion on this. >>> >>> Regards, >>> Cheleswer >>> >>> >>> > From frederic.parain at oracle.com Mon Dec 14 14:44:25 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 15:44:25 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> Message-ID: <566ED5C9.60108@oracle.com> Goetz, The reserved zone is sometime considered as a subpart of the yellow zone, and sometime as an independent entity. Technically the reserved zone is placed just before the yellow zone, but the way it is managed depends on the context. In most cases, there's no specially annotated methods on the thread's call stack. In this configuration the reserved zone is considered as being part of the yellow zone. This means that the protection of the reserved zone is always the same as the protection of the yellow zone. In some cases, a thread could have one or more methods on its call stack with the ReservedStackAccess annotation. In this configuration, the reserved zone is managed as a separate entity. Initially protected like the yellow zone, access to the reserved zone can be temporary granted for the execution of some critical sections. This means that the protection of the reserved zone can be removed while the yellow zone is still protected. The take over is that the VM code should be able to manage the reserved zone alone or the reserved zone and the yellow zone together. I've already renamed a method because of this change: stack_yellow_zone_enabled() -> stack_guards_enabled() Here, "guards" refers to the two guard zones: reserved + yellow. If you want to change it for a better name, more explicit, I'm fine with that. We just have to preserve the different operations required for stack overflow management. Let's say R(x) and Y(x) represent the protection of the reserved zone and the yellow zone respectively. And let's say that x = P means "zone protected" and x = G means "access granted" The different configurations are: (1) R(P) Y(P) => initial configuration (2) R(G) Y(P) => first stack overflow with annotated method on stack (3) R(G) Y(G) => stack overflow without annotated method on stack, or second stack overflow with annotated method on stack And the transitions are: (1) -> (3) -> (1) or (1) -> (2) -> (1) or (1) -> (2) -> (3) -> (1) I hope this would clarify the semantic of the reserved zone. If it doesn't, let me know, I'll try to explain it differently. Thanks, Fred On 14/12/2015 14:59, Lindenmaier, Goetz wrote: > Hi Frederic, > > I'm now again working on my change "8139864: Improve handling of stack protection zones." > Coleen had asked me to wait until this change of yours is submitted. > > You changed the stack_yellow_zone accessor functions in thread.hpp to > handle both zones, yellow and reserved. > Therefore, reading the code, the reserved zone seems to be part of the yellow zone. > > In the description of the bug, it says "The new zone defined by the proposed > solution is placed just before the yellow zone." This reads as if the zones are > separate. > > Would you mind if I rename the stack_yellow_zone accessor functions to > stack_yellow_reserved_zone? This would make clear in the code that this > are two separate zones. > > I anyways have to adapt most of the calls to these accessors. > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Frederic Parain >> Sent: Montag, 14. Dezember 2015 14:24 >> To: Karen Kinnear >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev > dev at openjdk.java.net> >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical >> Sections >> >> Karen, >> >> Thank you for your review. >> >> Fred >> >> On 23/11/2015 20:10, Karen Kinnear wrote: >>> Frederic, >>> >>> Looks good. >>> >>> Many thanks. >>> Karen >>> >>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain >>>> > >> wrote: >>>> >>>> Karen, >>>> >>>> Thank you for your review, my answers are in-lined below. >>>> >>>> New Webrevs (including some fixes suggested by Paul Sandoz): >>>> >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >>>> >>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Code review for web revs you sent out. >>>>> Code looks good. I am not as familiar with the compiler code. >>>>> >>>>> I realize you need to check in at least a subset of the >>>>> java.util.concurrent changes for >>>>> the test to work, so maybe I should not have asked Doug about his >>>>> preference there. >>>>> Sorry. >>>>> >>>>> I am impressed you found a way to make a reproducible test! >>>>> >>>>> Comments/questions: >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>> >>>> Fixed >>>> >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>> this >>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>> windows >>>>> will need testing before enabling? >>>> >>>> More than testing, the implementation would have to be completed on >>>> Windows. I've added a comment to JDK-8067946. >>>> >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if >>>>> this is in interpreter code, you explicitly return the Java sender >>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>> and Windows >>>>> as well? I do see the assertion in caller that you do have a java frame. >>>> >>>> It doesn't make sense to check the current frame (no bytecode has been >>>> executed yet, so risk of partially executed critical section). I did the >>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>> and Windows too. >>>> >>>>> 4. test line 83 ?writtent? -> ?written? >>>> >>>> Fixed >>>> >>>>> 5. I like the way you set up the preallocated exception and then set >>>>> the message - we may >>>>> try that for default methods in future. >>>>> >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>> you already check that in? >>>> >>>> I've fixed x86 platforms in JDK-8068655. >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>> I had hoped it would have been silently accepted :-) >>>> >>>> >>>>> 7. I see the change in trace.xml, and I see an include added to >>>>> SharedRuntime.cpp, >>>>> but I didn?t see where it was used - did I just miss it? >>>> >>>> trace.xml changes define a new event. >>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>> in the next 3 lines. >>> Thanks. I must have mistyped when I searched for it. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>>> -- >>>> Frederic Parain - Oracle >>>> Grenoble Engineering Center - France >>>> Phone: +33 4 76 18 81 17 >>>> Email:Frederic.Parain at oracle.com >>> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From Roger.Riggs at Oracle.com Mon Dec 14 15:06:01 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Dec 2015 10:06:01 -0500 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <96b1ddd9-e543-42e5-8597-9b466225f854@default> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> <96b1ddd9-e543-42e5-8597-9b466225f854@default> Message-ID: <566EDAD9.8090406@Oracle.com> Hi Ramanand, Thanks for the cleanup of the test. On 12/14/2015 3:14 AM, Ramanand Patil wrote: > RE: Review request for JDK-8066982: ZonedDateTime.parse() > returns wrong ZoneOffset around DST fall transition > > Hi Rogerand all, > > Please review the updated > Webrev:_http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/_ > > DateTimeFormatter.java has an added import that is unused and should be removed. Looks fine. Thanks, Roger > > > Bug:_https://bugs.openjdk.java.net/browse/JDK-8066982_ > > Roger, please see my commentsabout new tests: > > -All my test methodswere earlier generic with main method and hence > had/private static/qualifier.I have changed them now to match and to > be consistent with the existing tests.Thank you for pointing this. > > - I agree with you on this. Particularly when we have tests around DST > we can?t avoid timezone data. > > - I have defined dataProvider for every method and reduced the test > data for cases where zone is not > present(/testWithoutZoneWithoutOffset//()/and/testWithOffsetWithoutZone//()/). > > > But for the other 2 cases where zone is > present(/testWithZoneWithOffset//()/and/testWithZoneWithoutOffset//()/), > I feel most of the data cases are necessary and some are > required to be on safer side if in future the timezone rule > changes. Also, this bug fix mainly affects these cases. > > I have created the dataProvider kepping in mind the below > cases for 2 DST zones. > > 1. Time before overlap > > 2. Time during Overlap > > 3. Time after overlap > > 4. Valid Offsets for each of these times > > 5. Zero Offset for each time > > 6. Few Positive and negative invalid offsets for each time > > Regards, > > Ramanand. > > -----Original Message----- > > From: Roger Riggs > > Sent: Saturday, December 12, 2015 1:37 AM > > To:_core-libs-dev at openjdk.java.net_ > > Cc:_i18n-dev at openjdk.java.net_ > > Subject: Re: Review request for JDK-8066982: > ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition > > Hi, > > Stephen, can you confirm that the added text and test in > DateTimeFormatter is not a specification change? > > Our processes have a bit more to do if it is a spec change and it > would limit the backport to JDK 8. > > This bug fix will cause an existing TCK/JCK test to fail but that is > considered also a bug and is fixed. > > test/java/time/tck/java/time/TCKZonedDateTime.java > > Ramanand, some comments on the new test: > > - The 'private' qualifier on the tests and data providers is not > used in the current tests and > > is not consistently present in the new one. > > Since it has little/no function, the tests would be a bit cleaner > without it. > > - Typically, test that have data dependencies (such as the timezone > > data) cannot be used for > > compatibility to the specification, but the data is stable and it > seems unavoidable in this case. > > - Are all of the data cases necessary to validate the specification? > > Redundant cases extend the testing time without adding more confidence > to the quality. > > Thanks, Roger > > > On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > > > I believe this is suitable for committing, thanks, other reviews welcome! > > > Stephen > > > > > > > > > > > > On 10 December 2015 at 15:36, Ramanand Patil > <_ramanand.patil at oracle.com_> wrote: > > >> Hi all, > > >> > > >> Please review the updated webrev: > > >>_http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/_ > > >> > > >> I have modified the fix and test cases as per inputs given by Stephen. > Also, I have added the javadocs changes in this patch which were > proposed in the bug. > > >> > > >> Bug link is:_https://bugs.openjdk.java.net/browse/JDK-8066982_ > > >> > > >> > > >> Regards, > > >> Ramanand. > > >> > > >> -----Original Message----- > > >> From: Stephen Colebourne [_mailto:scolebourne at joda.org_] > > >> Sent: Wednesday, December 09, 2015 4:46 PM > > >> To: core-libs-dev > > >> Cc: i18n-dev > > >> Subject: Re: Review request for JDK-8066982: > > >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall > > >> transition > > >> > > >> The logic looks fine. > > >> > > >> In the main code, this part > > >>.getLong(INSTANT_SECONDS); > > >> can be replaced with > > >>.toEpochSecond(); > > >> which will be slightly faster. > > >> > > >> In the test case, this part > > >>.plus(15, ChronoUnit.MINUTES); > > >> can be replaced with > > >>.plusMinutes(15) > > >> > > >> And > > >>.with(ChronoField.OFFSET_SECONDS, > > >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) > > >> can be replaced with > > >>.with(ZoneOffset.of(offsetSamples[j])) > > >> > > >> In addition to the looping tests, I'd like to see the examples from the > bug report as test cases. Those tests would be simple to follow and > explain, whereas the looping tests are a little hard to follow. > > >> > > >> thanks for fixing this > > >> Stephen > > >> > > >> > > >> > > >> On 9 December 2015 at 07:44, Ramanand Patil > <_ramanand.patil at oracle.com_> wrote: > > >>> HI all, > > >>> > > >>> > > >>> > > >>> Please review a fix for Bug - HYPERLINK > > >>> "_https://bugs.openjdk.java.net/browse/JDK-8066982_"JDK-8066982 > > >>> > > >>> > > >>> > > >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone > offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime > (different offset). This error starts exactly at the transition time > (included) and ends one hour later (excluded). > > >>> > > >>> > > >>> > > >>> Webrev > -_http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/_ > > >>> > > >>> > > >>> > > >>> One existing test case in TCKZonedDateTime.java is also modified, > because - when offset is invalid the local time is changed to make the > result valid. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Ramanand. > > From frederic.parain at oracle.com Mon Dec 14 15:19:41 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 14 Dec 2015 16:19:41 +0100 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> <566ED5C9.60108@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> Message-ID: <566EDE0D.7090004@oracle.com> Goetz, On 14/12/2015 16:11, Lindenmaier, Goetz wrote: > Hi Frederic, > > thanks for your fast reply. > From reading the code I guessed about what you explained, now > I understood more details, thanks! > > I will not fiddle with handling the zones. My change is only about > handling larger pages, i.e. the sizes of the zones, so there is no > danger I will break the mechanism you implemented. > >> The take over is that the VM code should be able to manage >> the reserved zone alone or the reserved zone and the yellow >> zone together. >> If you want to change it for a better name, more explicit, >> I'm fine with that. > Yes, I would like to change it to 'yellow_reserved' wherever > both are handled at the same time. > There's places where red+yellow+reserved are handled as > one, here I will use 'guard_zone'. That's aliged with > create_stack_guard_pages() which guards all (red, yellow, > reserved) of them. I believe that red+yellow+reserved are handled as one only during stack initialization. Once configured, the only moment when the red zone protection is changed is when the VM is about to generate a crash dump. Anyway, 'yellow_reserved' sounds good to me. >> stack_yellow_zone_enabled() -> stack_guards_enabled() >> >> Here, "guards" refers to the two guard zones: reserved >> + yellow. > Actually, it also includes that the red page is enabled, right? > > One question, in os_linux.cpp, you meant AMD64, not Itanium, right? > 27.18+#if defined(IA32) || defined(IA64) > I'll move that functionality to another place, so no need to fix it. You're right, I meant AMD64. Thanks, Fred >> -----Original Message----- >> From: Frederic Parain [mailto:frederic.parain at oracle.com] >> Sent: Montag, 14. Dezember 2015 15:44 >> To: Lindenmaier, Goetz ; Karen Kinnear >> >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev > dev at openjdk.java.net> >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical >> Sections >> >> Goetz, >> >> The reserved zone is sometime considered as a subpart of >> the yellow zone, and sometime as an independent entity. >> Technically the reserved zone is placed just before the >> yellow zone, but the way it is managed depends on the >> context. >> >> In most cases, there's no specially annotated methods on >> the thread's call stack. In this configuration the >> reserved zone is considered as being part of the yellow >> zone. This means that the protection of the reserved >> zone is always the same as the protection of the yellow >> zone. >> >> In some cases, a thread could have one or more methods >> on its call stack with the ReservedStackAccess annotation. >> In this configuration, the reserved zone is managed as >> a separate entity. Initially protected like the yellow >> zone, access to the reserved zone can be temporary granted >> for the execution of some critical sections. This means >> that the protection of the reserved zone can be removed >> while the yellow zone is still protected. >> >> The take over is that the VM code should be able to manage >> the reserved zone alone or the reserved zone and the yellow >> zone together. I've already renamed a method because of >> this change: >> stack_yellow_zone_enabled() -> stack_guards_enabled() >> >> Here, "guards" refers to the two guard zones: reserved >> + yellow. >> >> If you want to change it for a better name, more explicit, >> I'm fine with that. We just have to preserve the different >> operations required for stack overflow management. >> >> Let's say R(x) and Y(x) represent the protection of >> the reserved zone and the yellow zone respectively. >> And let's say that x = P means "zone protected" >> and x = G means "access granted" >> >> The different configurations are: >> >> (1) R(P) Y(P) => initial configuration >> (2) R(G) Y(P) => first stack overflow with annotated >> method on stack >> (3) R(G) Y(G) => stack overflow without annotated >> method on stack, or second stack >> overflow with annotated method >> on stack >> >> And the transitions are: >> >> (1) -> (3) -> (1) >> or >> (1) -> (2) -> (1) >> or >> (1) -> (2) -> (3) -> (1) >> >> I hope this would clarify the semantic of the reserved zone. >> If it doesn't, let me know, I'll try to explain it differently. >> >> Thanks, >> >> Fred >> >> On 14/12/2015 14:59, Lindenmaier, Goetz wrote: >>> Hi Frederic, >>> >>> I'm now again working on my change "8139864: Improve handling of stack >> protection zones." >>> Coleen had asked me to wait until this change of yours is submitted. >>> >>> You changed the stack_yellow_zone accessor functions in thread.hpp to >>> handle both zones, yellow and reserved. >>> Therefore, reading the code, the reserved zone seems to be part of the >> yellow zone. >>> >>> In the description of the bug, it says "The new zone defined by the >> proposed >>> solution is placed just before the yellow zone." This reads as if the zones >> are >>> separate. >>> >>> Would you mind if I rename the stack_yellow_zone accessor functions to >>> stack_yellow_reserved_zone? This would make clear in the code that this >>> are two separate zones. >>> >>> I anyways have to adapt most of the calls to these accessors. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Frederic Parain >>>> Sent: Montag, 14. Dezember 2015 14:24 >>>> To: Karen Kinnear >>>> Cc: hotspot-dev at openjdk.java.net; core-libs-dev >>> dev at openjdk.java.net> >>>> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for >> Critical >>>> Sections >>>> >>>> Karen, >>>> >>>> Thank you for your review. >>>> >>>> Fred >>>> >>>> On 23/11/2015 20:10, Karen Kinnear wrote: >>>>> Frederic, >>>>> >>>>> Looks good. >>>>> >>>>> Many thanks. >>>>> Karen >>>>> >>>>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain >>>>>> > >>>> wrote: >>>>>> >>>>>> Karen, >>>>>> >>>>>> Thank you for your review, my answers are in-lined below. >>>>>> >>>>>> New Webrevs (including some fixes suggested by Paul Sandoz): >>>>>> >>>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ >>>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ >>>>>> >>>>>> On 20/11/2015 19:44, Karen Kinnear wrote: >>>>>>> Frederic, >>>>>>> >>>>>>> Code review for web revs you sent out. >>>>>>> Code looks good. I am not as familiar with the compiler code. >>>>>>> >>>>>>> I realize you need to check in at least a subset of the >>>>>>> java.util.concurrent changes for >>>>>>> the test to work, so maybe I should not have asked Doug about his >>>>>>> preference there. >>>>>>> Sorry. >>>>>>> >>>>>>> I am impressed you found a way to make a reproducible test! >>>>>>> >>>>>>> Comments/questions: >>>>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? >>>>>> >>>>>> Fixed >>>>>> >>>>>>> 2. IIRC, due to another bug with windows handling of our guard pages, >>>>>>> this >>>>>>> is disabled for Windows. Would it be worth putting a comment in the >>>>>>> bug , 8067946, that once this is fixed, the reserved stack logic on >>>>>>> windows >>>>>>> will need testing before enabling? >>>>>> >>>>>> More than testing, the implementation would have to be completed >> on >>>>>> Windows. I've added a comment to JDK-8067946. >>>>>> >>>>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and >> solaris_x86 if >>>>>>> this is in interpreter code, you explicitly return the Java sender >>>>>>> of the current frame. I was expecting to see that on Solaris_sparc >>>>>>> and Windows >>>>>>> as well? I do see the assertion in caller that you do have a java frame. >>>>>> >>>>>> It doesn't make sense to check the current frame (no bytecode has >> been >>>>>> executed yet, so risk of partially executed critical section). I did the >>>>>> change but not for all platforms. This is now fixed for Solaris_SPARC >>>>>> and Windows too. >>>>>> >>>>>>> 4. test line 83 ?writtent? -> ?written? >>>>>> >>>>>> Fixed >>>>>> >>>>>>> 5. I like the way you set up the preallocated exception and then set >>>>>>> the message - we may >>>>>>> try that for default methods in future. >>>>>>> >>>>>>> 6. I had a memory that you had found a bug in safe_for_sender - did >>>>>>> you already check that in? >>>>>> >>>>>> I've fixed x86 platforms in JDK-8068655. >>>>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), >>>>>> I had hoped it would have been silently accepted :-) >>>>>> >>>>>> >>>>>>> 7. I see the change in trace.xml, and I see an include added to >>>>>>> SharedRuntime.cpp, >>>>>>> but I didn?t see where it was used - did I just miss it? >>>>>> >>>>>> trace.xml changes define a new event. >>>>>> This event is created at sharedRuntime.cpp::3006 and it is used >>>>>> in the next 3 lines. >>>>> Thanks. I must have mistyped when I searched for it. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>>> -- >>>>>> Frederic Parain - Oracle >>>>>> Grenoble Engineering Center - France >>>>>> Phone: +33 4 76 18 81 17 >>>>>> Email:Frederic.Parain at oracle.com >> >>>>> >>>> >>>> -- >>>> Frederic Parain - Oracle >>>> Grenoble Engineering Center - France >>>> Phone: +33 4 76 18 81 17 >>>> Email: Frederic.Parain at oracle.com >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From ramanand.patil at oracle.com Mon Dec 14 15:53:41 2015 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 14 Dec 2015 07:53:41 -0800 (PST) Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <566EDAD9.8090406@Oracle.com> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> <96b1ddd9-e543-42e5-8597-9b466225f854@default> <566EDAD9.8090406@Oracle.com> Message-ID: Hi Roger, ? The added import in DateTimeFormatter.java ?is because of the javadocs entry - {@link ChronoLocalDateTime#atZone(ZoneId)} ? ? Regards, Ramanand. ? From: Roger Riggs Sent: Monday, December 14, 2015 8:36 PM To: Ramanand Patil; core-libs-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition ? Hi Ramanand, Thanks for the cleanup of the test. On 12/14/2015 3:14 AM, Ramanand Patil wrote: Hi Roger and all, Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ DateTimeFormatter.java has an added import that is unused and should be removed. Looks fine. Thanks,? Roger Bug: https://bugs.openjdk.java.net/browse/JDK-8066982 Roger, please see my comments about new tests: - All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this. - I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data. - I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()). But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases. I have created the dataProvider kepping in mind the below cases for 2 DST zones. 1. Time before overlap 2. Time during Overlap 3. Time after overlap 4. Valid Offsets for each of these times 5. Zero Offset for each time 6. Few Positive and negative invalid offsets for each time Regards, Ramanand. -----Original Message----- From: Roger Riggs Sent: Saturday, December 12, 2015 1:37 AM To: HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net Cc: HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net Subject: Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition Hi, Stephen, can you? confirm that the added text and test in DateTimeFormatter is not a specification change? Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed. ???? test/java/time/tck/java/time/TCKZonedDateTime.java Ramanand, some comments on the new test: ? - The 'private' qualifier on the tests and data providers is not used in the current tests and ???? is not consistently present in the new one. ???? Since it has little/no function, the tests would be a bit cleaner without it. ? - Typically, test that have data dependencies (such as the timezone data) cannot be used for ???? compatibility to the specification, but the data is stable and it seems unavoidable in this case. ? - Are all of the data cases necessary to validate the specification? ??? Redundant cases extend the testing time without adding more confidence to the quality. Thanks,? Roger ? On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > I believe this is suitable for committing, thanks, other reviews welcome! > Stephen >? >? >? > On 10 December 2015 at 15:36, Ramanand Patil wrote: >> Hi all, >>? >> Please review the updated webrev: >> HYPERLINK "http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.01/"http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >>? >> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug. >>? >> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >>? >>? >> Regards, >> Ramanand. >>? >> -----Original Message----- >> From: Stephen Colebourne [mailto:scolebourne at joda.org] >> Sent: Wednesday, December 09, 2015 4:46 PM >> To: core-libs-dev >> Cc: i18n-dev >> Subject: Re: Review request for JDK-8066982: >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall >> transition >>? >> The logic looks fine. >>? >> In the main code, this part >>??? .getLong(INSTANT_SECONDS); >> can be replaced with >>??? .toEpochSecond(); >> which will be slightly faster. >>? >> In the test case, this part >>?? .plus(15, ChronoUnit.MINUTES); >> can be replaced with >>?? .plusMinutes(15) >>? >> And >>?? .with(ChronoField.OFFSET_SECONDS, >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >> can be replaced with >>?? .with(ZoneOffset.of(offsetSamples[j])) >>? >> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow. >>? >> thanks for fixing this >> Stephen >>? >>? >>? >> On 9 December 2015 at 07:44, Ramanand Patil wrote: >>> HI all, >>>? >>>? >>>? >>> Please review a fix for Bug? - HYPERLINK >>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>>? >>>? >>>? >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded). >>>? >>>? >>>? >>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>>? >>>? >>>? >>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid. >>>? >>>? >>>? >>>? >>>? >>> Regards, >>>? >>> Ramanand. ? ? From Roger.Riggs at Oracle.com Mon Dec 14 16:04:30 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Dec 2015 11:04:30 -0500 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> <96b1ddd9-e543-42e5-8597-9b466225f854@default> <566EDAD9.8090406@Oracle.com> Message-ID: <566EE88E.8010103@Oracle.com> Hi, ok, (I still think of import is for code, not docs, but it makes the {@link}s easier). Roger On 12/14/2015 10:53 AM, Ramanand Patil wrote: > RE: Review request for JDK-8066982: ZonedDateTime.parse() > returns wrong ZoneOffset around DST fall transition > > Hi Roger, > > The added import in DateTimeFormatter.java is because of the javadocs > entry - {@link ChronoLocalDateTime#atZone(ZoneId)} > Regards, > Ramanand. > > *From:*Roger Riggs > *Sent:* Monday, December 14, 2015 8:36 PM > *To:* Ramanand Patil; core-libs-dev at openjdk.java.net > *Cc:* i18n-dev at openjdk.java.net > *Subject:* Re: Review request for JDK-8066982: > ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition > > Hi Ramanand, > > Thanks for the cleanup of the test. > > On 12/14/2015 3:14 AM, Ramanand Patil wrote: > > Hi Roger and all, > > Please review the updated Webrev: > _http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/ > _ > > DateTimeFormatter.java has an added import that is unused and should > be removed. > > Looks fine. > > Thanks, Roger > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066982 > > Roger, please see my comments about new tests: > > - All my test methods were earlier generic with main method and hence > had///private static/qualifier. I have changed them now to match and > to be consistent with the existing tests. Thank you for pointing this. > > - I agree with you on this. Particularly when we have tests around DST > we can?t avoid timezone data. > > - I have defined dataProvider for every method and reduced the test > data for cases where zone is not > present(/testWithoutZoneWithoutOffset()/and///testWithOffsetWithoutZone()/). > > > But for the other 2 cases where zone is > present(/testWithZoneWithOffset()/and///testWithZoneWithoutOffset()/), > I feel most of the data cases are necessary and some are required to > be on safer side if in future the timezone rule changes. Also, this > bug fix mainly affects these cases. > > I have created the dataProvider kepping in mind the below cases for 2 > DST zones. > > 1. Time before overlap > > 2. Time during Overlap > > 3. Time after overlap > > 4. Valid Offsets for each of these times > > 5. Zero Offset for each time > > 6. Few Positive and negative invalid offsets for each time > > Regards, > > Ramanand. > > -----Original Message----- > > From: Roger Riggs > > Sent: Saturday, December 12, 2015 1:37 AM > > To: core-libs-dev at openjdk.java.net > > Cc: i18n-dev at openjdk.java.net > > Subject: Re: Review request for JDK-8066982: > ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition > > Hi, > > Stephen, can you confirm that the added text and test in > DateTimeFormatter is not a specification change? > > Our processes have a bit more to do if it is a spec change and it > would limit the backport to JDK 8. > > This bug fix will cause an existing TCK/JCK test to fail but that is > considered also a bug and is fixed. > > test/java/time/tck/java/time/TCKZonedDateTime.java > > Ramanand, some comments on the new test: > > - The 'private' qualifier on the tests and data providers is not > used in the current tests and > > is not consistently present in the new one. > > Since it has little/no function, the tests would be a bit cleaner > without it. > > - Typically, test that have data dependencies (such as the timezone > > data) cannot be used for > > compatibility to the specification, but the data is stable and it > seems unavoidable in this case. > > - Are all of the data cases necessary to validate the specification? > > Redundant cases extend the testing time without adding more > confidence to the quality. > > Thanks, Roger > > On 12/10/2015 11:00 AM, Stephen Colebourne wrote: > > > I believe this is suitable for committing, thanks, other reviews welcome! > > > Stephen > > > > > > > > > > > > On 10 December 2015 at 15:36, Ramanand Patil > wrote: > > >> Hi all, > > >> > > >> Please review the updated webrev: > > >> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ > > > >> > > >> I have modified the fix and test cases as per inputs given by Stephen. Also, I have > added the javadocs changes in this patch which were proposed in the bug. > > >> > > >> Bug link is: _https://bugs.openjdk.java.net/browse/JDK-8066982_ > > >> > > >> > > >> Regards, > > >> Ramanand. > > >> > > >> -----Original Message----- > > >> From: Stephen Colebourne [_mailto:scolebourne at joda.org_] > > >> Sent: Wednesday, December 09, 2015 4:46 PM > > >> To: core-libs-dev > > >> Cc: i18n-dev > > >> Subject: Re: Review request for JDK-8066982: > > >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall > > >> transition > > >> > > >> The logic looks fine. > > >> > > >> In the main code, this part > > >>.getLong(INSTANT_SECONDS); > > >> can be replaced with > > >>.toEpochSecond(); > > >> which will be slightly faster. > > >> > > >> In the test case, this part > > >> .plus(15, ChronoUnit.MINUTES); > > >> can be replaced with > > >>.plusMinutes(15) > > >> > > >> And > > >>.with(ChronoField.OFFSET_SECONDS, > > >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) > > >> can be replaced with > > >>.with(ZoneOffset.of(offsetSamples[j])) > > >> > > >> In addition to the looping tests, I'd like to see the examples from the bug report > as test cases. Those tests would be simple to follow and explain, > whereas the looping tests are a little hard to follow. > > >> > > >> thanks for fixing this > > >> Stephen > > >> > > >> > > >> > > >> On 9 December 2015 at 07:44, Ramanand Patil > wrote: > > >>> HI all, > > >>> > > >>> > > >>> > > >>> Please review a fix for Bug - HYPERLINK > > >>> "_https://bugs.openjdk.java.net/browse/JDK-8066982_"JDK-8066982 > > >>> > > >>> > > >>> > > >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and > zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different > offset). This error starts exactly at the transition time (included) > and ends one hour later (excluded). > > >>> > > >>> > > >>> > > >>> Webrev - _http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ > _ > > >>> > > >>> > > >>> > > >>> One existing test case in TCKZonedDateTime.java is also modified, because - when > offset is invalid the local time is changed to make the result valid. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Ramanand. > From xueming.shen at oracle.com Mon Dec 14 16:36:42 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 14 Dec 2015 08:36:42 -0800 Subject: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2] In-Reply-To: <566E8821.5010504@oracle.com> References: <5643A368.7010207@oracle.com> <566C6AE5.3040207@oracle.com> <566E8821.5010504@oracle.com> Message-ID: <566EF01A.9010001@oracle.com> On 12/14/15 1:13 AM, Se?n Coffey wrote: > Sherman, > > Changes look fine. One suggestion in ZipFile around line 956. Would > you be better off managing the RandomAccessFile via > try-with-resources. That would clean up your exception handling. Hi Sean, The "zfile" does not need to close if "new RandomAccessFile) throws an exception here. And we need to keep the "zfile" open/alive if everything works well, so it appears the try-with-resourecs does not really help anything here. Thanks, Sherman > Regards, > Sean. > > On 12/12/2015 18:43, Xueming Shen wrote: >> Hi, >> >> The changeset for JDK-8142508 had been backout because it triggers >> jtreg fails in -avm mode >> with testng tests. Here is the updated version that fixes the >> problem. I'm using a different issue >> to trace this update change. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8145260 >> webrev: http://cr.openjdk.java.net/~sherman/8145260/webrev/ >> diff: http://cr.openjdk.java.net/~sherman/8145260/diff (diff to the >> latest 8142508 version) >> >> The root cause/direct trigger that causes the jtreg failure is the >> overlook in the new implementation. >> The flag "locsig" was implemented as >> >> this.locsig = (LOCSIG(buf) != LOCSIG); >> >> while it really should be >> >> this.locsig = (LOCSIG(buf) == LOCSIG); >> >> This is the flag that sun.misc.URLClassPath uses to check if a jar >> file stars with the correct >> LOC (throws away if not) in certain circumstance (security manager + >> !disable_jar_checking). >> >> This has been fixed in the new webrev, and I also renamed the field >> to be more straightforward >> (locsig -> startsWithLoc) >> >> Other than that, there are two small updates >> >> (1) wrap the zip file initialization code with a try{} block and >> close the raw file if any exception >> (2) reorder of "len <=0" check in ZipFileInputStream.read() >> >> All tests seem to pass now. >> >> Thanks, >> Sherman >> >> On 11/11/15 12:22 PM, Xueming Shen wrote: >>> Hi >>> >>> Please help review the changes for JDK-8142508 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 >>> webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev >>> >>> Mainly to address the issues in current j.u.z.ZipFile implementation >>> as listed >>> below >>> >>> (1) The ZIP file format support code is in native C (shared with the >>> VM via >>> ZipFile.c -> zip_util.c). Any entry lookup, creation operation >>> requires multiple >>> round-trips of expensive jni calls. >>> >>> (2) The native C implementation which uses mmap to map in the >>> central directory >>> table appears to be a big risk of vm crash when the underlying >>> jar file gets >>> overwritten with new contents while it is still being used by >>> other ZipFile. The >>> crash reports keep coming in even after we have introduced in >>> system flag >>> to disable it (sun.zip.disableMemoryMapping). >>> >>> (3) The use of "filename + lastModified()" cache (zip_util.c) >>> appears to be broken >>> if the timestamp is in low resolution/precision >>> (File.getModified() for example, >>> might only have "second" ersolution on solaris/linux), and/or >>> the file is being >>> overwritten. >>> >>> The clean solution appears to bring the ZIP format support code >>> completely from >>> native to Java to remove the jni invocation cost and the mmap risk. >>> Also to use >>> the fileKey and lastModified from >>> java.nio.file.attribute.BasicFileAttributes to have >>> better/correct cache matching. >>> >>> Benchmark: >>> >>> This simple jmh measurement suggests a big boost of the performance of >>> ZipFile.getEntry()/entries()/getStream() which are basically entry >>> related >>> accesses (the "open only" has some regression, which is expected as we >>> switched from the mmap to simply read the cen table in into a byte[]) >>> >>> http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java >>> >>> # JDK9 base >>> >>> Benchmark Mode Cnt Score Error Units >>> MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op >>> MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op >>> MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op >>> MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op >>> MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op >>> MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op >>> -------------------------------------------------------------------------------------- >>> >>> # JDK9 ZipFile without jni invocation >>> >>> Benchmark Mode Cnt Score Error Units >>> MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op >>> MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op >>> MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op >>> MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op >>> MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op >>> MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op >>> --------------------------------------------------------------------------------------- >>> >>> >>> Test: >>> http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html >>> >>> >>> Verified the new ZipFile runs as expected when the underlying >>> jar/zip file get >>> deleted/overwritten when the zip still be used. The "old" ZipFile >>> fails to continue >>> to work but no crash, and the "new" one works correctly on updated >>> zip file >>> without problem (The test runs a little long, have not decided if it >>> should be >>> checked in as unit test). >>> >>> -Sherman >>> >> > From sean.coffey at oracle.com Mon Dec 14 16:40:45 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 14 Dec 2015 16:40:45 +0000 Subject: RFR: JDK-8145260: To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2] In-Reply-To: <566EF01A.9010001@oracle.com> References: <5643A368.7010207@oracle.com> <566C6AE5.3040207@oracle.com> <566E8821.5010504@oracle.com> <566EF01A.9010001@oracle.com> Message-ID: <566EF10D.2050604@oracle.com> Ah - of course. That comment would been lack of coffee syndrome on my behalf earlier this morning then ;) Regards, Sean. On 14/12/15 16:36, Xueming Shen wrote: > On 12/14/15 1:13 AM, Se?n Coffey wrote: >> Sherman, >> >> Changes look fine. One suggestion in ZipFile around line 956. Would >> you be better off managing the RandomAccessFile via >> try-with-resources. That would clean up your exception handling. > Hi Sean, > > The "zfile" does not need to close if "new RandomAccessFile) throws > an exception here. > And we need to keep the "zfile" open/alive if everything works well, > so it appears the > try-with-resourecs does not really help anything here. > > Thanks, > Sherman > >> Regards, >> Sean. >> >> On 12/12/2015 18:43, Xueming Shen wrote: >>> Hi, >>> >>> The changeset for JDK-8142508 had been backout because it triggers >>> jtreg fails in -avm mode >>> with testng tests. Here is the updated version that fixes the >>> problem. I'm using a different issue >>> to trace this update change. >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8145260 >>> webrev: http://cr.openjdk.java.net/~sherman/8145260/webrev/ >>> diff: http://cr.openjdk.java.net/~sherman/8145260/diff (diff to the >>> latest 8142508 version) >>> >>> The root cause/direct trigger that causes the jtreg failure is the >>> overlook in the new implementation. >>> The flag "locsig" was implemented as >>> >>> this.locsig = (LOCSIG(buf) != LOCSIG); >>> >>> while it really should be >>> >>> this.locsig = (LOCSIG(buf) == LOCSIG); >>> >>> This is the flag that sun.misc.URLClassPath uses to check if a jar >>> file stars with the correct >>> LOC (throws away if not) in certain circumstance (security manager + >>> !disable_jar_checking). >>> >>> This has been fixed in the new webrev, and I also renamed the field >>> to be more straightforward >>> (locsig -> startsWithLoc) >>> >>> Other than that, there are two small updates >>> >>> (1) wrap the zip file initialization code with a try{} block and >>> close the raw file if any exception >>> (2) reorder of "len <=0" check in ZipFileInputStream.read() >>> >>> All tests seem to pass now. >>> >>> Thanks, >>> Sherman >>> >>> On 11/11/15 12:22 PM, Xueming Shen wrote: >>>> Hi >>>> >>>> Please help review the changes for JDK-8142508 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8142508 >>>> webrev: http://cr.openjdk.java.net/~sherman/8142508/webrev >>>> >>>> Mainly to address the issues in current j.u.z.ZipFile >>>> implementation as listed >>>> below >>>> >>>> (1) The ZIP file format support code is in native C (shared with >>>> the VM via >>>> ZipFile.c -> zip_util.c). Any entry lookup, creation operation >>>> requires multiple >>>> round-trips of expensive jni calls. >>>> >>>> (2) The native C implementation which uses mmap to map in the >>>> central directory >>>> table appears to be a big risk of vm crash when the underlying >>>> jar file gets >>>> overwritten with new contents while it is still being used by >>>> other ZipFile. The >>>> crash reports keep coming in even after we have introduced in >>>> system flag >>>> to disable it (sun.zip.disableMemoryMapping). >>>> >>>> (3) The use of "filename + lastModified()" cache (zip_util.c) >>>> appears to be broken >>>> if the timestamp is in low resolution/precision >>>> (File.getModified() for example, >>>> might only have "second" ersolution on solaris/linux), and/or >>>> the file is being >>>> overwritten. >>>> >>>> The clean solution appears to bring the ZIP format support code >>>> completely from >>>> native to Java to remove the jni invocation cost and the mmap risk. >>>> Also to use >>>> the fileKey and lastModified from >>>> java.nio.file.attribute.BasicFileAttributes to have >>>> better/correct cache matching. >>>> >>>> Benchmark: >>>> >>>> This simple jmh measurement suggests a big boost of the performance of >>>> ZipFile.getEntry()/entries()/getStream() which are basically entry >>>> related >>>> accesses (the "open only" has some regression, which is expected as we >>>> switched from the mmap to simply read the cen table in into a byte[]) >>>> >>>> http://cr.openjdk.java.net/~sherman/8142508/MyBenchmark.java >>>> >>>> # JDK9 base >>>> >>>> Benchmark Mode Cnt Score Error Units >>>> MyBenchmark.testEntries avgt 50 13.671 ? 0.385 ms/op >>>> MyBenchmark.testGetEntry avgt 50 17.414 ? 0.803 ms/op >>>> MyBenchmark.testGetStream avgt 50 42.398 ? 10.136 ms/op >>>> MyBenchmark.testOpen avgt 50 3.049 ? 0.094 ms/op >>>> MyBenchmark.testRead avgt 50 215.179 ? 9.926 ms/op >>>> MyBenchmark.testReadAll avgt 50 244.422 ? 19.375 ms/op >>>> -------------------------------------------------------------------------------------- >>>> >>>> # JDK9 ZipFile without jni invocation >>>> >>>> Benchmark Mode Cnt Score Error Units >>>> MyBenchmark.testEntries avgt 50 6.436 ? 0.422 ms/op >>>> MyBenchmark.testGetEntry avgt 50 10.021 ? 0.699 ms/op >>>> MyBenchmark.testGetStream avgt 50 38.713 ? 16.687 ms/op >>>> MyBenchmark.testOpen avgt 50 3.288 ? 0.119 ms/op >>>> MyBenchmark.testRead avgt 50 220.653 ? 8.529 ms/op >>>> MyBenchmark.testReadAll avgt 50 249.798 ? 18.438 ms/op >>>> --------------------------------------------------------------------------------------- >>>> >>>> >>>> Test: >>>> http://cr.openjdk.java.net/~sherman/8142508/webrev/test/java/util/zip/ZipFile/TestZipFile.java.html >>>> >>>> >>>> Verified the new ZipFile runs as expected when the underlying >>>> jar/zip file get >>>> deleted/overwritten when the zip still be used. The "old" ZipFile >>>> fails to continue >>>> to work but no crash, and the "new" one works correctly on updated >>>> zip file >>>> without problem (The test runs a little long, have not decided if >>>> it should be >>>> checked in as unit test). >>>> >>>> -Sherman >>>> >>> >> > From joe.darcy at oracle.com Mon Dec 14 19:45:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 14 Dec 2015 11:45:54 -0800 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> <5669EC2A.1030308@oracle.com> Message-ID: <566F1C72.7010001@oracle.com> Hi Joel, Revised ccc request finalized for current version of the spec; should be approved in a day or two. Once that is approved, I think the current version can be pushed, enabling the refactorings you've alluded to to occur later. Thanks, -Joe On 12/13/2015 12:26 PM, Joel Borggr?n-Franck wrote: > Hi Joe, > > Thanks for the comments, > > On Thu, 10 Dec 2015 at 22:18 joe darcy > wrote: > > Hi Joel, > > On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: >> Question, is it better to remove the throws clauses for the cases >> that return null? > > I think so; they aren't applicable in those case and it is fine to > remove exceptions in subtypes of course. > > > Done. > > Please also add @Override annotations to the methods in the > subtypes as a check that a new method is not accidentally being > declared. > > > Doh! Fixed. > >> >> New webrev: >> http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ >> >> Diff of patch 01 and patch 02 (a diff-diff): >> http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch >> >> >> > > Please add an @implSpec note in AnnotatedType saying that "this > implementation returns null", or words to that effect. > > > Done. > > Shouldn't some of the implementation overrides in > AnnotatedTypeFactory.java which throw null now be removed? Ah, I > see the BaseImpl type is in the way. Is there an easy way to > refactor that? > > > I think it deserves a separate commit. I have another bugfix lined up, > then I plan to refactor refactor the code a bit and clean up and > improve testing. > > (I'll take care of the ccc changes once the new spec is finalized.) > > > Thanks! > > New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.03/ > > Delta vs 01: > http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v3.patch > > > cheers > /Joel From david.holmes at oracle.com Mon Dec 14 20:47:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 06:47:54 +1000 Subject: Need help to understand TLS behavior In-Reply-To: <566EBEC0.1000609@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> Message-ID: <566F2AFA.3000805@oracle.com> On 14/12/2015 11:06 PM, cheleswer sahu wrote: > Hi David, > TLS is thread local storage. In test program it is defined using > > #define TLS_SIZE 32 > int __thread XYZ[TLS_SIZE * 1024]; Thanks for clarifying. What test is that? I'm guessing this may be a linux only test? Which platform do you see the problem on? We don't unconditionally use compiler-based TLS as some platforms may not support it. That aside that declaration should really be static I think. David ----- > Regards, > Cheleswer > On 12/14/2015 6:29 PM, David Holmes wrote: >> What is TLS in this context? >> >> Thanks, >> David >> >> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >>> Hi, >>> >>> I am investigating an issue, in which test with TLS size set to 32K is >>> failing with StackOverFlowError. During investigation I found the below >>> code >>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >>> >>> >>> >>> ThreadFactory threadFactory = grimReaper -> { >>> // Our thread stack requirement is quite modest. >>> Thread t = new Thread(systemThreadGroup, grimReaper, >>> "process reaper", 32768); >>> >>> Here reaper thread is created with fixed stack size "32768 ", which >>> causes StackOverFlowError when TLS is set to 32k around. >>> If I remove this fixed size and make it default, test works fine. >>> >>> Thread t = new Thread(systemThreadGroup, grimReaper, >>> "process reaper"); >>> >>> I have run several test with TLS size 32k , 64k ,128k and more . >>> The interesting part, it works well with 64k and 128k TLS size but not >>> with 32k. >>> So my questions are as follows: >>>> What is the motivation behind the fixed thread stack size ? >>>> will it be ok to replace the fixed stack size with default or stack >>> size setting is platform sensitive? >>>> How TLS sizes are interpreted internally, which allows 64k and 128k >>> to work but not to 32k ? >>> >>> I would really appreciate, if anyone have any opinion on this. >>> >>> Regards, >>> Cheleswer >>> >>> >>> > From ecki at zusammenkunft.net Mon Dec 14 20:52:39 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 14 Dec 2015 21:52:39 +0100 Subject: Need help to understand TLS behavior In-Reply-To: <566ECF1B.80406@Oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566ECF1B.80406@Oracle.com> Message-ID: <20151214215239.0000571c.ecki@zusammenkunft.net> Am Mon, 14 Dec 2015 09:15:55 -0500 schrieb Roger Riggs : > Hi, > > The reaper thread that waits for process exit has minimal stack > requirements, > and if possible should not consume all of the memory for a full stack. > The 32k number is a guess at a small stack. It has worked so far > except in cases > where the VM configuration or parameters increase the size of stack > the VM needs. Maybe it can benefit from the new "No Inherit TLS" Thread constructor? (However I wonder how two references in the thread object would overflow the stack...) Gruss Bernd From martinrb at google.com Mon Dec 14 20:53:15 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Dec 2015 12:53:15 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <566F2AFA.3000805@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> Message-ID: Thread local storage is trouble. java stack sizes should be in _addition_ to any OS overhead, which includes TLS. IOW, the java thread stack size should actually be available for stack frames. Hotspot should be fixed, but it's not easy. On Mon, Dec 14, 2015 at 12:47 PM, David Holmes wrote: > On 14/12/2015 11:06 PM, cheleswer sahu wrote: >> >> Hi David, >> TLS is thread local storage. In test program it is defined using >> >> #define TLS_SIZE 32 >> int __thread XYZ[TLS_SIZE * 1024]; > > > Thanks for clarifying. What test is that? I'm guessing this may be a linux > only test? Which platform do you see the problem on? > > We don't unconditionally use compiler-based TLS as some platforms may not > support it. > > That aside that declaration should really be static I think. > > David > ----- > > >> Regards, >> Cheleswer >> On 12/14/2015 6:29 PM, David Holmes wrote: >>> >>> What is TLS in this context? >>> >>> Thanks, >>> David >>> >>> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >>>> >>>> Hi, >>>> >>>> I am investigating an issue, in which test with TLS size set to 32K is >>>> failing with StackOverFlowError. During investigation I found the below >>>> code >>>> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >>>> >>>> >>>> >>>> ThreadFactory threadFactory = grimReaper -> { >>>> // Our thread stack requirement is quite modest. >>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>> "process reaper", 32768); >>>> >>>> Here reaper thread is created with fixed stack size "32768 ", which >>>> causes StackOverFlowError when TLS is set to 32k around. >>>> If I remove this fixed size and make it default, test works fine. >>>> >>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>> "process reaper"); >>>> >>>> I have run several test with TLS size 32k , 64k ,128k and more . >>>> The interesting part, it works well with 64k and 128k TLS size but not >>>> with 32k. >>>> So my questions are as follows: >>>>> >>>>> What is the motivation behind the fixed thread stack size ? >>>>> will it be ok to replace the fixed stack size with default or stack >>>> >>>> size setting is platform sensitive? >>>>> >>>>> How TLS sizes are interpreted internally, which allows 64k and 128k >>>> >>>> to work but not to 32k ? >>>> >>>> I would really appreciate, if anyone have any opinion on this. >>>> >>>> Regards, >>>> Cheleswer >>>> >>>> >>>> >> > From stuart.marks at oracle.com Mon Dec 14 21:53:25 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 14 Dec 2015 13:53:25 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups In-Reply-To: References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> <5669FF22.6010705@oracle.com> <566B2DBC.4030305@oracle.com> Message-ID: <566F3A55.8020309@oracle.com> On 12/11/15 12:23 PM, Martin Buchholz wrote: > I added Iterator and Comparator to "my" list of tests. Thanks! > > The key difference is that we don't try to separate concurrent and > non-concurrent collections, so my "collections test set" includes all > of /java/util/concurrent even though it's technically overkill. But > we've optimized those tests so they run much more quickly now! > > So I encourage you to also make jdk_concurrent a subset of > jdk_collections if that's compatible with the makefile conventions. OK, how about this then? * jdk_collections = jdk_collections_core + jdk_concurrent * jdk_collections_core = ("classic" collections framework classes, without j.u.c.) * jdk_concurrent = (same as it ever was) Diffs below. s'marks # HG changeset patch # User smarks # Date 1449887489 28800 # Fri Dec 11 18:31:29 2015 -0800 # Node ID e96855cde1677ffa0c681e1496d628afcd15037f # Parent 83e427bf6451d5145f58ba7654d586232d0c91be 8145139: clean up jdk_collections and jdk_concurrent test groups Reviewed-by: XXX diff -r 83e427bf6451 -r e96855cde167 test/TEST.groups --- a/test/TEST.groups Fri Dec 11 17:01:01 2015 -0800 +++ b/test/TEST.groups Fri Dec 11 18:31:29 2015 -0800 @@ -95,16 +95,18 @@ -:jdk_concurrent \ -:jdk_stream -# java.util.concurrent (JSR-166) -# Maintained by JSR-166 EG (Doug Lea et al) -# Deque and PriorityQueue are also generally maintained by JSR-166 +jdk_collections = \ + :jdk_collections_core \ + :jdk_concurrent + +# java.util.concurrent +# Includes concurrent collections and other stuff. +# Maintained by JSR-166 EG (Doug Lea et al). jdk_concurrent = \ - java/util/concurrent \ - java/util/Deque \ - java/util/PriorityQueue + java/util/concurrent -# Java Collections Framework -jdk_collections = \ +# Java Collections Framework core classes. +jdk_collections_core = \ java/util/AbstractCollection \ java/util/AbstractList \ java/util/AbstractMap \ @@ -114,19 +116,22 @@ java/util/BitSet \ java/util/Collection \ java/util/Collections \ + java/util/Comparator \ + java/util/Deque \ java/util/EnumMap \ java/util/EnumSet \ - java/util/Comparator \ - java/util/Iterator \ java/util/HashMap \ + java/util/HashSet \ java/util/Hashtable \ java/util/IdentityHashMap \ - java/util/List \ + java/util/Iterator \ java/util/LinkedHashMap \ java/util/LinkedHashSet \ java/util/LinkedList \ + java/util/List \ java/util/Map \ java/util/NavigableMap \ + java/util/PriorityQueue \ java/util/TimSort \ java/util/TreeMap \ java/util/Vector \ From dbrosius at baybroadband.net Sat Dec 12 05:10:28 2015 From: dbrosius at baybroadband.net (Dave Brosius) Date: Sat, 12 Dec 2015 00:10:28 -0500 Subject: ExceptionTable addition? Message-ID: <566BAC44.1070300@baybroadband.net> Greetings, From a byte code analysis--toolsy point of view, it would be nice if you could deterministically find the end of a catch/finally block. Unfortunately, the ExceptionTable attribute only lists the starts of trys/catches/finallys. Now obviously, there are times when you can determine the end of the catch/finally block: If for instance a try block exits normally, javac, will insert a GOTO, from which you can clean the 'continuation' PC. You can also determine the end of a catch block if it is followed by another catch or finally block. However, there are pretty regular cases where you cannot, for instance if a try block ends with a return or a throw, and there is only one catch block or finally block, or those catch blocks that exist (before the last one) also return or throw. String someMethod() { try { return getSomething(); } catch (IOException e) { LOGGER.log("Oops"); } return doSomeMoreStuff(); } In this scenario, there's no way to know if the 'doSomeMoreStuff() is in the catch block or not. Now from a program execution point of view, it doesn't really matter. You can consider everything below the catch, (or finally) block to be part of that catch (or finally) block. But there are cases, where for code analysis, you would really like to know. --- It would be really nice if the ExceptionTable also listed a 'continuation pc'. From goetz.lindenmaier at sap.com Mon Dec 14 13:59:31 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 13:59:31 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <566EC2DD.5000404@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> Hi Frederic, I'm now again working on my change "8139864: Improve handling of stack protection zones." Coleen had asked me to wait until this change of yours is submitted. You changed the stack_yellow_zone accessor functions in thread.hpp to handle both zones, yellow and reserved. Therefore, reading the code, the reserved zone seems to be part of the yellow zone. In the description of the bug, it says "The new zone defined by the proposed solution is placed just before the yellow zone." This reads as if the zones are separate. Would you mind if I rename the stack_yellow_zone accessor functions to stack_yellow_reserved_zone? This would make clear in the code that this are two separate zones. I anyways have to adapt most of the calls to these accessors. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Frederic Parain > Sent: Montag, 14. Dezember 2015 14:24 > To: Karen Kinnear > Cc: hotspot-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net> > Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical > Sections > > Karen, > > Thank you for your review. > > Fred > > On 23/11/2015 20:10, Karen Kinnear wrote: > > Frederic, > > > > Looks good. > > > > Many thanks. > > Karen > > > >> On Nov 23, 2015, at 12:44 PM, Frederic Parain > >> > > wrote: > >> > >> Karen, > >> > >> Thank you for your review, my answers are in-lined below. > >> > >> New Webrevs (including some fixes suggested by Paul Sandoz): > >> > >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ > >> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ > >> > >> On 20/11/2015 19:44, Karen Kinnear wrote: > >>> Frederic, > >>> > >>> Code review for web revs you sent out. > >>> Code looks good. I am not as familiar with the compiler code. > >>> > >>> I realize you need to check in at least a subset of the > >>> java.util.concurrent changes for > >>> the test to work, so maybe I should not have asked Doug about his > >>> preference there. > >>> Sorry. > >>> > >>> I am impressed you found a way to make a reproducible test! > >>> > >>> Comments/questions: > >>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? > >> > >> Fixed > >> > >>> 2. IIRC, due to another bug with windows handling of our guard pages, > >>> this > >>> is disabled for Windows. Would it be worth putting a comment in the > >>> bug , 8067946, that once this is fixed, the reserved stack logic on > >>> windows > >>> will need testing before enabling? > >> > >> More than testing, the implementation would have to be completed on > >> Windows. I've added a comment to JDK-8067946. > >> > >>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if > >>> this is in interpreter code, you explicitly return the Java sender > >>> of the current frame. I was expecting to see that on Solaris_sparc > >>> and Windows > >>> as well? I do see the assertion in caller that you do have a java frame. > >> > >> It doesn't make sense to check the current frame (no bytecode has been > >> executed yet, so risk of partially executed critical section). I did the > >> change but not for all platforms. This is now fixed for Solaris_SPARC > >> and Windows too. > >> > >>> 4. test line 83 ?writtent? -> ?written? > >> > >> Fixed > >> > >>> 5. I like the way you set up the preallocated exception and then set > >>> the message - we may > >>> try that for default methods in future. > >>> > >>> 6. I had a memory that you had found a bug in safe_for_sender - did > >>> you already check that in? > >> > >> I've fixed x86 platforms in JDK-8068655. > >> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), > >> I had hoped it would have been silently accepted :-) > >> > >> > >>> 7. I see the change in trace.xml, and I see an include added to > >>> SharedRuntime.cpp, > >>> but I didn?t see where it was used - did I just miss it? > >> > >> trace.xml changes define a new event. > >> This event is created at sharedRuntime.cpp::3006 and it is used > >> in the next 3 lines. > > Thanks. I must have mistyped when I searched for it. > >> > >> Thanks, > >> > >> Fred > >> > >> -- > >> Frederic Parain - Oracle > >> Grenoble Engineering Center - France > >> Phone: +33 4 76 18 81 17 > >> Email:Frederic.Parain at oracle.com > > > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From goetz.lindenmaier at sap.com Mon Dec 14 15:11:38 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Dec 2015 15:11:38 +0000 Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections In-Reply-To: <566ED5C9.60108@oracle.com> References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com> <563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com> <56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com> <564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com> <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com> <56535077.9090605@oracle.com> <566EC2DD.5000404@oracle.com> <4295855A5C1DE049A61835A1887419CC41EDE813@DEWDFEMB12A.global.corp.sap> <566ED5C9.60108@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EDE889@DEWDFEMB12A.global.corp.sap> Hi Frederic, thanks for your fast reply. From reading the code I guessed about what you explained, now I understood more details, thanks! I will not fiddle with handling the zones. My change is only about handling larger pages, i.e. the sizes of the zones, so there is no danger I will break the mechanism you implemented. > The take over is that the VM code should be able to manage > the reserved zone alone or the reserved zone and the yellow > zone together. > If you want to change it for a better name, more explicit, > I'm fine with that. Yes, I would like to change it to 'yellow_reserved' wherever both are handled at the same time. There's places where red+yellow+reserved are handled as one, here I will use 'guard_zone'. That's aliged with create_stack_guard_pages() which guards all (red, yellow, reserved) of them. > stack_yellow_zone_enabled() -> stack_guards_enabled() > > Here, "guards" refers to the two guard zones: reserved > + yellow. Actually, it also includes that the red page is enabled, right? One question, in os_linux.cpp, you meant AMD64, not Itanium, right? 27.18+#if defined(IA32) || defined(IA64) I'll move that functionality to another place, so no need to fix it. Best regards, Goetz. > -----Original Message----- > From: Frederic Parain [mailto:frederic.parain at oracle.com] > Sent: Montag, 14. Dezember 2015 15:44 > To: Lindenmaier, Goetz ; Karen Kinnear > > Cc: hotspot-dev at openjdk.java.net; core-libs-dev dev at openjdk.java.net> > Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical > Sections > > Goetz, > > The reserved zone is sometime considered as a subpart of > the yellow zone, and sometime as an independent entity. > Technically the reserved zone is placed just before the > yellow zone, but the way it is managed depends on the > context. > > In most cases, there's no specially annotated methods on > the thread's call stack. In this configuration the > reserved zone is considered as being part of the yellow > zone. This means that the protection of the reserved > zone is always the same as the protection of the yellow > zone. > > In some cases, a thread could have one or more methods > on its call stack with the ReservedStackAccess annotation. > In this configuration, the reserved zone is managed as > a separate entity. Initially protected like the yellow > zone, access to the reserved zone can be temporary granted > for the execution of some critical sections. This means > that the protection of the reserved zone can be removed > while the yellow zone is still protected. > > The take over is that the VM code should be able to manage > the reserved zone alone or the reserved zone and the yellow > zone together. I've already renamed a method because of > this change: > stack_yellow_zone_enabled() -> stack_guards_enabled() > > Here, "guards" refers to the two guard zones: reserved > + yellow. > > If you want to change it for a better name, more explicit, > I'm fine with that. We just have to preserve the different > operations required for stack overflow management. > > Let's say R(x) and Y(x) represent the protection of > the reserved zone and the yellow zone respectively. > And let's say that x = P means "zone protected" > and x = G means "access granted" > > The different configurations are: > > (1) R(P) Y(P) => initial configuration > (2) R(G) Y(P) => first stack overflow with annotated > method on stack > (3) R(G) Y(G) => stack overflow without annotated > method on stack, or second stack > overflow with annotated method > on stack > > And the transitions are: > > (1) -> (3) -> (1) > or > (1) -> (2) -> (1) > or > (1) -> (2) -> (3) -> (1) > > I hope this would clarify the semantic of the reserved zone. > If it doesn't, let me know, I'll try to explain it differently. > > Thanks, > > Fred > > On 14/12/2015 14:59, Lindenmaier, Goetz wrote: > > Hi Frederic, > > > > I'm now again working on my change "8139864: Improve handling of stack > protection zones." > > Coleen had asked me to wait until this change of yours is submitted. > > > > You changed the stack_yellow_zone accessor functions in thread.hpp to > > handle both zones, yellow and reserved. > > Therefore, reading the code, the reserved zone seems to be part of the > yellow zone. > > > > In the description of the bug, it says "The new zone defined by the > proposed > > solution is placed just before the yellow zone." This reads as if the zones > are > > separate. > > > > Would you mind if I rename the stack_yellow_zone accessor functions to > > stack_yellow_reserved_zone? This would make clear in the code that this > > are two separate zones. > > > > I anyways have to adapt most of the calls to these accessors. > > > > Best regards, > > Goetz. > > > > > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Frederic Parain > >> Sent: Montag, 14. Dezember 2015 14:24 > >> To: Karen Kinnear > >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev >> dev at openjdk.java.net> > >> Subject: Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for > Critical > >> Sections > >> > >> Karen, > >> > >> Thank you for your review. > >> > >> Fred > >> > >> On 23/11/2015 20:10, Karen Kinnear wrote: > >>> Frederic, > >>> > >>> Looks good. > >>> > >>> Many thanks. > >>> Karen > >>> > >>>> On Nov 23, 2015, at 12:44 PM, Frederic Parain > >>>> > > >> wrote: > >>>> > >>>> Karen, > >>>> > >>>> Thank you for your review, my answers are in-lined below. > >>>> > >>>> New Webrevs (including some fixes suggested by Paul Sandoz): > >>>> > >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ > >>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ > >>>> > >>>> On 20/11/2015 19:44, Karen Kinnear wrote: > >>>>> Frederic, > >>>>> > >>>>> Code review for web revs you sent out. > >>>>> Code looks good. I am not as familiar with the compiler code. > >>>>> > >>>>> I realize you need to check in at least a subset of the > >>>>> java.util.concurrent changes for > >>>>> the test to work, so maybe I should not have asked Doug about his > >>>>> preference there. > >>>>> Sorry. > >>>>> > >>>>> I am impressed you found a way to make a reproducible test! > >>>>> > >>>>> Comments/questions: > >>>>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if? > >>>> > >>>> Fixed > >>>> > >>>>> 2. IIRC, due to another bug with windows handling of our guard pages, > >>>>> this > >>>>> is disabled for Windows. Would it be worth putting a comment in the > >>>>> bug , 8067946, that once this is fixed, the reserved stack logic on > >>>>> windows > >>>>> will need testing before enabling? > >>>> > >>>> More than testing, the implementation would have to be completed > on > >>>> Windows. I've added a comment to JDK-8067946. > >>>> > >>>>> 3. In get_frame_at_stack_banging_point on Linux, BSD and > solaris_x86 if > >>>>> this is in interpreter code, you explicitly return the Java sender > >>>>> of the current frame. I was expecting to see that on Solaris_sparc > >>>>> and Windows > >>>>> as well? I do see the assertion in caller that you do have a java frame. > >>>> > >>>> It doesn't make sense to check the current frame (no bytecode has > been > >>>> executed yet, so risk of partially executed critical section). I did the > >>>> change but not for all platforms. This is now fixed for Solaris_SPARC > >>>> and Windows too. > >>>> > >>>>> 4. test line 83 ?writtent? -> ?written? > >>>> > >>>> Fixed > >>>> > >>>>> 5. I like the way you set up the preallocated exception and then set > >>>>> the message - we may > >>>>> try that for default methods in future. > >>>>> > >>>>> 6. I had a memory that you had found a bug in safe_for_sender - did > >>>>> you already check that in? > >>>> > >>>> I've fixed x86 platforms in JDK-8068655. > >>>> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635), > >>>> I had hoped it would have been silently accepted :-) > >>>> > >>>> > >>>>> 7. I see the change in trace.xml, and I see an include added to > >>>>> SharedRuntime.cpp, > >>>>> but I didn?t see where it was used - did I just miss it? > >>>> > >>>> trace.xml changes define a new event. > >>>> This event is created at sharedRuntime.cpp::3006 and it is used > >>>> in the next 3 lines. > >>> Thanks. I must have mistyped when I searched for it. > >>>> > >>>> Thanks, > >>>> > >>>> Fred > >>>> > >>>> -- > >>>> Frederic Parain - Oracle > >>>> Grenoble Engineering Center - France > >>>> Phone: +33 4 76 18 81 17 > >>>> Email:Frederic.Parain at oracle.com > > >>> > >> > >> -- > >> Frederic Parain - Oracle > >> Grenoble Engineering Center - France > >> Phone: +33 4 76 18 81 17 > >> Email: Frederic.Parain at oracle.com > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From Roger.Riggs at Oracle.com Mon Dec 14 22:05:34 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Dec 2015 17:05:34 -0500 Subject: Producing streams in java.time? In-Reply-To: <851620702.20151210223156@gmail.com> References: <851620702.20151210223156@gmail.com> Message-ID: <566F3D2E.2010900@Oracle.com> Hi Tagir, What are the use cases? Does it need to be more convenient? It seems relatively easy to do in application code. Could there be a more general form that would be as useful but add fewer methods? Roger On 12/10/2015 11:31 AM, Tagir F. Valeev wrote: > Hello! > > Currently it seems that java.time package does not use Stream API in > any way. I think it would be nice to add some methods which produce > the streams. For example: > > - in class Year: > > // Returns sequential ordered stream of all months within this Year: > Stream months(); > // Returns sequential ordered stream of all days within this Year: > Stream days(); > // Returns sequential ordered stream of all years starting from this > // Year until the supplied year, exclusive > Stream yearsUntil(Temporal endExclusive); > > - in class YearMonth: > > // Returns sequential ordered stream of all days within this YearMonth: > Stream days(); > // Returns sequential ordered stream of all months starting from this > // YearMonth until the supplied YearMonth, exclusive > Stream monthsUntil(Temporal endExclusive); > > - in class LocalDate: > > // Returns sequential ordered stream of all months starting from this > // LocalDate until the supplied LocalDate, exclusive > Stream daysUntil(Temporal endExclusive); > > The implementation of these methods could be quite simple. For example: > > class Year { > public Stream days() { > return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); > } > } > > What do you think? > > With best regards, > Tagir Valeev. > From Roger.Riggs at Oracle.com Mon Dec 14 22:38:14 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 14 Dec 2015 17:38:14 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5668759A.1070204@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> Message-ID: <566F44D6.7020503@Oracle.com> Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and others should stick to the static nested class. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Thanks, Roger p.s. last call for comments From kim.barrett at oracle.com Mon Dec 14 22:49:37 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 17:49:37 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566F44D6.7020503@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566F44D6.7! 020503@Oracle.com> Message-ID: <080FBEF6-8CC8-49C8-83CF-0631BE265285@oracle.com> On Dec 14, 2015, at 5:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain in depth > in the context of an example. A more conservative approach is to show using a static nested > class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and others > should stick to the static nested class. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Thanks, Roger > > p.s. last call for comments A few editorial nits: ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 72 * The cleaning function is invoked after the object it is cleaning up after it 73 * becomes phantom reachable, so it is important that the references and values "after it becomes" => ?after becomes? or maybe instead something like "after the object it is cleaning up after it" => "after the associated object" ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 74 * it needs do not prevent the object from becoming phantom reachable. Perhaps "it needs" => "the cleaning function needs". ------------------------------------------------------------------------------ src/java.base/share/classes/java/lang/ref/Cleaner.java 116 * the object reference, by referring to fields of the objecting being cleaned, "objecting" => "object" ------------------------------------------------------------------------------ From martinrb at google.com Tue Dec 15 00:26:51 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Dec 2015 16:26:51 -0800 Subject: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups In-Reply-To: <566F3A55.8020309@oracle.com> References: <5668D9B4.5040408@oracle.com> <5669F93E.4090609@oracle.com> <5669FF22.6010705@oracle.com> <566B2DBC.4030305@oracle.com> <566F3A55.8020309@oracle.com> Message-ID: It's a winner! On Mon, Dec 14, 2015 at 1:53 PM, Stuart Marks wrote: > > > On 12/11/15 12:23 PM, Martin Buchholz wrote: >> >> I added Iterator and Comparator to "my" list of tests. Thanks! >> >> The key difference is that we don't try to separate concurrent and >> non-concurrent collections, so my "collections test set" includes all >> of /java/util/concurrent even though it's technically overkill. But >> we've optimized those tests so they run much more quickly now! >> >> So I encourage you to also make jdk_concurrent a subset of >> jdk_collections if that's compatible with the makefile conventions. > > > OK, how about this then? > > * jdk_collections = jdk_collections_core + jdk_concurrent > > * jdk_collections_core = ("classic" collections framework classes, without > j.u.c.) > > * jdk_concurrent = (same as it ever was) > > Diffs below. > > s'marks > > > > # HG changeset patch > # User smarks > # Date 1449887489 28800 > # Fri Dec 11 18:31:29 2015 -0800 > # Node ID e96855cde1677ffa0c681e1496d628afcd15037f > # Parent 83e427bf6451d5145f58ba7654d586232d0c91be > 8145139: clean up jdk_collections and jdk_concurrent test groups > Reviewed-by: XXX > > diff -r 83e427bf6451 -r e96855cde167 test/TEST.groups > --- a/test/TEST.groups Fri Dec 11 17:01:01 2015 -0800 > +++ b/test/TEST.groups Fri Dec 11 18:31:29 2015 -0800 > @@ -95,16 +95,18 @@ > -:jdk_concurrent \ > -:jdk_stream > > -# java.util.concurrent (JSR-166) > -# Maintained by JSR-166 EG (Doug Lea et al) > -# Deque and PriorityQueue are also generally maintained by JSR-166 > +jdk_collections = \ > + :jdk_collections_core \ > + :jdk_concurrent > + > +# java.util.concurrent > +# Includes concurrent collections and other stuff. > +# Maintained by JSR-166 EG (Doug Lea et al). > jdk_concurrent = \ > - java/util/concurrent \ > - java/util/Deque \ > - java/util/PriorityQueue > + java/util/concurrent > > -# Java Collections Framework > -jdk_collections = \ > +# Java Collections Framework core classes. > +jdk_collections_core = \ > java/util/AbstractCollection \ > java/util/AbstractList \ > java/util/AbstractMap \ > @@ -114,19 +116,22 @@ > > java/util/BitSet \ > java/util/Collection \ > java/util/Collections \ > + java/util/Comparator \ > + java/util/Deque \ > java/util/EnumMap \ > java/util/EnumSet \ > - java/util/Comparator \ > - java/util/Iterator \ > java/util/HashMap \ > + java/util/HashSet \ > java/util/Hashtable \ > java/util/IdentityHashMap \ > - java/util/List \ > + java/util/Iterator \ > java/util/LinkedHashMap \ > java/util/LinkedHashSet \ > java/util/LinkedList \ > + java/util/List \ > java/util/Map \ > java/util/NavigableMap \ > + java/util/PriorityQueue \ > java/util/TimSort \ > java/util/TreeMap \ > java/util/Vector \ > > From mandy.chung at oracle.com Tue Dec 15 00:48:17 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Dec 2015 16:48:17 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566F44D6.7020503@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566F44D6.7! 020503@Oracle.com> Message-ID: > On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: > > Hi, > > The complexity of using Lambda for cleaning functions are too hard to explain in depth > in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and other should stick to the static nested class. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Looks okay in general. When we convert existing use of finalizers in the JDK to Cleaner, that would give good feedback to this API. As the api note, it would be better if the CleaningExample shows the real cleaning work. It?s okay with me if you want to file a JBS issue and do that later if you want to build up some examples when converting existing use to Cleaner. Editorial comments. 186 * @exception IllegalThreadStateException if the thread from the thread 187 * factory was {@link Thread.State#NEW not a new thread}. s/@exception/@throws/ s/ {@link Thread.State#NEW not a new thread}/not a {@link Thread.State#NEW new thread}/ 205 * @param thunk a {@code Runnable} to invoke when the object becomes phantom reachable The spec refers this as a cleaning function and this is the only outliner and refer it as ?thunk?. s/thunk/action - David suggested ?action?. "function? vs ?action? - It?s quite minor. I do think David has a good point that java.util.function.Function produces a result [1]. No new webrev is needed. Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037364.html From martinrb at google.com Tue Dec 15 03:13:39 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Dec 2015 19:13:39 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <20151214215239.0000571c.ecki@zusammenkunft.net> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566ECF1B.80406@Oracle.com> <20151214215239.0000571c.ecki@zusammenkunft.net> Message-ID: On Mon, Dec 14, 2015 at 12:52 PM, Bernd Eckenfels wrote: > Maybe it can benefit from the new "No Inherit TLS" Thread constructor? If the process has TLS, then one has to assume there's a good reason, and it will be necessary. From christian.thalinger at oracle.com Tue Dec 15 03:23:36 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Dec 2015 17:23:36 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566AB958.8010901@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> Message-ID: <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> > On Dec 11, 2015, at 1:54 AM, Konstantin Shefov wrote: > > Hello > > Please review the new version on the patch. > > New webrev: > Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 These newlines look ridiculous especially when it?s not even needed: + // Returns a class reference index for a method or a field. + public int getClassRefIndexAt + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } Either fix the indent or just add them like regular methods should look like. > > What has been changed: > 1. Added tests for the new added methods. > 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). > > Thanks > -Konstantin > > On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >> Coleen, >> Thanks for review >> >> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>> >>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >> I will add tests. >>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>> >>> thanks, >>> Coleen >>> >>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please, review modified webrev. >>>> >>>> I have added methods >>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>> >>>> I removed previously added method >>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>> >>>> New webrev: >>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>> Remi, >>>>> >>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>> >>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Christian Thalinger" >>>>>>> ?: "Konstantin Shefov" >>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>> >>>>>>> [CC'ing core-libs-dev] >>>>>>> >>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review an enhancement to add three new methods to >>>>>>>> sun.reflect.ConstantPool class. >>>>>>>> The following methods are suggested: >>>>>>>> >>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>> with the specified index >>>>>>>> >>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>> pool entry with the specified index >>>>>>>> >>>>>>>> These three methods could be used for testing API working with constant >>>>>>>> pool, e.g. JVMCI. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>> Webrev hotspot: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Dec 15 04:36:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 14:36:06 +1000 Subject: Need help to understand TLS behavior In-Reply-To: <20151214215239.0000571c.ecki@zusammenkunft.net> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566ECF1B.80406@Oracle.com> <20151214215239.0000571c.ecki@zusammenkunft.net> Message-ID: <566F98B6.3090005@oracle.com> On 15/12/2015 6:52 AM, Bernd Eckenfels wrote: > Am Mon, 14 Dec 2015 09:15:55 -0500 > schrieb Roger Riggs : > >> Hi, >> >> The reaper thread that waits for process exit has minimal stack >> requirements, >> and if possible should not consume all of the memory for a full stack. >> The 32k number is a guess at a small stack. It has worked so far >> except in cases >> where the VM configuration or parameters increase the size of stack >> the VM needs. > > Maybe it can benefit from the new "No Inherit TLS" Thread constructor? This is C/library Thread-local-Storage, not java.lang.ThreadLocal. David ----- > (However I wonder how two references in the thread object would > overflow the stack...) > > Gruss > Bernd > From david.holmes at oracle.com Tue Dec 15 04:44:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 14:44:43 +1000 Subject: Need help to understand TLS behavior In-Reply-To: References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> Message-ID: <566F9ABB.9050804@oracle.com> On 15/12/2015 6:53 AM, Martin Buchholz wrote: > Thread local storage is trouble. > > java stack sizes should be in _addition_ to any OS overhead, which includes TLS. TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing about that in "ELF Handling for Thread Local Storage". That is why I want to know more about the test, the compilation environment and the execution environment. > IOW, the java thread stack size should actually be available for stack frames. > Hotspot should be fixed, but it's not easy. Do you mean that the value specified at the Java level should be rounded up to accommodate guard pages etc at the native level? David ----- > On Mon, Dec 14, 2015 at 12:47 PM, David Holmes wrote: >> On 14/12/2015 11:06 PM, cheleswer sahu wrote: >>> >>> Hi David, >>> TLS is thread local storage. In test program it is defined using >>> >>> #define TLS_SIZE 32 >>> int __thread XYZ[TLS_SIZE * 1024]; >> >> >> Thanks for clarifying. What test is that? I'm guessing this may be a linux >> only test? Which platform do you see the problem on? >> >> We don't unconditionally use compiler-based TLS as some platforms may not >> support it. >> >> That aside that declaration should really be static I think. >> >> David >> ----- >> >> >>> Regards, >>> Cheleswer >>> On 12/14/2015 6:29 PM, David Holmes wrote: >>>> >>>> What is TLS in this context? >>>> >>>> Thanks, >>>> David >>>> >>>> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am investigating an issue, in which test with TLS size set to 32K is >>>>> failing with StackOverFlowError. During investigation I found the below >>>>> code >>>>> >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >>>>> >>>>> >>>>> >>>>> ThreadFactory threadFactory = grimReaper -> { >>>>> // Our thread stack requirement is quite modest. >>>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>>> "process reaper", 32768); >>>>> >>>>> Here reaper thread is created with fixed stack size "32768 ", which >>>>> causes StackOverFlowError when TLS is set to 32k around. >>>>> If I remove this fixed size and make it default, test works fine. >>>>> >>>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>>> "process reaper"); >>>>> >>>>> I have run several test with TLS size 32k , 64k ,128k and more . >>>>> The interesting part, it works well with 64k and 128k TLS size but not >>>>> with 32k. >>>>> So my questions are as follows: >>>>>> >>>>>> What is the motivation behind the fixed thread stack size ? >>>>>> will it be ok to replace the fixed stack size with default or stack >>>>> >>>>> size setting is platform sensitive? >>>>>> >>>>>> How TLS sizes are interpreted internally, which allows 64k and 128k >>>>> >>>>> to work but not to 32k ? >>>>> >>>>> I would really appreciate, if anyone have any opinion on this. >>>>> >>>>> Regards, >>>>> Cheleswer >>>>> >>>>> >>>>> >>> >> From jeremymanson at google.com Tue Dec 15 06:32:39 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 14 Dec 2015 22:32:39 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <566F9ABB.9050804@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> Message-ID: David: What the spec says and what glibc does are two different things: https://sourceware.org/bugzilla/show_bug.cgi?id=11787 We have an internal Google patch to compensate for this. Nasty stuff. Jeremy On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: > On 15/12/2015 6:53 AM, Martin Buchholz wrote: > >> Thread local storage is trouble. >> >> java stack sizes should be in _addition_ to any OS overhead, which >> includes TLS. >> > > TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing > about that in "ELF Handling for Thread Local Storage". That is why I want > to know more about the test, the compilation environment and the execution > environment. > > IOW, the java thread stack size should actually be available for stack >> frames. >> Hotspot should be fixed, but it's not easy. >> > > Do you mean that the value specified at the Java level should be rounded > up to accommodate guard pages etc at the native level? > > David > ----- > > > On Mon, Dec 14, 2015 at 12:47 PM, David Holmes >> wrote: >> >>> On 14/12/2015 11:06 PM, cheleswer sahu wrote: >>> >>>> >>>> Hi David, >>>> TLS is thread local storage. In test program it is defined using >>>> >>>> #define TLS_SIZE 32 >>>> int __thread XYZ[TLS_SIZE * 1024]; >>>> >>> >>> >>> Thanks for clarifying. What test is that? I'm guessing this may be a >>> linux >>> only test? Which platform do you see the problem on? >>> >>> We don't unconditionally use compiler-based TLS as some platforms may not >>> support it. >>> >>> That aside that declaration should really be static I think. >>> >>> David >>> ----- >>> >>> >>> Regards, >>>> Cheleswer >>>> On 12/14/2015 6:29 PM, David Holmes wrote: >>>> >>>>> >>>>> What is TLS in this context? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am investigating an issue, in which test with TLS size set to 32K is >>>>>> failing with StackOverFlowError. During investigation I found the >>>>>> below >>>>>> code >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >>>>>> >>>>>> >>>>>> >>>>>> ThreadFactory threadFactory = grimReaper -> { >>>>>> // Our thread stack requirement is quite modest. >>>>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>>>> "process reaper", 32768); >>>>>> >>>>>> Here reaper thread is created with fixed stack size "32768 ", which >>>>>> causes StackOverFlowError when TLS is set to 32k around. >>>>>> If I remove this fixed size and make it default, test works fine. >>>>>> >>>>>> Thread t = new Thread(systemThreadGroup, grimReaper, >>>>>> "process reaper"); >>>>>> >>>>>> I have run several test with TLS size 32k , 64k ,128k and more . >>>>>> The interesting part, it works well with 64k and 128k TLS size but not >>>>>> with 32k. >>>>>> So my questions are as follows: >>>>>> >>>>>>> >>>>>>> What is the motivation behind the fixed thread stack size ? >>>>>>> will it be ok to replace the fixed stack size with default or stack >>>>>>> >>>>>> >>>>>> size setting is platform sensitive? >>>>>> >>>>>>> >>>>>>> How TLS sizes are interpreted internally, which allows 64k and 128k >>>>>>> >>>>>> >>>>>> to work but not to 32k ? >>>>>> >>>>>> I would really appreciate, if anyone have any opinion on this. >>>>>> >>>>>> Regards, >>>>>> Cheleswer >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> From david.holmes at oracle.com Tue Dec 15 06:53:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 16:53:43 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566F44D6.7! 020503@Oracle.com> Message-ID: <566FB8F7.4030206@oracle.com> On 15/12/2015 10:48 AM, Mandy Chung wrote: > >> On Dec 14, 2015, at 2:38 PM, Roger Riggs wrote: >> >> Hi, >> >> The complexity of using Lambda for cleaning functions are too hard to explain in depth >> in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and other should stick to the static nested class. >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Looks okay in general. When we convert existing use of finalizers in the JDK to Cleaner, that would give good feedback to this API. As the api note, it would be better if the CleaningExample shows the real cleaning work. It?s okay with me if you want to file a JBS issue and do that later if you want to build up some examples when converting existing use to Cleaner. > > Editorial comments. > > 186 * @exception IllegalThreadStateException if the thread from the thread > 187 * factory was {@link Thread.State#NEW not a new thread}. > > s/@exception/@throws/ > s/ {@link Thread.State#NEW not a new thread}/not a {@link Thread.State#NEW new thread}/ > > 205 * @param thunk a {@code Runnable} to invoke when the object becomes phantom reachable > > The spec refers this as a cleaning function and this is the only outliner and refer it as ?thunk?. > > s/thunk/action - David suggested ?action?. "function? vs ?action? - It?s quite minor. I do think David has a good point that java.util.function.Function produces a result [1]. No new webrev is needed. It also matches with j.u.c.RecursiveAction, which is a resultless ForkJoinTask. functions return values. Cheers, David > Mandy > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037364.html > From david.holmes at oracle.com Tue Dec 15 06:59:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 16:59:36 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566F44D6.7020503@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566F44D6.7020503@Oracle.com> Message-ID: <566FBA58.3010002@oracle.com> Hi Roger, On 15/12/2015 8:38 AM, Roger Riggs wrote: > Hi, > > The complexity of using Lambda for cleaning functions are too hard to > explain in depth > in the context of an example. A more conservative approach is to show > using a static nested > class. A lambda savvy developer can correctly determine how to avoid > the pitfalls, and others > should stick to the static nested class. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html I still think Cleaner deserves to be mentioned in the package javadoc. I also strongly urge the thunk/function -> action, change. Terminology is important. Thanks, David ----- > Thanks, Roger > > p.s. last call for comments > From david.holmes at oracle.com Tue Dec 15 07:01:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 17:01:35 +1000 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5668759A.1070204@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> Message-ID: <566FBACF.3010606@oracle.com> PS. create(): can also throw SecurityException if not allowed to create/start threads. David On 10/12/2015 4:40 AM, Roger Riggs wrote: > Hi, > > The example is revised to caution about inner classes and lambdas. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Thanks, Roger > > On 12/9/2015 11:04 AM, Peter Levart wrote: >> Hi Chris, >> >> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>> Peter, >>> >>> On 09/12/15 07:05, Peter Levart wrote: >>>> Hi, >>>> >>>> I think the only way to try to prevent such things is with a good >>>> example in javadoc that "screams" of possible miss-usages. >>>> >>>> >>>> public static class CleanerExample implements AutoCloseable { >>>> >>>> private static final Cleaner cleaner = ...; // preferably a >>>> shared cleaner >>>> >>>> private final PrivateNativeResource pnr; >>>> >>>> private final Cleaner.Cleanable cleanable; >>>> >>>> public CleanerExample(args, ...) { >>>> >>>> // prepare captured state as local vars... >>>> PrivateNativeResource _pnr = ...; >>>> >>>> this.cleanable = cleaner.register(this, () -> { >>>> // DON'T capture any instance fields with lambda since >>>> that would >>>> // capture 'this' and prevent it from becoming >>> >>> I assume that the WARNING should include anonymous inner classes too >>> ( which I expect are quite common, though less now with lambda ) ? >>> >>> Is "leaking" 'this' in a constructor a potential issue with respect >>> to the visibility of pnr? As well as causing red-squiggly lines in >>> the IDE ;-) >> >> 'this' only leaks to the 'referent' field of PhantomReference where by >> definition is not accessible. >> >> 'this' can become phantom-reachable before CleanerExample constructor >> ends. But this is harmless, because the code that may execute at that >> time does not access the object any more, so the object may be safely >> collected. >> >> Cleanup action can run at any time after registration even before >> CleanerExample constructor ends. But this is harmless too, because it >> only accesses PrivateNativeResource which is fully constructed before >> registration of cleanup action. >> >> I see no issues apart from IDE(s) not seeing no issues. >> >> Regards, Peter >> >>> >>> -Chris. >>> >>> >>>> phantom-reachable!!! >>>> _pnr.close(); >>>> }); >>>> >>>> this.pnr = _pnr; >>>> } >>>> >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> >>>> >>>> Regards, Peter >>>> >> > From david.holmes at oracle.com Tue Dec 15 07:25:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 17:25:48 +1000 Subject: Need help to understand TLS behavior In-Reply-To: References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> Message-ID: <566FC07C.8010509@oracle.com> On 15/12/2015 4:32 PM, Jeremy Manson wrote: > David: What the spec says and what glibc does are two different things: > > https://sourceware.org/bugzilla/show_bug.cgi?id=11787 > > We have an internal Google patch to compensate for this. Nasty stuff. Nasty isn't even the right word - this is just ludicrous! And the bug has just languished even though they were going to fix it years ago!!!!! And I also cried when I saw the part finally recognizing that glibc does the wrong thing by taking the guard pages from the requested stack size! To me this just screams don't use TLS on linux except for trivially small data structures, or else use static-TLS. Which brings me back to this test - make the variable static! Thanks Jeremy. I'm thoroughly depressed now. David ----- > Jeremy > > On Mon, Dec 14, 2015 at 8:44 PM, David Holmes > wrote: > > On 15/12/2015 6:53 AM, Martin Buchholz wrote: > > Thread local storage is trouble. > > java stack sizes should be in _addition_ to any OS overhead, > which includes TLS. > > > TLS shouldn't be coming out the stack of the thread AFAIK - I see > nothing about that in "ELF Handling for Thread Local Storage". That > is why I want to know more about the test, the compilation > environment and the execution environment. > > IOW, the java thread stack size should actually be available for > stack frames. > Hotspot should be fixed, but it's not easy. > > > Do you mean that the value specified at the Java level should be > rounded up to accommodate guard pages etc at the native level? > > David > ----- > > > On Mon, Dec 14, 2015 at 12:47 PM, David Holmes > > wrote: > > On 14/12/2015 11:06 PM, cheleswer sahu wrote: > > > Hi David, > TLS is thread local storage. In test program it is > defined using > > #define TLS_SIZE 32 > int __thread XYZ[TLS_SIZE * 1024]; > > > > Thanks for clarifying. What test is that? I'm guessing this > may be a linux > only test? Which platform do you see the problem on? > > We don't unconditionally use compiler-based TLS as some > platforms may not > support it. > > That aside that declaration should really be static I think. > > David > ----- > > > Regards, > Cheleswer > On 12/14/2015 6:29 PM, David Holmes wrote: > > > What is TLS in this context? > > Thanks, > David > > On 14/12/2015 10:34 PM, cheleswer sahu wrote: > > > Hi, > > I am investigating an issue, in which test with > TLS size set to 32K is > failing with StackOverFlowError. During > investigation I found the below > code > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java > > > > ThreadFactory threadFactory = grimReaper -> { > // Our thread stack > requirement is quite modest. > Thread t = new > Thread(systemThreadGroup, grimReaper, > > "process reaper", 32768); > > Here reaper thread is created with fixed stack > size "32768 ", which > causes StackOverFlowError when TLS is set to > 32k around. > If I remove this fixed size and make it default, > test works fine. > > Thread t = new Thread(systemThreadGroup, grimReaper, > > "process reaper"); > > I have run several test with TLS size 32k , 64k > ,128k and more . > The interesting part, it works well with 64k and > 128k TLS size but not > with 32k. > So my questions are as follows: > > > What is the motivation behind the fixed > thread stack size ? > will it be ok to replace the fixed stack > size with default or stack > > > size setting is platform sensitive? > > > How TLS sizes are interpreted internally, > which allows 64k and 128k > > > to work but not to 32k ? > > I would really appreciate, if anyone have any > opinion on this. > > Regards, > Cheleswer > > > > > > From volker.simonis at gmail.com Tue Dec 15 07:55:36 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Dec 2015 08:55:36 +0100 Subject: RFR(XXS): 8145212: ISO-8859-1 isn't properly handled as 'fastEncoding' in jni_util.c In-Reply-To: <566F2BFB.4050404@oracle.com> References: <566F2BFB.4050404@oracle.com> Message-ID: Forwarded to core-libs-dev upon request. As I already got two reviews (thanks Roger and Martin) and as the fix for "8145015: jni_GetStringCritical asserts for empty strings" [1] has just been pushed to jdk9/hs-rt/hotspot I plan to push this one to jdk9/hs-rt/jdk as well. Regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8145015 On Mon, Dec 14, 2015 at 9:52 PM, Alan Bateman wrote: > > > On 14/12/2015 14:45, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review this trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145212/ >> https://bugs.openjdk.java.net/browse/JDK-8145212 >> >> > Can you bring this to core-libs-dev? > > -Alan. From Alan.Bateman at oracle.com Tue Dec 15 08:00:33 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Dec 2015 08:00:33 +0000 Subject: RFR(XXS): 8145212: ISO-8859-1 isn't properly handled as 'fastEncoding' in jni_util.c In-Reply-To: References: <566F2BFB.4050404@oracle.com> Message-ID: <566FC8A1.7020000@oracle.com> On 15/12/2015 07:55, Volker Simonis wrote: > Forwarded to core-libs-dev upon request. > > As I already got two reviews (thanks Roger and Martin) and as the fix > for "8145015: jni_GetStringCritical asserts for empty strings" [1] has > just been pushed to jdk9/hs-rt/hotspot I plan to push this one to > jdk9/hs-rt/jdk as well. > Thanks, that should be fine. The main thing is that jdk9-dev isn't really suited for code reviews. I know random stuff is sent there periodically but it's not really the place to review change in specific areas. -Alan From konstantin.shefov at oracle.com Tue Dec 15 09:11:28 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 15 Dec 2015 12:11:28 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> Message-ID: <566FD940.4090608@oracle.com> Hi Christian Thanks for reviewing, I have changed indents as you asked: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 -Konstantin On 12/15/2015 06:23 AM, Christian Thalinger wrote: > >> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >> > >> wrote: >> >> Hello >> >> Please review the new version on the patch. >> >> New webrev: >> Webrev hotspot: >> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >> >> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> > > These newlines look ridiculous especially when it?s not even needed: > > + // Returns a class reference index for a method or a field. > + public int getClassRefIndexAt > + (int index) { return > getClassRefIndexAt0 (constantPoolOop, index); } > > Either fix the indent or just add them like regular methods should > look like. > >> >> What has been changed: >> 1. Added tests for the new added methods. >> 2. Removed CP tag codes 100 - 105 from being passed to java and left >> only codes from the open JVM spec >> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >> >> Thanks >> -Konstantin >> >> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>> Coleen, >>> Thanks for review >>> >>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>> >>>> I have a couple preliminary comments. First, there are no tests >>>> added with all this new functionality. Tests should be added with >>>> the functionality changeset, not promised afterward. >>> I will add tests. >>>> Secondly, I do not like that JDK code knows the implementation >>>> details of the JVM's constant pool tags. These should be only for >>>> internal use. >>> The package "sun.reflect" is for internal use only, so it shouldn?t >>> be a problem. >>>> My third comment is that I haven't looked carefully at this >>>> constant pool implementation but it seems very unsafe if the class >>>> is redefined and relies on an implementation detail in the JVM that >>>> can change. I will have more comments once I look more at the >>>> jvmti specification. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please, review modified webrev. >>>>> >>>>> I have added methods >>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>>>> index from a method, field or indy entry index; >>>>> getClassRefIndexAt(int index) - to get class entry index from a >>>>> method or field entry index; >>>>> >>>>> I removed previously added method >>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: >>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>> >>>>> Webrev jdk: >>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>> >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>> Remi, >>>>>> >>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>> May be it also has sense to make a method >>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>> name-and-type entry index for methods also. >>>>>> >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>> Hi Konstantin, >>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract >>>>>>> the nameAndType value of the InvokeDynamicRef. >>>>>>> >>>>>>> In term of API, I think it's better to decompose the API, i.e. >>>>>>> to have a method >>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>> that returns the nameAndType index and to reuse >>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of >>>>>>> Strings. >>>>>>> >>>>>>> cheers, >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>>> De: "Christian Thalinger" >>>>>>> > >>>>>>>> ?: "Konstantin Shefov" >>>>>>> > >>>>>>>> Cc: "hotspot-dev developers" >>>>>>> >, >>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>> >>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>> sun.reflect.ConstantPool >>>>>>>> >>>>>>>> [CC'ing core-libs-dev] >>>>>>>> >>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>> The following methods are suggested: >>>>>>>>> >>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns >>>>>>>>> string >>>>>>>>> representation of name and type from a NameAndType constant >>>>>>>>> pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns >>>>>>>>> string >>>>>>>>> representation of name and type from an InvokeDynamic constant >>>>>>>>> pool entry >>>>>>>>> with the specified index >>>>>>>>> >>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance >>>>>>>>> of a constant >>>>>>>>> pool entry with the specified index >>>>>>>>> >>>>>>>>> These three methods could be used for testing API working with >>>>>>>>> constant >>>>>>>>> pool, e.g. JVMCI. >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>> Webrev hotspot: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>> >>>>>>>>> Webrev jdk: >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.stuefe at gmail.com Tue Dec 15 09:25:48 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Dec 2015 10:25:48 +0100 Subject: Need help to understand TLS behavior In-Reply-To: <566FC07C.8010509@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> Message-ID: Hi Jeremy, David, I would like to understand the problem better and have some questions, maybe you could answer? - What is the difference between "static __thread int x" and "__thread int x" - one lives in the thread stacks, one does not? - What happens with existing threads if a library is loaded which uses this form of TLS? - Does this TLS live at the top of the stack? So, to find out if a third party library uses this form of TLS, we could check the distance of sp to the stack base in java_start()? - Would the region returned by pthread_attr_getstack() include the TLS region? Thanks! Kind Regards, Thomas On Tue, Dec 15, 2015 at 8:25 AM, David Holmes wrote: > On 15/12/2015 4:32 PM, Jeremy Manson wrote: > >> David: What the spec says and what glibc does are two different things: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=11787 >> >> We have an internal Google patch to compensate for this. Nasty stuff. >> > > Nasty isn't even the right word - this is just ludicrous! And the bug has > just languished even though they were going to fix it years ago!!!!! And I > also cried when I saw the part finally recognizing that glibc does the > wrong thing by taking the guard pages from the requested stack size! > > To me this just screams don't use TLS on linux except for trivially small > data structures, or else use static-TLS. > > Which brings me back to this test - make the variable static! > > Thanks Jeremy. I'm thoroughly depressed now. > > David > ----- > > Jeremy >> >> On Mon, Dec 14, 2015 at 8:44 PM, David Holmes > > wrote: >> >> On 15/12/2015 6:53 AM, Martin Buchholz wrote: >> >> Thread local storage is trouble. >> >> java stack sizes should be in _addition_ to any OS overhead, >> which includes TLS. >> >> >> TLS shouldn't be coming out the stack of the thread AFAIK - I see >> nothing about that in "ELF Handling for Thread Local Storage". That >> is why I want to know more about the test, the compilation >> environment and the execution environment. >> >> IOW, the java thread stack size should actually be available for >> stack frames. >> Hotspot should be fixed, but it's not easy. >> >> >> Do you mean that the value specified at the Java level should be >> rounded up to accommodate guard pages etc at the native level? >> >> David >> ----- >> >> >> On Mon, Dec 14, 2015 at 12:47 PM, David Holmes >> > wrote: >> >> On 14/12/2015 11:06 PM, cheleswer sahu wrote: >> >> >> Hi David, >> TLS is thread local storage. In test program it is >> defined using >> >> #define TLS_SIZE 32 >> int __thread XYZ[TLS_SIZE * 1024]; >> >> >> >> Thanks for clarifying. What test is that? I'm guessing this >> may be a linux >> only test? Which platform do you see the problem on? >> >> We don't unconditionally use compiler-based TLS as some >> platforms may not >> support it. >> >> That aside that declaration should really be static I think. >> >> David >> ----- >> >> >> Regards, >> Cheleswer >> On 12/14/2015 6:29 PM, David Holmes wrote: >> >> >> What is TLS in this context? >> >> Thanks, >> David >> >> On 14/12/2015 10:34 PM, cheleswer sahu wrote: >> >> >> Hi, >> >> I am investigating an issue, in which test with >> TLS size set to 32K is >> failing with StackOverFlowError. During >> investigation I found the below >> code >> >> >> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java >> >> >> >> ThreadFactory threadFactory = grimReaper -> { >> // Our thread stack >> requirement is quite modest. >> Thread t = new >> Thread(systemThreadGroup, grimReaper, >> >> "process reaper", 32768); >> >> Here reaper thread is created with fixed stack >> size "32768 ", which >> causes StackOverFlowError when TLS is set to >> 32k around. >> If I remove this fixed size and make it default, >> test works fine. >> >> Thread t = new Thread(systemThreadGroup, >> grimReaper, >> >> "process reaper"); >> >> I have run several test with TLS size 32k , 64k >> ,128k and more . >> The interesting part, it works well with 64k and >> 128k TLS size but not >> with 32k. >> So my questions are as follows: >> >> >> What is the motivation behind the fixed >> thread stack size ? >> will it be ok to replace the fixed stack >> size with default or stack >> >> >> size setting is platform sensitive? >> >> >> How TLS sizes are interpreted internally, >> which allows 64k and 128k >> >> >> to work but not to 32k ? >> >> I would really appreciate, if anyone have any >> opinion on this. >> >> Regards, >> Cheleswer >> >> >> >> >> >> >> From david.holmes at oracle.com Tue Dec 15 10:00:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 20:00:34 +1000 Subject: Need help to understand TLS behavior In-Reply-To: References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> Message-ID: <566FE4C2.50504@oracle.com> On 15/12/2015 7:25 PM, Thomas St?fe wrote: > Hi Jeremy, David, > > I would like to understand the problem better and have some questions, > maybe you could answer? The "specification" for ELF based TLS as I understood it is the Ulrich Drepper document I referenced: ""ELF Handling for Thread Local Storage", for which I don't have a URL handy. But you can see basically the same kind of information in the Solaris document: https://docs.oracle.com/cd/E26502_01/pdf/E26507.pdf the details are complex as it depends on the exact model being used. > - What is the difference between "static __thread int x" and "__thread > int x" - one lives in the thread stacks, one does not? If we are working with the initial executable or a statically linked library then the storage for a static TLS variable can be allocated in a static data segment. For a dynamic library there are two options: there may be some spare space in the static area which may be used, or the storage is allocated in the Thread-Control-Block - again it depends on the model. And I guess it is up to the implementation as to how/where it manages TCBs - they might be placed at the top of the stack, I don't know. > - What happens with existing threads if a library is loaded which uses > this form of TLS? See above. > - Does this TLS live at the top of the stack? So, to find out if a third > party library uses this form of TLS, we could check the distance of sp > to the stack base in java_start()? Depends on the implementation. I'm not concerned with trying to solve any general problem here, just the problem with this specific test (which I have not yet seen :) ) > - Would the region returned by pthread_attr_getstack() include the TLS > region? That's up to glibc. David > Thanks! > > Kind Regards, Thomas > > > On Tue, Dec 15, 2015 at 8:25 AM, David Holmes > wrote: > > On 15/12/2015 4:32 PM, Jeremy Manson wrote: > > David: What the spec says and what glibc does are two different > things: > > https://sourceware.org/bugzilla/show_bug.cgi?id=11787 > > We have an internal Google patch to compensate for this. Nasty > stuff. > > > Nasty isn't even the right word - this is just ludicrous! And the > bug has just languished even though they were going to fix it years > ago!!!!! And I also cried when I saw the part finally recognizing > that glibc does the wrong thing by taking the guard pages from the > requested stack size! > > To me this just screams don't use TLS on linux except for trivially > small data structures, or else use static-TLS. > > Which brings me back to this test - make the variable static! > > Thanks Jeremy. I'm thoroughly depressed now. > > David > ----- > > Jeremy > > On Mon, Dec 14, 2015 at 8:44 PM, David Holmes > > >> wrote: > > On 15/12/2015 6:53 AM, Martin Buchholz wrote: > > Thread local storage is trouble. > > java stack sizes should be in _addition_ to any OS > overhead, > which includes TLS. > > > TLS shouldn't be coming out the stack of the thread AFAIK - > I see > nothing about that in "ELF Handling for Thread Local > Storage". That > is why I want to know more about the test, the compilation > environment and the execution environment. > > IOW, the java thread stack size should actually be > available for > stack frames. > Hotspot should be fixed, but it's not easy. > > > Do you mean that the value specified at the Java level > should be > rounded up to accommodate guard pages etc at the native level? > > David > ----- > > > On Mon, Dec 14, 2015 at 12:47 PM, David Holmes > >> wrote: > > On 14/12/2015 11:06 PM, cheleswer sahu wrote: > > > Hi David, > TLS is thread local storage. In test program it is > defined using > > #define TLS_SIZE 32 > int __thread XYZ[TLS_SIZE * 1024]; > > > > Thanks for clarifying. What test is that? I'm > guessing this > may be a linux > only test? Which platform do you see the problem on? > > We don't unconditionally use compiler-based TLS as some > platforms may not > support it. > > That aside that declaration should really be static > I think. > > David > ----- > > > Regards, > Cheleswer > On 12/14/2015 6:29 PM, David Holmes wrote: > > > What is TLS in this context? > > Thanks, > David > > On 14/12/2015 10:34 PM, cheleswer sahu wrote: > > > Hi, > > I am investigating an issue, in which > test with > TLS size set to 32K is > failing with StackOverFlowError. During > investigation I found the below > code > > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/tip/src/solaris/classes/java/lang/UNIXProcess.java > > > > ThreadFactory threadFactory = > grimReaper -> { > // Our thread stack > requirement is quite modest. > Thread t = new > Thread(systemThreadGroup, grimReaper, > > "process reaper", 32768); > > Here reaper thread is created with > fixed stack > size "32768 ", which > causes StackOverFlowError when TLS is > set to > 32k around. > If I remove this fixed size and make it > default, > test works fine. > > Thread t = new > Thread(systemThreadGroup, grimReaper, > > "process reaper"); > > I have run several test with TLS size > 32k , 64k > ,128k and more . > The interesting part, it works well > with 64k and > 128k TLS size but not > with 32k. > So my questions are as follows: > > > What is the motivation behind the fixed > thread stack size ? > will it be ok to replace the fixed > stack > size with default or stack > > > size setting is platform sensitive? > > > How TLS sizes are interpreted > internally, > which allows 64k and 128k > > > to work but not to 32k ? > > I would really appreciate, if anyone > have any > opinion on this. > > Regards, > Cheleswer > > > > > > > From chris.hegarty at oracle.com Tue Dec 15 12:00:47 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Dec 2015 12:00:47 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect Message-ID: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> No new code here, just giving sun.misc.ProxyGenerator a more appropriate location, in jdk.internal.reflect ( since it contains the code to generate a dynamic proxy class for the java.lang.reflect.Proxy ). http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ Note: ProxyGenerator could be moved into java.lang.reflect, as a package-private class, but I see no reason to move it into an exported package, and a package that it not on the restricted package list. -Chris. From Roger.Riggs at Oracle.com Tue Dec 15 14:44:31 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 09:44:31 -0500 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: <5670274F.8090204@Oracle.com> Hi Chris, ok as is. But is that the only class in the jdk.internal.reflect package (or will it always be)? Roger On 12/15/2015 7:00 AM, Chris Hegarty wrote: > No new code here, just giving sun.misc.ProxyGenerator a more appropriate > location, in jdk.internal.reflect ( since it contains the code to generate a dynamic > proxy class for the java.lang.reflect.Proxy ). > > http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ > > Note: ProxyGenerator could be moved into java.lang.reflect, as a > package-private class, but I see no reason to move it into an exported > package, and a package that it not on the restricted package list. > > -Chris. From Alan.Bateman at oracle.com Tue Dec 15 14:49:28 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Dec 2015 14:49:28 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: <56702878.3070609@oracle.com> On 15/12/2015 12:00, Chris Hegarty wrote: > No new code here, just giving sun.misc.ProxyGenerator a more appropriate > location, in jdk.internal.reflect ( since it contains the code to generate a dynamic > proxy class for the java.lang.reflect.Proxy ). > > http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ > > Note: ProxyGenerator could be moved into java.lang.reflect, as a > package-private class, but I see no reason to move it into an exported > package, and a package that it not on the restricted package list. > > -Chris. Looks okay, I would imagine moving a few other classes into this package too. -Alan From chris.hegarty at oracle.com Tue Dec 15 14:51:11 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Dec 2015 14:51:11 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: <5670274F.8090204@Oracle.com> References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> <5670274F.8090204@Oracle.com> Message-ID: On 15 Dec 2015, at 14:44, Roger Riggs wrote: > Hi Chris, > > ok as is. Thanks for looking at this Roger. > But is that the only class in the jdk.internal.reflect package (or will it always be)? Nope. Several other classes from sun.reflect will likely wind up there too. -Chris. > Roger > > > On 12/15/2015 7:00 AM, Chris Hegarty wrote: >> No new code here, just giving sun.misc.ProxyGenerator a more appropriate >> location, in jdk.internal.reflect ( since it contains the code to generate a dynamic >> proxy class for the java.lang.reflect.Proxy ). >> >> http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ >> >> Note: ProxyGenerator could be moved into java.lang.reflect, as a >> package-private class, but I see no reason to move it into an exported >> package, and a package that it not on the restricted package list. >> >> -Chris. > From pbenedict at apache.org Tue Dec 15 15:09:19 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Dec 2015 09:09:19 -0600 Subject: General question: sun package -> jdk package? Message-ID: I have a general question prompted by the many classes moved from sun.* to jdk.*. Once JDK 9 delivers on the Module System and internals are no longer exposed, is it planned to eventually migrate away from the sun.* legacy namespace in later JDK versions? Cheers, Paul From chris.hegarty at oracle.com Tue Dec 15 15:15:11 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Dec 2015 15:15:11 +0000 Subject: General question: sun package -> jdk package? In-Reply-To: References: Message-ID: Paul, I cannot address your general question, but I guess it might be motivated by some of my recent preparatory work for JEP 260 [1]. This JEP proposes to expose a small number of critical API?s that are in the sun.misc and sun.reflect namespace. Anything not deemed critical should be removed from these packages, since it should not be exposed. There is also a significant amount of technical debt in these packages. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 On 15 Dec 2015, at 15:09, Paul Benedict wrote: > I have a general question prompted by the many classes moved from sun.* to > jdk.*. Once JDK 9 delivers on the Module System and internals are no longer > exposed, is it planned to eventually migrate away from the sun.* legacy > namespace in later JDK versions? > > Cheers, > Paul From pbenedict at apache.org Tue Dec 15 15:25:25 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Dec 2015 09:25:25 -0600 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566FBACF.3010606@oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566FBACF.3010606@oracle.com> Message-ID: David, this needs editing. * The cleaning function is invoked after the object it is cleaning up after it * becomes phantom reachable, so it is important that the references and values * it needs do not prevent the object from becoming phantom reachable. 1) The "after it" looks like a leftover from an edit 2) "becomes phantom reachable" after already "becoming phantom reachable" needs clarification to make sense: My suggestion: * The cleaning function is invoked after the object it is cleaning becomes * phantom reachable, so it is important that the object's references and values * do not prevent the object from remaining phantom reachable. PS: I noticed in the source that much of the documentation is written with line breaks but without the

    tag. If you have a paragraph in mind, perhaps you can remove the line breaks so it doesn't look like

    tags were meant to be there but forgotten. Cheers, Paul On Tue, Dec 15, 2015 at 1:01 AM, David Holmes wrote: > PS. > > create(): can also throw SecurityException if not allowed to create/start > threads. > > David > > On 10/12/2015 4:40 AM, Roger Riggs wrote: > >> Hi, >> >> The example is revised to caution about inner classes and lambdas. >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> Thanks, Roger >> >> On 12/9/2015 11:04 AM, Peter Levart wrote: >> >>> Hi Chris, >>> >>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>> >>>> Peter, >>>> >>>> On 09/12/15 07:05, Peter Levart wrote: >>>> >>>>> Hi, >>>>> >>>>> I think the only way to try to prevent such things is with a good >>>>> example in javadoc that "screams" of possible miss-usages. >>>>> >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static final Cleaner cleaner = ...; // preferably a >>>>> shared cleaner >>>>> >>>>> private final PrivateNativeResource pnr; >>>>> >>>>> private final Cleaner.Cleanable cleanable; >>>>> >>>>> public CleanerExample(args, ...) { >>>>> >>>>> // prepare captured state as local vars... >>>>> PrivateNativeResource _pnr = ...; >>>>> >>>>> this.cleanable = cleaner.register(this, () -> { >>>>> // DON'T capture any instance fields with lambda since >>>>> that would >>>>> // capture 'this' and prevent it from becoming >>>>> >>>> >>>> I assume that the WARNING should include anonymous inner classes too >>>> ( which I expect are quite common, though less now with lambda ) ? >>>> >>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>> the IDE ;-) >>>> >>> >>> 'this' only leaks to the 'referent' field of PhantomReference where by >>> definition is not accessible. >>> >>> 'this' can become phantom-reachable before CleanerExample constructor >>> ends. But this is harmless, because the code that may execute at that >>> time does not access the object any more, so the object may be safely >>> collected. >>> >>> Cleanup action can run at any time after registration even before >>> CleanerExample constructor ends. But this is harmless too, because it >>> only accesses PrivateNativeResource which is fully constructed before >>> registration of cleanup action. >>> >>> I see no issues apart from IDE(s) not seeing no issues. >>> >>> Regards, Peter >>> >>> >>>> -Chris. >>>> >>>> >>>> phantom-reachable!!! >>>>> _pnr.close(); >>>>> }); >>>>> >>>>> this.pnr = _pnr; >>>>> } >>>>> >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>> >> From Roger.Riggs at Oracle.com Tue Dec 15 15:57:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 10:57:59 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <566FBA58.3010002@oracle.com> References: <560D3F61.6040607@Oracle.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566F44D6.7020503@Oracle.com> <566FBA58.3010002@oracle.com> Message-ID: <56703887.1060506@Oracle.com> Hi David, Thanks for the comments and suggestions from recent emails, they have been applied to the webrev and javadoc. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html Roger On 12/15/2015 1:59 AM, David Holmes wrote: > Hi Roger, > > On 15/12/2015 8:38 AM, Roger Riggs wrote: >> Hi, >> >> The complexity of using Lambda for cleaning functions are too hard to >> explain in depth >> in the context of an example. A more conservative approach is to show >> using a static nested >> class. A lambda savvy developer can correctly determine how to avoid >> the pitfalls, and others >> should stick to the static nested class. >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > I still think Cleaner deserves to be mentioned in the package javadoc. > > I also strongly urge the thunk/function -> action, change. Terminology > is important. > > Thanks, > David > ----- > > >> Thanks, Roger >> >> p.s. last call for comments >> From kumar.x.srinivasan at oracle.com Tue Dec 15 15:54:18 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 15 Dec 2015 07:54:18 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem Message-ID: <567037AA.30801@oracle.com> Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ The background: The launcher uses stat(2) to check for the existence of a file, unfortunately on 32-bit system with large file systems causes the inode storage to overflow causing the syscall to return EOVERFLOW. Solution: * stat(2) replaced with access(3), in most cases. * jbs is marked noreg-hard hard to replicate the problem Thanks Kumar From Roger.Riggs at Oracle.com Tue Dec 15 16:00:56 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 11:00:56 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566FBACF.3010606@oracle.com> Message-ID: <56703938.3050406@Oracle.com> Hi Paul, The credit/blame for the Cleaner doc is mine. On 12/15/2015 10:25 AM, Paul Benedict wrote: > David, this needs editing. > > * The cleaning function is invoked after the object it is cleaning up > after it > * becomes phantom reachable, so it is important that the references > and values > * it needs do not prevent the object from becoming phantom reachable. > > 1) The "after it" looks like a leftover from an edit > 2) "becomes phantom reachable" after already "becoming phantom > reachable" needs clarification to make sense: Yes, this poorly worded. It has been simplified in the latest update. > > My suggestion: > > * The cleaning function is invoked after the object it is cleaning > becomes > * phantom reachable, so it is important that the object's references > and values > * do not prevent the object from remaining phantom reachable. > > PS: I noticed in the source that much of the documentation is written > with line breaks but without the

    tag. If you have a paragraph in > mind, perhaps you can remove the line breaks so it doesn't look like >

    tags were meant to be there but forgotten. Blank lines improve readability of the source; but should not appear to break any paragraph. Did I miss some? Thanks, Roger > > Cheers, > Paul > > On Tue, Dec 15, 2015 at 1:01 AM, David Holmes > wrote: > > PS. > > create(): can also throw SecurityException if not allowed to > create/start threads. > > David > > On 10/12/2015 4:40 AM, Roger Riggs wrote: > > Hi, > > The example is revised to caution about inner classes and lambdas. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > > Thanks, Roger > > On 12/9/2015 11:04 AM, Peter Levart wrote: > > Hi Chris, > > On 12/09/2015 04:03 PM, Chris Hegarty wrote: > > Peter, > > On 09/12/15 07:05, Peter Levart wrote: > > Hi, > > I think the only way to try to prevent such things > is with a good > example in javadoc that "screams" of possible > miss-usages. > > > public static class CleanerExample implements > AutoCloseable { > > private static final Cleaner cleaner = > ...; // preferably a > shared cleaner > > private final PrivateNativeResource pnr; > > private final Cleaner.Cleanable cleanable; > > public CleanerExample(args, ...) { > > // prepare captured state as local > vars... > PrivateNativeResource _pnr = ...; > > this.cleanable = > cleaner.register(this, () -> { > // DON'T capture any instance > fields with lambda since > that would > // capture 'this' and prevent it > from becoming > > > I assume that the WARNING should include anonymous > inner classes too > ( which I expect are quite common, though less now > with lambda ) ? > > Is "leaking" 'this' in a constructor a potential issue > with respect > to the visibility of pnr? As well as causing > red-squiggly lines in > the IDE ;-) > > > 'this' only leaks to the 'referent' field of > PhantomReference where by > definition is not accessible. > > 'this' can become phantom-reachable before CleanerExample > constructor > ends. But this is harmless, because the code that may > execute at that > time does not access the object any more, so the object > may be safely > collected. > > Cleanup action can run at any time after registration even > before > CleanerExample constructor ends. But this is harmless too, > because it > only accesses PrivateNativeResource which is fully > constructed before > registration of cleanup action. > > I see no issues apart from IDE(s) not seeing no issues. > > Regards, Peter > > > -Chris. > > > phantom-reachable!!! > _pnr.close(); > }); > > this.pnr = _pnr; > } > > public void close() { > cleanable.clean(); > } > > > Regards, Peter > > > > From pbenedict at apache.org Tue Dec 15 16:03:38 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Dec 2015 10:03:38 -0600 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56703938.3050406@Oracle.com> References: <560D3F61.6040607@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <566FBACF.3010606@oracle.com> <56703938.3050406@Oracle.com> Message-ID: No, you didn't miss any. I didn't know you were using line breaks for readability or meant a new paragraph. No worries. You are right they don't break the paragraph in javadoc. Cheers, Paul On Tue, Dec 15, 2015 at 10:00 AM, Roger Riggs wrote: > Hi Paul, > > The credit/blame for the Cleaner doc is mine. > > On 12/15/2015 10:25 AM, Paul Benedict wrote: > > David, this needs editing. > > * The cleaning function is invoked after the object it is cleaning up > after it > * becomes phantom reachable, so it is important that the references and > values > * it needs do not prevent the object from becoming phantom reachable. > > 1) The "after it" looks like a leftover from an edit > 2) "becomes phantom reachable" after already "becoming phantom reachable" > needs clarification to make sense: > > Yes, this poorly worded. It has been simplified in the latest update. > > > My suggestion: > > * The cleaning function is invoked after the object it is cleaning becomes > * phantom reachable, so it is important that the object's references and > values > * do not prevent the object from remaining phantom reachable. > > PS: I noticed in the source that much of the documentation is written with > line breaks but without the

    tag. If you have a paragraph in mind, > perhaps you can remove the line breaks so it doesn't look like

    tags > were meant to be there but forgotten. > > Blank lines improve readability of the source; but should not appear to > break any paragraph. > Did I miss some? > > Thanks, Roger > > > > Cheers, > Paul > > On Tue, Dec 15, 2015 at 1:01 AM, David Holmes < > david.holmes at oracle.com> wrote: > >> PS. >> >> create(): can also throw SecurityException if not allowed to create/start >> threads. >> >> David >> >> On 10/12/2015 4:40 AM, Roger Riggs wrote: >> >>> Hi, >>> >>> The example is revised to caution about inner classes and lambdas. >>> >>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> Thanks, Roger >>> >>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>> >>>> Hi Chris, >>>> >>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>> >>>>> Peter, >>>>> >>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I think the only way to try to prevent such things is with a good >>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>> >>>>>> >>>>>> public static class CleanerExample implements AutoCloseable { >>>>>> >>>>>> private static final Cleaner cleaner = ...; // preferably a >>>>>> shared cleaner >>>>>> >>>>>> private final PrivateNativeResource pnr; >>>>>> >>>>>> private final Cleaner.Cleanable cleanable; >>>>>> >>>>>> public CleanerExample(args, ...) { >>>>>> >>>>>> // prepare captured state as local vars... >>>>>> PrivateNativeResource _pnr = ...; >>>>>> >>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>> // DON'T capture any instance fields with lambda >>>>>> since >>>>>> that would >>>>>> // capture 'this' and prevent it from becoming >>>>>> >>>>> >>>>> I assume that the WARNING should include anonymous inner classes too >>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>> >>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>> the IDE ;-) >>>>> >>>> >>>> 'this' only leaks to the 'referent' field of PhantomReference where by >>>> definition is not accessible. >>>> >>>> 'this' can become phantom-reachable before CleanerExample constructor >>>> ends. But this is harmless, because the code that may execute at that >>>> time does not access the object any more, so the object may be safely >>>> collected. >>>> >>>> Cleanup action can run at any time after registration even before >>>> CleanerExample constructor ends. But this is harmless too, because it >>>> only accesses PrivateNativeResource which is fully constructed before >>>> registration of cleanup action. >>>> >>>> I see no issues apart from IDE(s) not seeing no issues. >>>> >>>> Regards, Peter >>>> >>>> >>>>> -Chris. >>>>> >>>>> >>>>> phantom-reachable!!! >>>>>> _pnr.close(); >>>>>> }); >>>>>> >>>>>> this.pnr = _pnr; >>>>>> } >>>>>> >>>>>> public void close() { >>>>>> cleanable.clean(); >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>> >>> > > From Roger.Riggs at Oracle.com Tue Dec 15 16:31:50 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 11:31:50 -0500 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56695984.7030204@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> Message-ID: <56704076.8050203@Oracle.com> Hi Yvom, Minor comments: src/java.base/share/native/libjava/RandomAccessFile.c: - "length fail" might be clearer as "GetLength failed" src/java.base/unix/native/libjava/io_util_md.c: - Please add a comment before the define of FILE_OFFSET_BITS to indicate where it is used and why it is there. - BTW, are there any unintended side effects? Perhaps a different issue but perhaps 64 bit offsets should be used everywhere src/java.base/windows/native/libjava/io_util_md.c - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used elsewhere in the file BTW, Testing for invalid handle might be unnecessary since the call to GetFileSizeEx will fail if it is invalid, yielding the same result. Roger On 12/10/2015 5:52 AM, vyom wrote: > Hi All, > > Please review my changes for below bug. > > Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe > > Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ > > > This change ensure that length() does not temporarily changes the > file pointer and it will make sure that there is no race > condition in case of multi thread uses. > > Thanks, > Vyom > > > > From mandy.chung at oracle.com Tue Dec 15 17:15:30 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Dec 2015 09:15:30 -0800 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: > On Dec 15, 2015, at 4:00 AM, Chris Hegarty wrote: > > No new code here, just giving sun.misc.ProxyGenerator a more appropriate > location, in jdk.internal.reflect ( since it contains the code to generate a dynamic > proxy class for the java.lang.reflect.Proxy ). > > http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ > > Note: ProxyGenerator could be moved into java.lang.reflect, as a > package-private class, but I see no reason to move it into an exported > package, and a package that it not on the restricted package list. ProxyGenerator is only used by Proxy (it was used by other JDK code previously). I would prefer it moving to java.lang.reflect as package-private class in java.lang.reflect since we are moving it. Mandy From martinrb at google.com Tue Dec 15 17:25:52 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Dec 2015 09:25:52 -0800 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56704076.8050203@Oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> Message-ID: _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between translation units. It would be good to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made available via _LARGEFILE64_SOURCE. But that is also a JDK-wide job now, because every call to plain stat in the source code is broken on 32-bit systems with 64-bit inodes, which are becoming more common. I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job for build-dev, not core-libs-dev. On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs wrote: > Hi Yvom, > > Minor comments: > > src/java.base/share/native/libjava/RandomAccessFile.c: > - "length fail" might be clearer as "GetLength failed" > > src/java.base/unix/native/libjava/io_util_md.c: > > - Please add a comment before the define of FILE_OFFSET_BITS to indicate > where it is used and why it is there. > - BTW, are there any unintended side effects? > Perhaps a different issue but perhaps 64 bit offsets should be used > everywhere > > src/java.base/windows/native/libjava/io_util_md.c > - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used > elsewhere in the file > BTW, Testing for invalid handle might be unnecessary since the call to > GetFileSizeEx will fail > if it is invalid, yielding the same result. > > Roger > > > On 12/10/2015 5:52 AM, vyom wrote: >> >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >> >> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >> >> >> This change ensure that length() does not temporarily changes the file >> pointer and it will make sure that there is no race >> condition in case of multi thread uses. >> >> Thanks, >> Vyom >> >> >> >> > From martinrb at google.com Tue Dec 15 17:28:21 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Dec 2015 09:28:21 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <567037AA.30801@oracle.com> References: <567037AA.30801@oracle.com> Message-ID: Note that the semantics of stat and access may be subtly different, and that there are many calls to stat in the JDK sources, and they may all be broken on 32-bit systems. I just wrote elsewhere: _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between translation units. It would be good to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made available via _LARGEFILE64_SOURCE. But that is also a JDK-wide job now, because every call to plain stat in the source code is broken on 32-bit systems with 64-bit inodes, which are becoming more common. I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job for build-dev, not core-libs-dev. On Tue, Dec 15, 2015 at 7:54 AM, Kumar Srinivasan wrote: > Hello, > > Please review fix for: JDK-8115868 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > The background: > The launcher uses stat(2) to check for the existence of a file, > unfortunately > on 32-bit system with large file systems causes the inode storage to > overflow > causing the syscall to return EOVERFLOW. > > Solution: > * stat(2) replaced with access(3), in most cases. > * jbs is marked noreg-hard hard to replicate the problem > > Thanks > Kumar > > > > > From christian.thalinger at oracle.com Tue Dec 15 17:36:45 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Dec 2015 07:36:45 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <566FD940.4090608@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> Message-ID: <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> > On Dec 14, 2015, at 11:11 PM, Konstantin Shefov wrote: > > Hi Christian > > Thanks for reviewing, I have changed indents as you asked: > > http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. > > -Konstantin > > On 12/15/2015 06:23 AM, Christian Thalinger wrote: >> >>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>> >>> Hello >>> >>> Please review the new version on the patch. >>> >>> New webrev: >>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >> >> These newlines look ridiculous especially when it?s not even needed: >> >> + // Returns a class reference index for a method or a field. >> + public int getClassRefIndexAt >> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >> >> Either fix the indent or just add them like regular methods should look like. >> >>> >>> What has been changed: >>> 1. Added tests for the new added methods. >>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec ( https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140 ). >>> >>> Thanks >>> -Konstantin >>> >>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>> Coleen, >>>> Thanks for review >>>> >>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>> >>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>> I will add tests. >>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>> Hello >>>>>> >>>>>> Please, review modified webrev. >>>>>> >>>>>> I have added methods >>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>> >>>>>> I removed previously added method >>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>> >>>>>> New webrev: >>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>>> >>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>> Remi, >>>>>>> >>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>> >>>>>>> -Konstantin >>>>>>> >>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>> Hi Konstantin, >>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>> >>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>> >>>>>>>> cheers, >>>>>>>> R?mi >>>>>>>> >>>>>>>> ----- Mail original ----- >>>>>>>>> De: "Christian Thalinger" > >>>>>>>>> ?: "Konstantin Shefov" < konstantin.shefov at oracle.com > >>>>>>>>> Cc: "hotspot-dev developers" < hotspot-dev at openjdk.java.net >, core-libs-dev at openjdk.java.net >>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>> >>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>> >>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>> The following methods are suggested: >>>>>>>>>> >>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>> with the specified index >>>>>>>>>> >>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>> with the specified index >>>>>>>>>> >>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>> pool entry with the specified index >>>>>>>>>> >>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>> Webrev hotspot: >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Konstantin >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Tue Dec 15 18:18:40 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Dec 2015 10:18:40 -0800 Subject: Review Request for JDK-8145430: Fix typo in StackWalker javadoc Message-ID: diff --git a/src/java.base/share/classes/java/lang/StackWalker.java b/src/java.base/share/classes/java/lang/StackWalker.java --- a/src/java.base/share/classes/java/lang/StackWalker.java +++ b/src/java.base/share/classes/java/lang/StackWalker.java @@ -304,8 +304,8 @@ } /** - * Returns a {@code StackWalker} instance with the given {@ocde options} specifying - * the stack frame information it can access. If the given {@ocde options} + * Returns a {@code StackWalker} instance with the given {@code options} specifying + * the stack frame information it can access. If the given {@code options} * is empty, this {@code StackWalker} is configured to skip all * {@linkplain Option#SHOW_HIDDEN_FRAMES hidden frames} and no * {@linkplain Option#RETAIN_CLASS_REFERENCE class reference} is retained. From daniel.fuchs at oracle.com Tue Dec 15 18:29:07 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Dec 2015 19:29:07 +0100 Subject: Review Request for JDK-8145430: Fix typo in StackWalker javadoc In-Reply-To: References: Message-ID: <56705BF3.5030208@oracle.com> On 15/12/15 19:18, Mandy Chung wrote: > diff --git a/src/java.base/share/classes/java/lang/StackWalker.java b/src/java.base/share/classes/java/lang/StackWalker.java > --- a/src/java.base/share/classes/java/lang/StackWalker.java > +++ b/src/java.base/share/classes/java/lang/StackWalker.java > @@ -304,8 +304,8 @@ > } > > /** > - * Returns a {@code StackWalker} instance with the given {@ocde options} specifying > - * the stack frame information it can access. If the given {@ocde options} > + * Returns a {@code StackWalker} instance with the given {@code options} specifying > + * the stack frame information it can access. If the given {@code options} > * is empty, this {@code StackWalker} is configured to skip all > * {@linkplain Option#SHOW_HIDDEN_FRAMES hidden frames} and no > * {@linkplain Option#RETAIN_CLASS_REFERENCE class reference} is retained. > Looks good :-) -- daniel From joe.darcy at oracle.com Tue Dec 15 18:30:09 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 15 Dec 2015 10:30:09 -0800 Subject: Review Request for JDK-8145430: Fix typo in StackWalker javadoc In-Reply-To: <56705BF3.5030208@oracle.com> References: <56705BF3.5030208@oracle.com> Message-ID: <56705C31.5050108@oracle.com> +1 On 12/15/2015 10:29 AM, Daniel Fuchs wrote: > On 15/12/15 19:18, Mandy Chung wrote: >> diff --git a/src/java.base/share/classes/java/lang/StackWalker.java >> b/src/java.base/share/classes/java/lang/StackWalker.java >> --- a/src/java.base/share/classes/java/lang/StackWalker.java >> +++ b/src/java.base/share/classes/java/lang/StackWalker.java >> @@ -304,8 +304,8 @@ >> } >> >> /** >> - * Returns a {@code StackWalker} instance with the given {@ocde >> options} specifying >> - * the stack frame information it can access. If the given >> {@ocde options} >> + * Returns a {@code StackWalker} instance with the given {@code >> options} specifying >> + * the stack frame information it can access. If the given >> {@code options} >> * is empty, this {@code StackWalker} is configured to skip all >> * {@linkplain Option#SHOW_HIDDEN_FRAMES hidden frames} and no >> * {@linkplain Option#RETAIN_CLASS_REFERENCE class reference} >> is retained. >> > > Looks good :-) > > -- daniel From henry.jen at oracle.com Tue Dec 15 18:36:08 2015 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 15 Dec 2015 10:36:08 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <567037AA.30801@oracle.com> References: <567037AA.30801@oracle.com> Message-ID: Changes looks reasonable to me. Cheers, Henry > On Dec 15, 2015, at 7:54 AM, Kumar Srinivasan wrote: > > Hello, > > Please review fix for: JDK-8115868 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > The background: > The launcher uses stat(2) to check for the existence of a file, unfortunately > on 32-bit system with large file systems causes the inode storage to overflow > causing the syscall to return EOVERFLOW. > > Solution: > * stat(2) replaced with access(3), in most cases. > * jbs is marked noreg-hard hard to replicate the problem > > Thanks > Kumar > > > > > From chris.hegarty at oracle.com Tue Dec 15 18:41:51 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Dec 2015 18:41:51 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: On 15 Dec 2015, at 17:15, Mandy Chung wrote: > >> On Dec 15, 2015, at 4:00 AM, Chris Hegarty wrote: >> >> No new code here, just giving sun.misc.ProxyGenerator a more appropriate >> location, in jdk.internal.reflect ( since it contains the code to generate a dynamic >> proxy class for the java.lang.reflect.Proxy ). >> >> http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ >> >> Note: ProxyGenerator could be moved into java.lang.reflect, as a >> package-private class, but I see no reason to move it into an exported >> package, and a package that it not on the restricted package list. > > ProxyGenerator is only used by Proxy (it was used by other JDK code previously). Ah ok. That somewhat explains its current location in sun.misc. > I would prefer it moving to java.lang.reflect as package-private class in java.lang.reflect since we are moving it. I have no objection. Webrev updated in-place. -Chris. From Roger.Riggs at Oracle.com Tue Dec 15 18:47:00 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 13:47:00 -0500 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: <56706024.60309@Oracle.com> +1 On 12/15/2015 1:41 PM, Chris Hegarty wrote: > On 15 Dec 2015, at 17:15, Mandy Chung wrote: > >>> On Dec 15, 2015, at 4:00 AM, Chris Hegarty wrote: >>> >>> No new code here, just giving sun.misc.ProxyGenerator a more appropriate >>> location, in jdk.internal.reflect ( since it contains the code to generate a dynamic >>> proxy class for the java.lang.reflect.Proxy ). >>> >>> http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/ >>> >>> Note: ProxyGenerator could be moved into java.lang.reflect, as a >>> package-private class, but I see no reason to move it into an exported >>> package, and a package that it not on the restricted package list. >> ProxyGenerator is only used by Proxy (it was used by other JDK code previously). > Ah ok. That somewhat explains its current location in sun.misc. > >> I would prefer it moving to java.lang.reflect as package-private class in java.lang.reflect since we are moving it. > I have no objection. Webrev updated in-place. > > -Chris. > From martinrb at google.com Tue Dec 15 18:55:40 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Dec 2015 10:55:40 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <567037AA.30801@oracle.com> References: <567037AA.30801@oracle.com> Message-ID: OK, now doing an actual review ... this does look like a clear improvement! From joel.borggren.franck at gmail.com Tue Dec 15 18:56:29 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Tue, 15 Dec 2015 18:56:29 +0000 Subject: General question: sun package -> jdk package? In-Reply-To: References: Message-ID: Hi Chris, I'm somewhat surprised to see ReflectionFactory on that list. Can you share more details around its external use? cheers /Joel On Tue, 15 Dec 2015 at 16:15 Chris Hegarty wrote: > Paul, > > I cannot address your general question, but I guess it might be motivated > by some of my recent preparatory work for JEP 260 [1]. This JEP proposes > to expose a small number of critical API?s that are in the sun.misc and > sun.reflect namespace. Anything not deemed critical should be removed > from these packages, since it should not be exposed. There is also a > significant amount of technical debt in these packages. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > > On 15 Dec 2015, at 15:09, Paul Benedict wrote: > > > I have a general question prompted by the many classes moved from sun.* > to > > jdk.*. Once JDK 9 delivers on the Module System and internals are no > longer > > exposed, is it planned to eventually migrate away from the sun.* legacy > > namespace in later JDK versions? > > > > Cheers, > > Paul > > From mandy.chung at oracle.com Tue Dec 15 19:26:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Dec 2015 11:26:55 -0800 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: > On Dec 15, 2015, at 10:41 AM, Chris Hegarty wrote: > > > Webrev updated in-place. Thank you for moving it to java.lang.reflect. Formatting nit: since you make generateProxyClass method package-private, line 323 & 335-336 needs to be adjusted to align with the line above. Thanks for renaming the system property. Do you mind renaming it to ?jdk.proxy.ProxyGenerator.saveGeneratedFiles? as ?java.? may be interpreted as standard system property? ?jdk.proxy? may not be the best candidate that we can revisit later. Mandy From chris.hegarty at oracle.com Tue Dec 15 19:39:13 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Dec 2015 19:39:13 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: On 15 Dec 2015, at 19:26, Mandy Chung wrote: >> On Dec 15, 2015, at 10:41 AM, Chris Hegarty wrote: >> >> >> Webrev updated in-place. > > Thank you for moving it to java.lang.reflect. > > Formatting nit: since you make generateProxyClass method package-private, line 323 & 335-336 needs to be adjusted to align with the line above. > > Thanks for renaming the system property. Do you mind renaming it to ?jdk.proxy.ProxyGenerator.saveGeneratedFiles? as ?java.? may be interpreted as standard system property? ?jdk.proxy? may not be the best candidate that we can revisit later. I?ll do this before pushing. Thanks, -Chris. From mark.reinhold at oracle.com Tue Dec 15 19:48:22 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 15 Dec 2015 11:48:22 -0800 Subject: General question: sun package -> jdk package? In-Reply-To: References: Message-ID: <20151215114822.636862@eggemoggin.niobe.net> 2015/12/15 7:09 -0800, Paul Benedict : > I have a general question prompted by the many classes moved from sun.* to > jdk.*. Once JDK 9 delivers on the Module System and internals are no longer > exposed, is it planned to eventually migrate away from the sun.* legacy > namespace in later JDK versions? There's no specific intent right now to remove or rename all the existing internal sun.* packages in any particular timeframe. For a while now new JDK-specific packages, internal or otherwise, have been named jdk.* rather than {sun,com.sun}.*, and we intend to continue that practice going forward. Why do you ask? - Mark From pbenedict at apache.org Tue Dec 15 19:51:53 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 15 Dec 2015 13:51:53 -0600 Subject: General question: sun package -> jdk package? In-Reply-To: <20151215114822.636862@eggemoggin.niobe.net> References: <20151215114822.636862@eggemoggin.niobe.net> Message-ID: I only asked out of curiosity. There seemed to be a migration trend, but I didn't know what the intent was. I understand a name is just a name, but I personally do like seeing the vestiges of "sun" being replaced with something more universal. Cheers, Paul On Tue, Dec 15, 2015 at 1:48 PM, wrote: > 2015/12/15 7:09 -0800, Paul Benedict : > > I have a general question prompted by the many classes moved from sun.* > to > > jdk.*. Once JDK 9 delivers on the Module System and internals are no > longer > > exposed, is it planned to eventually migrate away from the sun.* legacy > > namespace in later JDK versions? > > There's no specific intent right now to remove or rename all the > existing internal sun.* packages in any particular timeframe. > > For a while now new JDK-specific packages, internal or otherwise, > have been named jdk.* rather than {sun,com.sun}.*, and we intend > to continue that practice going forward. > > Why do you ask? > > - Mark > From Alan.Bateman at oracle.com Tue Dec 15 19:52:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Dec 2015 19:52:19 +0000 Subject: RFR [9] Moved sun.misc.ProxyGenerator to jdk.internal.reflect In-Reply-To: References: <9CAA0C0B-5D38-40AC-9FD9-D646651A7190@oracle.com> Message-ID: <56706F73.8020905@oracle.com> On 15/12/2015 18:41, Chris Hegarty wrote: > : > >> I would prefer it moving to java.lang.reflect as package-private class in java.lang.reflect since we are moving it. > I have no objection. Webrev updated in-place. > > java.lang.reflect with package access is okay with me too. -Alan From martinrb at google.com Tue Dec 15 20:23:50 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Dec 2015 12:23:50 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <566F9ABB.9050804@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> Message-ID: On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: > On 15/12/2015 6:53 AM, Martin Buchholz wrote: >> >> Thread local storage is trouble. >> >> java stack sizes should be in _addition_ to any OS overhead, which >> includes TLS. > > > TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing > about that in "ELF Handling for Thread Local Storage". That is why I want to > know more about the test, the compilation environment and the execution > environment. I have also struggled to understand "ELF Handling for Thread Local Storage". > Do you mean that the value specified at the Java level should be rounded up > to accommodate guard pages etc at the native level? Yes, I think so. All of the -Xss size should be available for actual stack frames. From jeremymanson at google.com Tue Dec 15 22:03:04 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 15 Dec 2015 14:03:04 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <566FC07C.8010509@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> Message-ID: On Mon, Dec 14, 2015 at 11:25 PM, David Holmes wrote: > On 15/12/2015 4:32 PM, Jeremy Manson wrote: > >> David: What the spec says and what glibc does are two different things: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=11787 >> >> We have an internal Google patch to compensate for this. Nasty stuff. >> > > Nasty isn't even the right word - this is just ludicrous! And the bug has > just languished even though they were going to fix it years ago!!!!! And I > also cried when I saw the part finally recognizing that glibc does the > wrong thing by taking the guard pages from the requested stack size! > > To me this just screams don't use TLS on linux except for trivially small > data structures, or else use static-TLS. > > Which brings me back to this test - make the variable static! > > Thanks Jeremy. I'm thoroughly depressed now. > Happy to oblige. :) The really depressing part is that there is no standard way of figuring out how much TLS you need so that you can compensate. Note that the Rust people are trying to introspect into glibc to figure it out. We roll our own glibc, so at least we can export something that we guarantee can work. You would probably want to avoid both of these situations for the JDK. I expect the official answer from you guys about this is going to end up being "bump your Xss if you really care", which is deeply sad. Jeremy From ecki at zusammenkunft.net Tue Dec 15 22:12:50 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 15 Dec 2015 23:12:50 +0100 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: References: <567037AA.30801@oracle.com> Message-ID: <20151215231250.00004401.ecki@zusammenkunft.net> Hello, I always like it when access() is used instead of stat() magic. I noticed that the new ProgramExists in java_md_common.c does not anymore reject directories (which are typically executable). Not sure it this matters or is intentional, it is a change in semantic. Is there an exising typo in args.c#366 ("size i_s_ fine") which could be fixed in the patch as well? I would simply remove the stat code from expandArgFile, the fallback code is only slow in the unlikely case of rejected large files so there is no need to attempt the stat() call. Would remove 10 lines. Gruss Bernd Am Tue, 15 Dec 2015 10:36:08 -0800 schrieb Henry Jen : > Changes looks reasonable to me. > > Cheers, > Henry > > > > On Dec 15, 2015, at 7:54 AM, Kumar Srinivasan > > wrote: > > > > Hello, > > > > Please review fix for: JDK-8115868 > > > > The webrev is here: > > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > > > The background: > > The launcher uses stat(2) to check for the existence of a file, > > unfortunately on 32-bit system with large file systems causes the > > inode storage to overflow causing the syscall to return EOVERFLOW. > > > > Solution: > > * stat(2) replaced with access(3), in most cases. > > * jbs is marked noreg-hard hard to replicate the problem > > > > Thanks > > Kumar > > > > > > > > > > > From peter.levart at gmail.com Tue Dec 15 22:38:51 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Dec 2015 23:38:51 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5668759A.1070204@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> Message-ID: <5670967B.4050209@gmail.com> Hi Roger, Just one thing about implementation: Since the type exposed to user is Cleaner.Cleanable that has only a single method clean(), it would be good if the implementation class (CleanerImpl.PhantomCleanableRef) overrode CleanerImpl.PhantomCleanable.clear() method and threw UnsupportedOperationException, otherwise users will be tempted to cast the returned Cleaner.Cleanable to Reference and invoke clear() method to de-register cleanup action without invoking it. This is the only remaining public Reference method that is not disabled this way. Regards, Peter On 12/09/2015 07:40 PM, Roger Riggs wrote: > Hi, > > The example is revised to caution about inner classes and lambdas. > > [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html > > Thanks, Roger > > On 12/9/2015 11:04 AM, Peter Levart wrote: >> Hi Chris, >> >> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>> Peter, >>> >>> On 09/12/15 07:05, Peter Levart wrote: >>>> Hi, >>>> >>>> I think the only way to try to prevent such things is with a good >>>> example in javadoc that "screams" of possible miss-usages. >>>> >>>> >>>> public static class CleanerExample implements AutoCloseable { >>>> >>>> private static final Cleaner cleaner = ...; // preferably a >>>> shared cleaner >>>> >>>> private final PrivateNativeResource pnr; >>>> >>>> private final Cleaner.Cleanable cleanable; >>>> >>>> public CleanerExample(args, ...) { >>>> >>>> // prepare captured state as local vars... >>>> PrivateNativeResource _pnr = ...; >>>> >>>> this.cleanable = cleaner.register(this, () -> { >>>> // DON'T capture any instance fields with lambda >>>> since >>>> that would >>>> // capture 'this' and prevent it from becoming >>> >>> I assume that the WARNING should include anonymous inner classes too >>> ( which I expect are quite common, though less now with lambda ) ? >>> >>> Is "leaking" 'this' in a constructor a potential issue with respect >>> to the visibility of pnr? As well as causing red-squiggly lines in >>> the IDE ;-) >> >> 'this' only leaks to the 'referent' field of PhantomReference where >> by definition is not accessible. >> >> 'this' can become phantom-reachable before CleanerExample constructor >> ends. But this is harmless, because the code that may execute at that >> time does not access the object any more, so the object may be safely >> collected. >> >> Cleanup action can run at any time after registration even before >> CleanerExample constructor ends. But this is harmless too, because it >> only accesses PrivateNativeResource which is fully constructed before >> registration of cleanup action. >> >> I see no issues apart from IDE(s) not seeing no issues. >> >> Regards, Peter >> >>> >>> -Chris. >>> >>> >>>> phantom-reachable!!! >>>> _pnr.close(); >>>> }); >>>> >>>> this.pnr = _pnr; >>>> } >>>> >>>> public void close() { >>>> cleanable.clean(); >>>> } >>>> >>>> >>>> Regards, Peter >>>> >> > From Roger.Riggs at Oracle.com Tue Dec 15 22:48:27 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 15 Dec 2015 17:48:27 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5670967B.4050209@gmail.com> References: <560D3F61.6040607@Oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> Message-ID: <567098BB.4050001@Oracle.com> Hi Peter, That will break up clearing the ref when the Cleanable is explicitly cleaned. Reference.clear() needs to be called from Cleanable.clean(). it might be nice to block that but to do so we'd need to go back to separate objects for the Reference and the Cleanable and we worked hard to get to a single object. Roger On 12/15/2015 5:38 PM, Peter Levart wrote: > Hi Roger, > > Just one thing about implementation: > > Since the type exposed to user is Cleaner.Cleanable that has only a > single method clean(), it would be good if the implementation class > (CleanerImpl.PhantomCleanableRef) overrode > CleanerImpl.PhantomCleanable.clear() method and threw > UnsupportedOperationException, otherwise users will be tempted to cast > the returned Cleaner.Cleanable to Reference and invoke clear() method > to de-register cleanup action without invoking it. This is the only > remaining public Reference method that is not disabled this way. > > Regards, Peter > > On 12/09/2015 07:40 PM, Roger Riggs wrote: >> Hi, >> >> The example is revised to caution about inner classes and lambdas. >> >> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >> >> Thanks, Roger >> >> On 12/9/2015 11:04 AM, Peter Levart wrote: >>> Hi Chris, >>> >>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>> Peter, >>>> >>>> On 09/12/15 07:05, Peter Levart wrote: >>>>> Hi, >>>>> >>>>> I think the only way to try to prevent such things is with a good >>>>> example in javadoc that "screams" of possible miss-usages. >>>>> >>>>> >>>>> public static class CleanerExample implements AutoCloseable { >>>>> >>>>> private static final Cleaner cleaner = ...; // preferably a >>>>> shared cleaner >>>>> >>>>> private final PrivateNativeResource pnr; >>>>> >>>>> private final Cleaner.Cleanable cleanable; >>>>> >>>>> public CleanerExample(args, ...) { >>>>> >>>>> // prepare captured state as local vars... >>>>> PrivateNativeResource _pnr = ...; >>>>> >>>>> this.cleanable = cleaner.register(this, () -> { >>>>> // DON'T capture any instance fields with lambda >>>>> since >>>>> that would >>>>> // capture 'this' and prevent it from becoming >>>> >>>> I assume that the WARNING should include anonymous inner classes too >>>> ( which I expect are quite common, though less now with lambda ) ? >>>> >>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>> the IDE ;-) >>> >>> 'this' only leaks to the 'referent' field of PhantomReference where >>> by definition is not accessible. >>> >>> 'this' can become phantom-reachable before CleanerExample >>> constructor ends. But this is harmless, because the code that may >>> execute at that time does not access the object any more, so the >>> object may be safely collected. >>> >>> Cleanup action can run at any time after registration even before >>> CleanerExample constructor ends. But this is harmless too, because >>> it only accesses PrivateNativeResource which is fully constructed >>> before registration of cleanup action. >>> >>> I see no issues apart from IDE(s) not seeing no issues. >>> >>> Regards, Peter >>> >>>> >>>> -Chris. >>>> >>>> >>>>> phantom-reachable!!! >>>>> _pnr.close(); >>>>> }); >>>>> >>>>> this.pnr = _pnr; >>>>> } >>>>> >>>>> public void close() { >>>>> cleanable.clean(); >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>> >> > From peter.levart at gmail.com Tue Dec 15 23:01:12 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Dec 2015 00:01:12 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <567098BB.4050001@Oracle.com> References: <560D3F61.6040607@Oracle.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> Message-ID: <56709BB8.3070809@gmail.com> On 12/15/2015 11:48 PM, Roger Riggs wrote: > Hi Peter, > > That will break up clearing the ref when the Cleanable is explicitly > cleaned. > Reference.clear() needs to be called from Cleanable.clean(). From PhantomCleanable (the superclass of PhantomCleanableRef): 253 @Override 254 public final void clean() { 255 if (remove()) { 256 super.clear(); 257 performCleanup(); 258 } 259 } 260 261 /** 262 * Unregister this PhantomCleanable and clear the reference. 263 * Due to inherent concurrency, {@link #performCleanup()} may still be invoked. 264 */ 265 @Override 266 public final void clear() { 267 if (remove()) { 268 super.clear(); 269 } 270 } ... clean() calls super.clear(), which is "invokespecial" (not a virtual dispatch). Regards, Peter > > it might be nice to block that but to do so we'd need to go back to > separate objects > for the Reference and the Cleanable and we worked hard to get to a > single object. > > Roger > > > On 12/15/2015 5:38 PM, Peter Levart wrote: >> Hi Roger, >> >> Just one thing about implementation: >> >> Since the type exposed to user is Cleaner.Cleanable that has only a >> single method clean(), it would be good if the implementation class >> (CleanerImpl.PhantomCleanableRef) overrode >> CleanerImpl.PhantomCleanable.clear() method and threw >> UnsupportedOperationException, otherwise users will be tempted to >> cast the returned Cleaner.Cleanable to Reference and invoke clear() >> method to de-register cleanup action without invoking it. This is the >> only remaining public Reference method that is not disabled this way. >> >> Regards, Peter >> >> On 12/09/2015 07:40 PM, Roger Riggs wrote: >>> Hi, >>> >>> The example is revised to caution about inner classes and lambdas. >>> >>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>> >>> Thanks, Roger >>> >>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>>> Hi Chris, >>>> >>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>>> Peter, >>>>> >>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>>> Hi, >>>>>> >>>>>> I think the only way to try to prevent such things is with a good >>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>> >>>>>> >>>>>> public static class CleanerExample implements AutoCloseable { >>>>>> >>>>>> private static final Cleaner cleaner = ...; // preferably a >>>>>> shared cleaner >>>>>> >>>>>> private final PrivateNativeResource pnr; >>>>>> >>>>>> private final Cleaner.Cleanable cleanable; >>>>>> >>>>>> public CleanerExample(args, ...) { >>>>>> >>>>>> // prepare captured state as local vars... >>>>>> PrivateNativeResource _pnr = ...; >>>>>> >>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>> // DON'T capture any instance fields with lambda >>>>>> since >>>>>> that would >>>>>> // capture 'this' and prevent it from becoming >>>>> >>>>> I assume that the WARNING should include anonymous inner classes too >>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>> >>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>> the IDE ;-) >>>> >>>> 'this' only leaks to the 'referent' field of PhantomReference where >>>> by definition is not accessible. >>>> >>>> 'this' can become phantom-reachable before CleanerExample >>>> constructor ends. But this is harmless, because the code that may >>>> execute at that time does not access the object any more, so the >>>> object may be safely collected. >>>> >>>> Cleanup action can run at any time after registration even before >>>> CleanerExample constructor ends. But this is harmless too, because >>>> it only accesses PrivateNativeResource which is fully constructed >>>> before registration of cleanup action. >>>> >>>> I see no issues apart from IDE(s) not seeing no issues. >>>> >>>> Regards, Peter >>>> >>>>> >>>>> -Chris. >>>>> >>>>> >>>>>> phantom-reachable!!! >>>>>> _pnr.close(); >>>>>> }); >>>>>> >>>>>> this.pnr = _pnr; >>>>>> } >>>>>> >>>>>> public void close() { >>>>>> cleanable.clean(); >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Dec 16 05:35:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2015 15:35:54 +1000 Subject: Need help to understand TLS behavior In-Reply-To: References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> Message-ID: <5670F83A.3050303@oracle.com> On 16/12/2015 6:23 AM, Martin Buchholz wrote: > On Mon, Dec 14, 2015 at 8:44 PM, David Holmes wrote: >> On 15/12/2015 6:53 AM, Martin Buchholz wrote: >>> >>> Thread local storage is trouble. >>> >>> java stack sizes should be in _addition_ to any OS overhead, which >>> includes TLS. >> >> >> TLS shouldn't be coming out the stack of the thread AFAIK - I see nothing >> about that in "ELF Handling for Thread Local Storage". That is why I want to >> know more about the test, the compilation environment and the execution >> environment. > > I have also struggled to understand "ELF Handling for Thread Local Storage". > >> Do you mean that the value specified at the Java level should be rounded up >> to accommodate guard pages etc at the native level? > > Yes, I think so. All of the -Xss size should be available for actual > stack frames. Alas no nice way to know what that value should be. I cringe at taking the same approach that Rust had to do. It's kind of interesting we've never hit this before. It's very frustrating that we hit it on a thread that couldn't care less about the TLS variables that have claimed space on its stack. I guess they need a notion of "inheritable thread-locals" too. David From david.holmes at oracle.com Wed Dec 16 05:40:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2015 15:40:06 +1000 Subject: Need help to understand TLS behavior In-Reply-To: References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> Message-ID: <5670F936.7010409@oracle.com> On 16/12/2015 8:03 AM, Jeremy Manson wrote: > > > On Mon, Dec 14, 2015 at 11:25 PM, David Holmes > wrote: > > On 15/12/2015 4:32 PM, Jeremy Manson wrote: > > David: What the spec says and what glibc does are two different > things: > > https://sourceware.org/bugzilla/show_bug.cgi?id=11787 > > We have an internal Google patch to compensate for this. Nasty > stuff. > > > Nasty isn't even the right word - this is just ludicrous! And the > bug has just languished even though they were going to fix it years > ago!!!!! And I also cried when I saw the part finally recognizing > that glibc does the wrong thing by taking the guard pages from the > requested stack size! > > To me this just screams don't use TLS on linux except for trivially > small data structures, or else use static-TLS. > > Which brings me back to this test - make the variable static! > > Thanks Jeremy. I'm thoroughly depressed now. > > > Happy to oblige. :) > > The really depressing part is that there is no standard way of figuring > out how much TLS you need so that you can compensate. Note that the > Rust people are trying to introspect into glibc to figure it out. We > roll our own glibc, so at least we can export something that we > guarantee can work. You would probably want to avoid both of these > situations for the JDK. Definitely do not want to roll our own glibc :) The Rust approach is unappealing but perhaps doable - I'm not sure what impact it would have with regard to build-time versus run-time dependencies. > I expect the official answer from you guys about this is going to end up > being "bump your Xss if you really care", which is deeply sad. As a point fix a way to change the stack size of the process reaper thread might suffice. But that is a band-aid. I can imagine bugs of the form "when we run our Java code stand-alone it runs fine, but as soon as we embed the JVM in our own application front-end it fails with StackOverflowErrors everywhere". :( David > Jeremy From mikael.gerdin at oracle.com Wed Dec 16 08:24:46 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Dec 2015 09:24:46 +0100 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <567037AA.30801@oracle.com> References: <567037AA.30801@oracle.com> Message-ID: <56711FCE.5030909@oracle.com> Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: > Hello, > > Please review fix for: JDK-8115868 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to comment on the actual code changes I don't consider this a code review but I looked at the diffs and they make sense to me. I have however tested this fix and verified that it resolves the issues in the launcher. /Mikael > > The background: > The launcher uses stat(2) to check for the existence of a file, > unfortunately > on 32-bit system with large file systems causes the inode storage to > overflow > causing the syscall to return EOVERFLOW. > > Solution: > * stat(2) replaced with access(3), in most cases. > * jbs is marked noreg-hard hard to replicate the problem > > Thanks > Kumar > > > > > From vyom.tewari at oracle.com Wed Dec 16 08:56:06 2015 From: vyom.tewari at oracle.com (vyom) Date: Wed, 16 Dec 2015 14:26:06 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56704076.8050203@Oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> Message-ID: <56712726.806@oracle.com> Hi All, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ ). I incorporated the review comments by Roger Riggs. Thanks, Vyom On Tuesday 15 December 2015 10:01 PM, Roger Riggs wrote: > Hi Yvom, > > Minor comments: > > src/java.base/share/native/libjava/RandomAccessFile.c: > - "length fail" might be clearer as "GetLength failed" > > src/java.base/unix/native/libjava/io_util_md.c: > > - Please add a comment before the define of FILE_OFFSET_BITS to > indicate where it is used and why it is there. > - BTW, are there any unintended side effects? > Perhaps a different issue but perhaps 64 bit offsets should be used > everywhere > > src/java.base/windows/native/libjava/io_util_md.c > - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used > elsewhere in the file > BTW, Testing for invalid handle might be unnecessary since the call > to GetFileSizeEx will fail > if it is invalid, yielding the same result. > > Roger > > On 12/10/2015 5:52 AM, vyom wrote: >> Hi All, >> >> Please review my changes for below bug. >> >> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >> >> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >> >> >> This change ensure that length() does not temporarily changes the >> file pointer and it will make sure that there is no race >> condition in case of multi thread uses. >> >> Thanks, >> Vyom >> >> >> >> > From joel.borggren.franck at gmail.com Wed Dec 16 09:15:30 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Wed, 16 Dec 2015 09:15:30 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: <566F1C72.7010001@oracle.com> References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> <5669EC2A.1030308@oracle.com> <566F1C72.7010001@oracle.com> Message-ID: Sounds good. I'll ping someone in my time zone to check the status of the ccc and push once it is approved. Thanks for the review Cheers /Joel On m?n 14 dec. 2015 at 20:45 joe darcy wrote: > Hi Joel, > > Revised ccc request finalized for current version of the spec; should be > approved in a day or two. > > Once that is approved, I think the current version can be pushed, enabling > the refactorings you've alluded to to occur later. > > Thanks, > > -Joe > > > On 12/13/2015 12:26 PM, Joel Borggr?n-Franck wrote: > > Hi Joe, > > Thanks for the comments, > > On Thu, 10 Dec 2015 at 22:18 joe darcy wrote: > >> Hi Joel, >> >> On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: >> >> Question, is it better to remove the throws clauses for the cases that >> return null? >> >> >> I think so; they aren't applicable in those case and it is fine to remove >> exceptions in subtypes of course. >> >> > Done. > > >> Please also add @Override annotations to the methods in the subtypes as a >> check that a new method is not accidentally being declared. >> >> > Doh! Fixed. > >> >> New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ >> Diff of patch 01 and patch 02 (a diff-diff): >> http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch >> >> >> >> Please add an @implSpec note in AnnotatedType saying that "this >> implementation returns null", or words to that effect. >> >> > Done. > > >> Shouldn't some of the implementation overrides in >> AnnotatedTypeFactory.java which throw null now be removed? Ah, I see the >> BaseImpl type is in the way. Is there an easy way to refactor that? >> >> > I think it deserves a separate commit. I have another bugfix lined up, > then I plan to refactor refactor the code a bit and clean up and improve > testing. > > >> (I'll take care of the ccc changes once the new spec is finalized.) >> >> > Thanks! > > New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.03/ > Delta vs 01: http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v3.patch > > cheers > /Joel > > > From mikael.gerdin at oracle.com Wed Dec 16 09:24:06 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Dec 2015 10:24:06 +0100 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <56711FCE.5030909@oracle.com> References: <567037AA.30801@oracle.com> <56711FCE.5030909@oracle.com> Message-ID: <56712DB6.9020102@oracle.com> On 2015-12-16 09:24, Mikael Gerdin wrote: > Hi Kumar, > > On 2015-12-15 16:54, Kumar Srinivasan wrote: >> Hello, >> >> Please review fix for: JDK-8115868 >> >> The webrev is here: >> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > Since I don't feel qualified to comment on the actual code changes I > don't consider this a code review but I looked at the diffs and they > make sense to me. > > I have however tested this fix and verified that it resolves the issues > in the launcher. And as for the changes required for the VM, would it be appropriate to clone 8115868 and move it to hotspot/runtime instead of pushing the VM fix under the same bug number? /Mikael > > /Mikael > >> >> The background: >> The launcher uses stat(2) to check for the existence of a file, >> unfortunately >> on 32-bit system with large file systems causes the inode storage to >> overflow >> causing the syscall to return EOVERFLOW. >> >> Solution: >> * stat(2) replaced with access(3), in most cases. >> * jbs is marked noreg-hard hard to replicate the problem >> >> Thanks >> Kumar >> >> >> >> >> > From aph at redhat.com Wed Dec 16 09:34:49 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Dec 2015 09:34:49 +0000 Subject: Need help to understand TLS behavior In-Reply-To: <5670F83A.3050303@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <5670F83A.3050303@oracle.com> Message-ID: <56713039.9060305@redhat.com> On 16/12/15 05:35, David Holmes wrote: > It's kind of interesting we've never hit this before. It's very > frustrating that we hit it on a thread that couldn't care less about > the TLS variables that have claimed space on its stack. I guess they > need a notion of "inheritable thread-locals" too. I think we're rather looking at abuse of TLS here. The obvious right way to use TLS is the way we do it in HotSpot: we have a base pointer to everything that is thread-local. So while this situation is a pain, the right answer to people who want to allocate a big block of TLS is "Don't do that, then." And yes, I know that we have no control over people who launch Java from their own applications. So it's a pain for us, and I am reaching out to glibc maintainers here at Red Hat. Andrew. From konstantin.shefov at oracle.com Wed Dec 16 11:13:41 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 16 Dec 2015 14:13:41 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> Message-ID: <56714765.5010009@oracle.com> Christian I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ -Konstantin On 12/15/2015 08:36 PM, Christian Thalinger wrote: > >> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >> > >> wrote: >> >> Hi Christian >> >> Thanks for reviewing, I have changed indents as you asked: >> >> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >> > > Thanks. I?m still not comfortable with the enum. It would be great > if we could get the values from the VM like in JVMCI: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 > > but that would be overkill here. But I would like to see the enum > entries take the integer values as arguments, like here: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 > > and either do a simple linear search to find the entry or build up a > table like the HotSpotConstantPool example above. > >> >> -Konstantin >> >> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>> >>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >>>> >>> > wrote: >>>> >>>> Hello >>>> >>>> Please review the new version on the patch. >>>> >>>> New webrev: >>>> Webrev hotspot: >>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>> >>>> Webrev jdk: >>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>> >>> >>> These newlines look ridiculous especially when it?s not even needed: >>> >>> + // Returns a class reference index for a method or a field. >>> + public int getClassRefIndexAt >>> + (int index) { return >>> getClassRefIndexAt0 (constantPoolOop, index); } >>> >>> Either fix the indent or just add them like regular methods should >>> look like. >>> >>>> >>>> What has been changed: >>>> 1. Added tests for the new added methods. >>>> 2. Removed CP tag codes 100 - 105 from being passed to java and >>>> left only codes from the open JVM spec >>>> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>> >>>> Thanks >>>> -Konstantin >>>> >>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>> Coleen, >>>>> Thanks for review >>>>> >>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>> >>>>>> I have a couple preliminary comments. First, there are no tests >>>>>> added with all this new functionality. Tests should be added >>>>>> with the functionality changeset, not promised afterward. >>>>> I will add tests. >>>>>> Secondly, I do not like that JDK code knows the implementation >>>>>> details of the JVM's constant pool tags. These should be only >>>>>> for internal use. >>>>> The package "sun.reflect" is for internal use only, so it >>>>> shouldn?t be a problem. >>>>>> My third comment is that I haven't looked carefully at this >>>>>> constant pool implementation but it seems very unsafe if the >>>>>> class is redefined and relies on an implementation detail in the >>>>>> JVM that can change. I will have more comments once I look more >>>>>> at the jvmti specification. >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>> Hello >>>>>>> >>>>>>> Please, review modified webrev. >>>>>>> >>>>>>> I have added methods >>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry >>>>>>> index from a method, field or indy entry index; >>>>>>> getClassRefIndexAt(int index) - to get class entry index from a >>>>>>> method or field entry index; >>>>>>> >>>>>>> I removed previously added method >>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>> >>>>>>> New webrev: >>>>>>> Webrev hotspot: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>> >>>>>>> Webrev jdk: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> -Konstantin >>>>>>> >>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>> Remi, >>>>>>>> >>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>> May be it also has sense to make a method >>>>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>>>> name-and-type entry index for methods also. >>>>>>>> >>>>>>>> -Konstantin >>>>>>>> >>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>> Hi Konstantin, >>>>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract >>>>>>>>> the nameAndType value of the InvokeDynamicRef. >>>>>>>>> >>>>>>>>> In term of API, I think it's better to decompose the API, i.e. >>>>>>>>> to have a method >>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>> that returns the nameAndType index and to reuse >>>>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array >>>>>>>>> of Strings. >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> R?mi >>>>>>>>> >>>>>>>>> ----- Mail original ----- >>>>>>>>>> De: "Christian Thalinger" >>>>>>>>> > >>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>> Cc: "hotspot-dev developers" , >>>>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>>>> sun.reflect.ConstantPool >>>>>>>>>> >>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>> >>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Hello >>>>>>>>>>> >>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>> The following methods are suggested: >>>>>>>>>>> >>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns >>>>>>>>>>> string >>>>>>>>>>> representation of name and type from a NameAndType constant >>>>>>>>>>> pool entry >>>>>>>>>>> with the specified index >>>>>>>>>>> >>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - >>>>>>>>>>> returns string >>>>>>>>>>> representation of name and type from an InvokeDynamic >>>>>>>>>>> constant pool entry >>>>>>>>>>> with the specified index >>>>>>>>>>> >>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance >>>>>>>>>>> of a constant >>>>>>>>>>> pool entry with the specified index >>>>>>>>>>> >>>>>>>>>>> These three methods could be used for testing API working >>>>>>>>>>> with constant >>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>> >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>> Webrev hotspot: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>> Webrev jdk: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Konstantin >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From chris.hegarty at oracle.com Wed Dec 16 12:22:56 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Dec 2015 12:22:56 +0000 Subject: General question: sun package -> jdk package? In-Reply-To: References: Message-ID: <567157A0.5030908@oracle.com> On 15/12/15 18:56, Joel Borggr?n-Franck wrote: > Hi Chris, > > I'm somewhat surprised to see ReflectionFactory on that list. Can you > share more details around its external use? ReflectionFactory.newConstructorForSerialization is used by several popular third party serialization, mocking, proxying, libraries to construct objects in a non-standard way. -Chris. > cheers > /Joel > > On Tue, 15 Dec 2015 at 16:15 Chris Hegarty > wrote: > > Paul, > > I cannot address your general question, but I guess it might be > motivated > by some of my recent preparatory work for JEP 260 [1]. This JEP proposes > to expose a small number of critical API?s that are in the sun.misc and > sun.reflect namespace. Anything not deemed critical should be removed > from these packages, since it should not be exposed. There is also a > significant amount of technical debt in these packages. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > > On 15 Dec 2015, at 15:09, Paul Benedict > wrote: > > > I have a general question prompted by the many classes moved from > sun.* to > > jdk.*. Once JDK 9 delivers on the Module System and internals are > no longer > > exposed, is it planned to eventually migrate away from the sun.* > legacy > > namespace in later JDK versions? > > > > Cheers, > > Paul > From yasuenag at gmail.com Wed Dec 16 13:04:07 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2015 22:04:07 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <566C11A7.1070309@gmail.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> Message-ID: <56716147.20100@gmail.com> I adapted this enhancement after JDK-8145260: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ Could you review it? Thanks, Yasumasa On 2015/12/12 21:23, Yasumasa Suenaga wrote: > Hi Sherman, > > Our proposal is affected by JDK-8142508. > We have to change ZipFile.java and and ZipFile.c . > Thus we will create a new webrev for current (after 8142508) jdk9/dev repos. > > Do you have any comments about current webrev? > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ > > If you have comments, we will fix them in new webrev. > > > Thanks, > > Yasumasa > > > On 2015/12/03 16:51, KUBOTA Yuji wrote: >> Hi Sherman, >> >> Thanks for your quick response :) >> >> I aimed to implement the "traditional" at this proposal by the below reasons. >> >> * We want to prepare API for encrypted zip files at first. >> * Many people use the "traditional" in problem-free scope like a >> temporary file. >> * We do not know which implementation of the "stronger" is best for openjdk. >> * PKWare claims that they have patents about the "stronger" on Zip[1]. >> * OTOH, WinZip have the alternative implementation of the "stronger" [2][3]. >> * Instead, we prepared the extensibility by ZipCryption interface to >> implement other encrypt engine, such as the AES based. >> >> Thus, I think this PoC should support the "traditional" only. >> In the future, anyone who want to implement the "stronger" can easily >> add their code by virtue of this proposal. >> >> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >> [2] https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >> [3] http://www.winzip.com/aes_info.htm >> >> Thanks, >> Yuji >> >> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>> >>> Hi Yuji, >>> >>> I will take a look at your PoC. Might need some time and even bring in the >>> security guy >>> to evaluate the proposal. It seems like you are only interested in the >>> "traditional PKWare >>> decryption", which is, based on the wiki, "known to be seriously flawed, and >>> in particular >>> is vulnerable to known-plaintext attacks":-) Any request to support >>> "stronger" encryption >>> mechanism, such as the AES based? >>> >>> Regards, >>> Sherman >>> >>> >>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>> >>>> Hi all, >>>> >>>> We need reviewer(s) for this PoC. >>>> Could you please review this proposal and PoC ? >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>> >>>>> Hi all, >>>>> >>>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>>> a response of subscription confirmation of core-libs-dev. >>>>> >>>>> Our customers have to handle password-protected zip files. However, >>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>> third party library so far. >>>>> >>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>> protection to Zip entries", and we tried to implement it. >>>>> >>>>> The current zlib in JDK is completely unaffected by this proposal. The >>>>> traditional zip encryption encrypts a data after it is has been >>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>> implementation. >>>>> >>>>> We've created PoC and uploaded it as webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>> >>>>> Test code is as below. This code will let you know how this PoC >>>>> works. >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>> >>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>> enterprise systems to customers. Some of them, we need to implement to >>>>> handle password-protected zip file. I guess that this proposal is >>>>> desired for many developers and users. >>>>> >>>>> I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). >>>>> We want to implement it if this proposal accepted. >>>>> >>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>> (6.0 Traditional PKWARE Encryption) >>>>> >>>>> Thanks, >>>>> Yuji >>> >>> From vyom.tewari at oracle.com Wed Dec 16 13:02:57 2015 From: vyom.tewari at oracle.com (vyom) Date: Wed, 16 Dec 2015 18:32:57 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> Message-ID: <56716101.1080502@oracle.com> Hi, Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ ) as per Martin review comment removed the _FILE_OFFSET_BITS from source. Thanks, Vyom On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: > _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it > affects interoperability between translation units. It would be good > to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but > that would be a big job. So traditionally the JDK has instead used > the functions made available via _LARGEFILE64_SOURCE. But that is > also a JDK-wide job now, because every call to plain stat in the > source code is broken on 32-bit systems with 64-bit inodes, which are > becoming more common. > > I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job > for build-dev, not core-libs-dev. > > > > > On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs wrote: >> Hi Yvom, >> >> Minor comments: >> >> src/java.base/share/native/libjava/RandomAccessFile.c: >> - "length fail" might be clearer as "GetLength failed" >> >> src/java.base/unix/native/libjava/io_util_md.c: >> >> - Please add a comment before the define of FILE_OFFSET_BITS to indicate >> where it is used and why it is there. >> - BTW, are there any unintended side effects? >> Perhaps a different issue but perhaps 64 bit offsets should be used >> everywhere >> >> src/java.base/windows/native/libjava/io_util_md.c >> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >> elsewhere in the file >> BTW, Testing for invalid handle might be unnecessary since the call to >> GetFileSizeEx will fail >> if it is invalid, yielding the same result. >> >> Roger >> >> >> On 12/10/2015 5:52 AM, vyom wrote: >>> Hi All, >>> >>> Please review my changes for below bug. >>> >>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>> >>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>> >>> >>> This change ensure that length() does not temporarily changes the file >>> pointer and it will make sure that there is no race >>> condition in case of multi thread uses. >>> >>> Thanks, >>> Vyom >>> >>> >>> >>> From Sergey.Bylokhov at oracle.com Wed Dec 16 13:19:20 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Dec 2015 16:19:20 +0300 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <56716147.20100@gmail.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> Message-ID: <567164D8.8040201@oracle.com> Should the new methods describe how they will work in case of null params? On 16/12/15 16:04, Yasumasa Suenaga wrote: > I adapted this enhancement after JDK-8145260: > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ > > Could you review it? > > > Thanks, > > Yasumasa > > > On 2015/12/12 21:23, Yasumasa Suenaga wrote: >> Hi Sherman, >> >> Our proposal is affected by JDK-8142508. >> We have to change ZipFile.java and and ZipFile.c . >> Thus we will create a new webrev for current (after 8142508) jdk9/dev >> repos. >> >> Do you have any comments about current webrev? >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >> >> If you have comments, we will fix them in new webrev. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>> Hi Sherman, >>> >>> Thanks for your quick response :) >>> >>> I aimed to implement the "traditional" at this proposal by the below >>> reasons. >>> >>> * We want to prepare API for encrypted zip files at first. >>> * Many people use the "traditional" in problem-free scope like a >>> temporary file. >>> * We do not know which implementation of the "stronger" is best for >>> openjdk. >>> * PKWare claims that they have patents about the "stronger" on >>> Zip[1]. >>> * OTOH, WinZip have the alternative implementation of the >>> "stronger" [2][3]. >>> * Instead, we prepared the extensibility by ZipCryption interface to >>> implement other encrypt engine, such as the AES based. >>> >>> Thus, I think this PoC should support the "traditional" only. >>> In the future, anyone who want to implement the "stronger" can easily >>> add their code by virtue of this proposal. >>> >>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>> [2] >>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>> >>> [3] http://www.winzip.com/aes_info.htm >>> >>> Thanks, >>> Yuji >>> >>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>> >>>> Hi Yuji, >>>> >>>> I will take a look at your PoC. Might need some time and even bring >>>> in the >>>> security guy >>>> to evaluate the proposal. It seems like you are only interested in the >>>> "traditional PKWare >>>> decryption", which is, based on the wiki, "known to be seriously >>>> flawed, and >>>> in particular >>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>> "stronger" encryption >>>> mechanism, such as the AES based? >>>> >>>> Regards, >>>> Sherman >>>> >>>> >>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We need reviewer(s) for this PoC. >>>>> Could you please review this proposal and PoC ? >>>>> >>>>> Thanks, >>>>> Yuji >>>>> >>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>> >>>>>> Hi all, >>>>>> >>>>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>>>> a response of subscription confirmation of core-libs-dev. >>>>>> >>>>>> Our customers have to handle password-protected zip files. However, >>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>> third party library so far. >>>>>> >>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>> protection to Zip entries", and we tried to implement it. >>>>>> >>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>> The >>>>>> traditional zip encryption encrypts a data after it is has been >>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>> implementation. >>>>>> >>>>>> We've created PoC and uploaded it as webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>> >>>>>> Test code is as below. This code will let you know how this PoC >>>>>> works. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>> >>>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>>> enterprise systems to customers. Some of them, we need to >>>>>> implement to >>>>>> handle password-protected zip file. I guess that this proposal is >>>>>> desired for many developers and users. >>>>>> >>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>> (ysuenaga). >>>>>> We want to implement it if this proposal accepted. >>>>>> >>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>> (6.0 Traditional PKWARE Encryption) >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>> >>>> -- Best regards, Sergey. From kumar.x.srinivasan at oracle.com Wed Dec 16 13:32:41 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 16 Dec 2015 05:32:41 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <56712DB6.9020102@oracle.com> References: <567037AA.30801@oracle.com> <56711FCE.5030909@oracle.com> <56712DB6.9020102@oracle.com> Message-ID: <567167F9.2010807@oracle.com> On 12/16/2015 1:24 AM, Mikael Gerdin wrote: > On 2015-12-16 09:24, Mikael Gerdin wrote: >> Hi Kumar, >> >> On 2015-12-15 16:54, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review fix for: JDK-8115868 >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ >> >> Since I don't feel qualified to comment on the actual code changes I >> don't consider this a code review but I looked at the diffs and they >> make sense to me. >> >> I have however tested this fix and verified that it resolves the issues >> in the launcher. > > And as for the changes required for the VM, would it be appropriate to > clone 8115868 and move it to hotspot/runtime instead of pushing the VM > fix under the same bug number? Right, since this issue exists in HotSpot you should file a bug on Runtime, linking this and the JDK bug, this issue will likely exist elsewhere in the JDK code base as well. Thanks Kumar > > /Mikael > >> >> /Mikael >> >>> >>> The background: >>> The launcher uses stat(2) to check for the existence of a file, >>> unfortunately >>> on 32-bit system with large file systems causes the inode storage to >>> overflow >>> causing the syscall to return EOVERFLOW. >>> >>> Solution: >>> * stat(2) replaced with access(3), in most cases. >>> * jbs is marked noreg-hard hard to replicate the problem >>> >>> Thanks >>> Kumar >>> >>> >>> >>> >>> >> > From kumar.x.srinivasan at oracle.com Wed Dec 16 13:42:49 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 16 Dec 2015 05:42:49 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <20151215231250.00004401.ecki@zusammenkunft.net> References: <567037AA.30801@oracle.com> <20151215231250.00004401.ecki@zusammenkunft.net> Message-ID: <56716A59.1090901@oracle.com> Hi Bernd, > Hello, > > I always like it when access() is used instead of stat() magic. > > I noticed that the new ProgramExists in java_md_common.c does not > anymore reject directories (which are typically executable). Not sure > it this matters or is intentional, it is a change in semantic. Yes as the name suggests "ProgramExists", therefore that method should be checking for the existence of the target file and whether it is executable. > Is there an exising typo in args.c#366 ("size i_s_ fine") which could > be fixed in the patch as well? I will refine that comment. > I would simply remove the stat code from expandArgFile, the fallback > code is only slow in the unlikely case of rejected large files so there > is no need to attempt the stat() call. Would remove 10 lines. I think it is correct, the way it is, because we could potentially have large argfiles residing on slow file systems (smb, nfs etc.). Thanks for the input. Kumar > Gruss > Bernd > > Am Tue, 15 Dec 2015 10:36:08 -0800 > schrieb Henry Jen: > >> Changes looks reasonable to me. >> >> Cheers, >> Henry >> >> >>> On Dec 15, 2015, at 7:54 AM, Kumar Srinivasan >>> wrote: >>> >>> Hello, >>> >>> Please review fix for: JDK-8115868 >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ >>> >>> The background: >>> The launcher uses stat(2) to check for the existence of a file, >>> unfortunately on 32-bit system with large file systems causes the >>> inode storage to overflow causing the syscall to return EOVERFLOW. >>> >>> Solution: >>> * stat(2) replaced with access(3), in most cases. >>> * jbs is marked noreg-hard hard to replicate the problem >>> >>> Thanks >>> Kumar >>> >>> >>> >>> >>> From magnus.ihse.bursie at oracle.com Wed Dec 16 13:50:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Dec 2015 14:50:20 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition Message-ID: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I am sponsoring this patch. The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 /Magnus From dl at cs.oswego.edu Wed Dec 16 14:09:28 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 16 Dec 2015 09:09:28 -0500 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> Message-ID: <56717098.8020609@cs.oswego.edu> On 12/02/2015 07:51 PM, Martin Buchholz wrote: > We're stuck. Peter wants to make Throwables cloneable, I want to > reverse the order of throwables and add the past Throwable as a > suppressed exception to the exception of a dependent action, and Doug > wants the current webrev behavior of adding the dependent action as a > suppressed exception of the source. > After letting this sit for a week or so, I think the main issue here is that we do not properly explain how and when to use whenComplete() vs handle(). We should explain that handle() should be used in the same way as "catch", and whenComplete as "finally"/try-with-resources. See below. Given this, the most appropriate response in whenComplete upon a secondary exception encountered when handling the primary exception is the same as the finally-based scheme used in try-with-resources: primary.addSuppressed(secondary). Which we should have done originally (vs dropping secondary), and is the current proposed webrev. (In contrast, if someone would like to translate one exception into another by throwing the new one, they could use handle().) Peter raised the issue that addSuppressed could visibly (but safely) alter the primary while it is visible to some concurrent action. Which is true, but also no different than is possible with try-with-resources (consider that the primary exception there could be already somehow accessible). If exceptions were cloneable, it might be less surprising to users in both cases to create a new cloned exception with the suppressed secondary. But I think we now agree that pseudo-cloning exceptions has even more opportunity for surprising users, so should be done only when there aren't any alternatives. Agreed? Here's a clarification for CompletionStage (un-reformatted). Improvements welcome. Someday we might consider adding some examples. * *

  • Two method forms support processing whether the triggering * stage completed normally or exceptionally: Method {@link ! * #whenComplete whenComplete} allows injection of an action * regardless of outcome, otherwise preserving the outcome in its ! * completion. Method {@link #handle handle} additionally allows the * stage to compute a replacement result that may enable further * processing by other dependent stages. In all other cases, if a * stage's computation terminates abruptly with an (unchecked) --- 58,66 ---- * *
  • Two method forms support processing whether the triggering * stage completed normally or exceptionally: Method {@link ! * #whenComplete whenComplete} is similar to a {@code finally} clause, allowing injection of an action * regardless of outcome, otherwise preserving the outcome in its ! * completion. Method {@link #handle handle} is similar to a {@code catch} clause, allowing the * stage to compute a replacement result that may enable further * processing by other dependent stages. In all other cases, if a * stage's computation terminates abruptly with an (unchecked) From erik.joelsson at oracle.com Wed Dec 16 14:37:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 Dec 2015 15:37:02 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <5671770E.90001@oracle.com> The configure change looks good. Can't comment on the code changes. /Erik On 2015-12-16 14:50, Magnus Ihse Bursie wrote: > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus From yasuenag at gmail.com Wed Dec 16 14:47:08 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2015 23:47:08 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <567164D8.8040201@oracle.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> Message-ID: <5671796C.1030406@gmail.com> Hi Sergey, Thank you for your comment. I added that description in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ Thanks, Yasumasa On 2015/12/16 22:19, Sergey Bylokhov wrote: > Should the new methods describe how they will work in case of null params? > > On 16/12/15 16:04, Yasumasa Suenaga wrote: >> I adapted this enhancement after JDK-8145260: >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>> Hi Sherman, >>> >>> Our proposal is affected by JDK-8142508. >>> We have to change ZipFile.java and and ZipFile.c . >>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>> repos. >>> >>> Do you have any comments about current webrev? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>> >>> If you have comments, we will fix them in new webrev. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>> Hi Sherman, >>>> >>>> Thanks for your quick response :) >>>> >>>> I aimed to implement the "traditional" at this proposal by the below >>>> reasons. >>>> >>>> * We want to prepare API for encrypted zip files at first. >>>> * Many people use the "traditional" in problem-free scope like a >>>> temporary file. >>>> * We do not know which implementation of the "stronger" is best for >>>> openjdk. >>>> * PKWare claims that they have patents about the "stronger" on >>>> Zip[1]. >>>> * OTOH, WinZip have the alternative implementation of the >>>> "stronger" [2][3]. >>>> * Instead, we prepared the extensibility by ZipCryption interface to >>>> implement other encrypt engine, such as the AES based. >>>> >>>> Thus, I think this PoC should support the "traditional" only. >>>> In the future, anyone who want to implement the "stronger" can easily >>>> add their code by virtue of this proposal. >>>> >>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>> [2] >>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>> >>>> [3] http://www.winzip.com/aes_info.htm >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>> >>>>> Hi Yuji, >>>>> >>>>> I will take a look at your PoC. Might need some time and even bring >>>>> in the >>>>> security guy >>>>> to evaluate the proposal. It seems like you are only interested in the >>>>> "traditional PKWare >>>>> decryption", which is, based on the wiki, "known to be seriously >>>>> flawed, and >>>>> in particular >>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>> "stronger" encryption >>>>> mechanism, such as the AES based? >>>>> >>>>> Regards, >>>>> Sherman >>>>> >>>>> >>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> We need reviewer(s) for this PoC. >>>>>> Could you please review this proposal and PoC ? >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>> >>>>>>> Our customers have to handle password-protected zip files. However, >>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>> third party library so far. >>>>>>> >>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>> >>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>> The >>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>> implementation. >>>>>>> >>>>>>> We've created PoC and uploaded it as webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>> >>>>>>> Test code is as below. This code will let you know how this PoC >>>>>>> works. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>> >>>>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>> implement to >>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>> desired for many developers and users. >>>>>>> >>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>> (ysuenaga). >>>>>>> We want to implement it if this proposal accepted. >>>>>>> >>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>> >>>>> > > From jason_mehrens at hotmail.com Wed Dec 16 15:33:03 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 16 Dec 2015 15:33:03 +0000 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <5671796C.1030406@gmail.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com>,<5671796C.1030406@gmail.com> Message-ID: The null check of 'entry' at line 351 of ZipFile.getInputStream is in conflict with line 350 and 348. ________________________________________ From: core-libs-dev on behalf of Yasumasa Suenaga Sent: Wednesday, December 16, 2015 8:47 AM To: Sergey Bylokhov; Xueming Shen Cc: core-libs-dev at openjdk.java.net Subject: Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries Hi Sergey, Thank you for your comment. I added that description in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ Thanks, Yasumasa On 2015/12/16 22:19, Sergey Bylokhov wrote: > Should the new methods describe how they will work in case of null params? > > On 16/12/15 16:04, Yasumasa Suenaga wrote: >> I adapted this enhancement after JDK-8145260: >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>> Hi Sherman, >>> >>> Our proposal is affected by JDK-8142508. >>> We have to change ZipFile.java and and ZipFile.c . >>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>> repos. >>> >>> Do you have any comments about current webrev? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>> >>> If you have comments, we will fix them in new webrev. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>> Hi Sherman, >>>> >>>> Thanks for your quick response :) >>>> >>>> I aimed to implement the "traditional" at this proposal by the below >>>> reasons. >>>> >>>> * We want to prepare API for encrypted zip files at first. >>>> * Many people use the "traditional" in problem-free scope like a >>>> temporary file. >>>> * We do not know which implementation of the "stronger" is best for >>>> openjdk. >>>> * PKWare claims that they have patents about the "stronger" on >>>> Zip[1]. >>>> * OTOH, WinZip have the alternative implementation of the >>>> "stronger" [2][3]. >>>> * Instead, we prepared the extensibility by ZipCryption interface to >>>> implement other encrypt engine, such as the AES based. >>>> >>>> Thus, I think this PoC should support the "traditional" only. >>>> In the future, anyone who want to implement the "stronger" can easily >>>> add their code by virtue of this proposal. >>>> >>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>> [2] >>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>> >>>> [3] http://www.winzip.com/aes_info.htm >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>> >>>>> Hi Yuji, >>>>> >>>>> I will take a look at your PoC. Might need some time and even bring >>>>> in the >>>>> security guy >>>>> to evaluate the proposal. It seems like you are only interested in the >>>>> "traditional PKWare >>>>> decryption", which is, based on the wiki, "known to be seriously >>>>> flawed, and >>>>> in particular >>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>> "stronger" encryption >>>>> mechanism, such as the AES based? >>>>> >>>>> Regards, >>>>> Sherman >>>>> >>>>> >>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> We need reviewer(s) for this PoC. >>>>>> Could you please review this proposal and PoC ? >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>> >>>>>>> Our customers have to handle password-protected zip files. However, >>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>> third party library so far. >>>>>>> >>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>> >>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>> The >>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>> implementation. >>>>>>> >>>>>>> We've created PoC and uploaded it as webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>> >>>>>>> Test code is as below. This code will let you know how this PoC >>>>>>> works. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>> >>>>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>> implement to >>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>> desired for many developers and users. >>>>>>> >>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>> (ysuenaga). >>>>>>> We want to implement it if this proposal accepted. >>>>>>> >>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>> >>>>> > > From christian.thalinger at oracle.com Wed Dec 16 16:42:49 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Dec 2015 06:42:49 -1000 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <56714765.5010009@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> Message-ID: <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> Looks good. Thanks. > On Dec 16, 2015, at 1:13 AM, Konstantin Shefov wrote: > > Christian > > I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. > http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ > > -Konstantin > > On 12/15/2015 08:36 PM, Christian Thalinger wrote: >> >>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov > wrote: >>> >>> Hi Christian >>> >>> Thanks for reviewing, I have changed indents as you asked: >>> >>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >> >> Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >> >> but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >> >> and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. >> >>> >>> -Konstantin >>> >>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>> >>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>>>> >>>>> Hello >>>>> >>>>> Please review the new version on the patch. >>>>> >>>>> New webrev: >>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>> >>>> These newlines look ridiculous especially when it?s not even needed: >>>> >>>> + // Returns a class reference index for a method or a field. >>>> + public int getClassRefIndexAt >>>> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >>>> >>>> Either fix the indent or just add them like regular methods should look like. >>>> >>>>> >>>>> What has been changed: >>>>> 1. Added tests for the new added methods. >>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>> Coleen, >>>>>> Thanks for review >>>>>> >>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>>>> I will add tests. >>>>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> Please, review modified webrev. >>>>>>>> >>>>>>>> I have added methods >>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>>>> >>>>>>>> I removed previously added method >>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>>> >>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>> Remi, >>>>>>>>> >>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>>>> >>>>>>>>> -Konstantin >>>>>>>>> >>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>> Hi Konstantin, >>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>> >>>>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> R?mi >>>>>>>>>> >>>>>>>>>> ----- Mail original ----- >>>>>>>>>>> De: "Christian Thalinger" > >>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>>>> >>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>> >>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello >>>>>>>>>>>> >>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>> >>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>>>> with the specified index >>>>>>>>>>>> >>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>>>> with the specified index >>>>>>>>>>>> >>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>> >>>>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>> >>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> -Konstantin >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Wed Dec 16 16:46:15 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Dec 2015 17:46:15 +0100 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56717098.8020609@cs.oswego.edu> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <56717098.8020609@cs.oswego.edu> Message-ID: <56719557.7020606@gmail.com> Hi Doug, On 12/16/2015 03:09 PM, Doug Lea wrote: > On 12/02/2015 07:51 PM, Martin Buchholz wrote: >> We're stuck. Peter wants to make Throwables cloneable, I want to >> reverse the order of throwables and add the past Throwable as a >> suppressed exception to the exception of a dependent action, and Doug >> wants the current webrev behavior of adding the dependent action as a >> suppressed exception of the source. >> > > After letting this sit for a week or so, I think the main issue > here is that we do not properly explain how and when to use > whenComplete() vs handle(). We should explain that handle() > should be used in the same way as "catch", and whenComplete as > "finally"/try-with-resources. See below. > > Given this, the most appropriate response in whenComplete upon > a secondary exception encountered when handling the primary exception > is the same as the finally-based scheme used in try-with-resources: > primary.addSuppressed(secondary). Which we should have done > originally (vs dropping secondary), and is the current proposed > webrev. > > (In contrast, if someone would like to translate one exception > into another by throwing the new one, they could use handle().) > > Peter raised the issue that addSuppressed could visibly (but safely) > alter the primary while it is visible to some concurrent action. > Which is true, but also no different than is possible with > try-with-resources (consider that the primary exception there could > be already somehow accessible). It could be, but in try-with-resources there is usually just a sequence of actions in a single thread that is always deterministic, while in whenCompleteAsync for example, a thread requesting the outcome of previous stage can observe it's outcome with suppressed exception added or not, depending on timing. > If exceptions were cloneable, > it might be less surprising to users in both cases to create a new > cloned exception with the suppressed secondary. But I think we now > agree that pseudo-cloning exceptions has even more opportunity for > surprising users, so should be done only when there aren't any > alternatives. > > Agreed? Agreed. Pseudo cloning (using reflection to invoke constructor) is not reliable. > > Here's a clarification for CompletionStage (un-reformatted). > Improvements welcome. Someday we might consider adding some examples. > > * > *
  • Two method forms support processing whether the triggering > * stage completed normally or exceptionally: Method {@link > ! * #whenComplete whenComplete} allows injection of an action > * regardless of outcome, otherwise preserving the outcome in its > ! * completion. Method {@link #handle handle} additionally allows the > * stage to compute a replacement result that may enable further > * processing by other dependent stages. In all other cases, if a > * stage's computation terminates abruptly with an (unchecked) > --- 58,66 ---- > * > *
  • Two method forms support processing whether the triggering > * stage completed normally or exceptionally: Method {@link > ! * #whenComplete whenComplete} is similar to a {@code finally} > clause, allowing injection of an action > * regardless of outcome, otherwise preserving the outcome in its The finally block (in classical try/finally or in try-with-resources/finally) preserves the outcome of try block only if the finally block completes normally. Otherwise the outcome is replaced with the exception thrown or value returned in finally block. For example: // IllegalStateException propagates out of: try { throw new IllegalArgumentException(); } finally { throw new IllegalStateException(); } // as well as out of: try (AutoCloseable r = () -> {}){ throw new IllegalArgumentException(); } finally { throw new IllegalStateException(); } // this method returns 2: public static int x() { try { return 1; } finally { return 2; } } If we are talking about the automatic clean-up action (AutoCloseable::close()) and not of the finally block, then the exceptional outcome of try block is always preserved and the exception thrown from AutoCloseable::close() is just added as suppressed to the exception from try block: // IllegalArgumentException propagates out of: try (AutoCloseable r = () -> { throw new IllegalStateException(); }){ throw new IllegalArgumentException(); } ...but non-exceptional outcome of try block is replaced with the exception from AutoCloseable::close(): // this method throws IllegalStateException: public static int x() throws Exception { try (AutoCloseable r = () -> { throw new IllegalStateException(); }){ return 12; } } If we are talking about auto-closing, then the text should not speak about "finally", as whenComplete is not equivalent to finally block then. Since whenComplete takes a BiConsumer, it can not "replace" the non-exceptional outcome of previous stage. In this respect it is more similar to void method AutoCloseable::close() than it is to finally block which can return a value from the method. So perhaps we should model it to the AutoCloseable::close() in try-with-resources then. Which is what is proposed. It's just that non-determinism when multiple threads are involved that might cause surprises. Regards, Peter > ! * completion. Method {@link #handle handle} is similar to a {@code > catch} clause, allowing the > * stage to compute a replacement result that may enable further > * processing by other dependent stages. In all other cases, if a > * stage's computation terminates abruptly with an (unchecked) > From joe.darcy at oracle.com Wed Dec 16 17:52:59 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 16 Dec 2015 09:52:59 -0800 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> <5669EC2A.1030308@oracle.com> <566F1C72.7010001@oracle.com> Message-ID: <5671A4FB.5020401@oracle.com> Hi Joel, FYI, ccc request now approved; thanks, -Joe On 12/16/2015 1:15 AM, Joel Borggr?n-Franck wrote: > Sounds good. > > I'll ping someone in my time zone to check the status of the ccc and > push once it is approved. > > Thanks for the review > > Cheers > /Joel > On m?n 14 dec. 2015 at 20:45 joe darcy > wrote: > > Hi Joel, > > Revised ccc request finalized for current version of the spec; > should be approved in a day or two. > > Once that is approved, I think the current version can be pushed, > enabling the refactorings you've alluded to to occur later. > > Thanks, > > -Joe > > > On 12/13/2015 12:26 PM, Joel Borggr?n-Franck wrote: >> Hi Joe, >> >> Thanks for the comments, >> >> On Thu, 10 Dec 2015 at 22:18 joe darcy > > wrote: >> >> Hi Joel, >> >> On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: >>> Question, is it better to remove the throws clauses for the >>> cases that return null? >> >> I think so; they aren't applicable in those case and it is >> fine to remove exceptions in subtypes of course. >> >> >> Done. >> >> Please also add @Override annotations to the methods in the >> subtypes as a check that a new method is not accidentally >> being declared. >> >> >> Doh! Fixed. >> >>> >>> New webrev: >>> http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ >>> >>> Diff of patch 01 and patch 02 (a diff-diff): >>> http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch >>> >>> >>> >> >> Please add an @implSpec note in AnnotatedType saying that >> "this implementation returns null", or words to that effect. >> >> >> Done. >> >> Shouldn't some of the implementation overrides in >> AnnotatedTypeFactory.java which throw null now be removed? >> Ah, I see the BaseImpl type is in the way. Is there an easy >> way to refactor that? >> >> >> I think it deserves a separate commit. I have another bugfix >> lined up, then I plan to refactor refactor the code a bit and >> clean up and improve testing. >> >> (I'll take care of the ccc changes once the new spec is >> finalized.) >> >> >> Thanks! >> >> New webrev: >> http://cr.openjdk.java.net/~jfranck/8057804/webrev.03/ >> >> Delta vs 01: >> http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v3.patch >> >> >> cheers >> /Joel > From martinrb at google.com Wed Dec 16 19:01:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Dec 2015 11:01:55 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <20151215231250.00004401.ecki@zusammenkunft.net> References: <567037AA.30801@oracle.com> <20151215231250.00004401.ecki@zusammenkunft.net> Message-ID: On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: > Hello, > > I always like it when access() is used instead of stat() magic. > > I noticed that the new ProgramExists in java_md_common.c does not > anymore reject directories (which are typically executable). Not sure > it this matters or is intentional, it is a change in semantic. Right. This is a small loss of robustness. Changing stat into access here isn't really right because not stat has a superset of functionality, and (like I keep saying) all the stat calls in the JDK are potentially broken and need fixing. From martinrb at google.com Wed Dec 16 19:08:44 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Dec 2015 11:08:44 -0800 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56716101.1080502@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56716101.1080502@oracle.com> Message-ID: Calling naked fstat without _FILE_OFFSET_BITS=64 is a bug. Don't you need to call fstat64 if it's available? +jlong +handleGetLength(FD fd) +{ + struct stat sb; + if (fstat(fd, &sb) == 0) { + return sb.st_size; + } else { + return -1; + } +} On Wed, Dec 16, 2015 at 5:02 AM, vyom wrote: > Hi, > > Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ > ) as per Martin > review comment removed the _FILE_OFFSET_BITS from source. > > Thanks, > Vyom > > > > On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: >> >> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >> affects interoperability between translation units. It would be good >> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but >> that would be a big job. So traditionally the JDK has instead used >> the functions made available via _LARGEFILE64_SOURCE. But that is >> also a JDK-wide job now, because every call to plain stat in the >> source code is broken on 32-bit systems with 64-bit inodes, which are >> becoming more common. >> >> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job >> for build-dev, not core-libs-dev. >> >> >> >> >> On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs >> wrote: >>> >>> Hi Yvom, >>> >>> Minor comments: >>> >>> src/java.base/share/native/libjava/RandomAccessFile.c: >>> - "length fail" might be clearer as "GetLength failed" >>> >>> src/java.base/unix/native/libjava/io_util_md.c: >>> >>> - Please add a comment before the define of FILE_OFFSET_BITS to >>> indicate >>> where it is used and why it is there. >>> - BTW, are there any unintended side effects? >>> Perhaps a different issue but perhaps 64 bit offsets should be used >>> everywhere >>> >>> src/java.base/windows/native/libjava/io_util_md.c >>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>> elsewhere in the file >>> BTW, Testing for invalid handle might be unnecessary since the call >>> to >>> GetFileSizeEx will fail >>> if it is invalid, yielding the same result. >>> >>> Roger >>> >>> >>> On 12/10/2015 5:52 AM, vyom wrote: >>>> >>>> Hi All, >>>> >>>> Please review my changes for below bug. >>>> >>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>> >>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>> >>>> >>>> This change ensure that length() does not temporarily changes the file >>>> pointer and it will make sure that there is no race >>>> condition in case of multi thread uses. >>>> >>>> Thanks, >>>> Vyom >>>> >>>> >>>> >>>> > From aleksey.shipilev at oracle.com Wed Dec 16 19:11:47 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Dec 2015 22:11:47 +0300 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 Message-ID: <5671B773.3070500@oracle.com> Hi, I would like to suggest a simple cleanup/improvement in current StringUTF16, which somewhat closes the gap between C1 and C2 performance with Compact Strings: https://bugs.openjdk.java.net/browse/JDK-8145428 http://cr.openjdk.java.net/~shade/8145428/webrev.02/ It does improve the score on C1 (-client) configurations significantly, without affecting C2 performance (because we basically modifying the code that C2 would overthrow with vectorized intrinsic): http://cr.openjdk.java.net/~shade/8145428/notes.txt ...and the generated code looks much better now. It also alleviates some performance regressions on client configurations we observed in a regular performance testing. The subsequent improvements may further eliminate range checks, plus unroll/vectorize the loop, but I would like to defer that until array comparison intrinsics are stable and exposed to both C1 and C2. Testing: microbenchmarks, JPRT Thanks, -Aleksey From martinrb at google.com Wed Dec 16 19:30:52 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Dec 2015 11:30:52 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <5670F936.7010409@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> <5670F936.7010409@oracle.com> Message-ID: On Tue, Dec 15, 2015 at 9:40 PM, David Holmes wrote: > As a point fix a way to change the stack size of the process reaper thread > might suffice. But that is a band-aid. I can imagine bugs of the form "when > we run our Java code stand-alone it runs fine, but as soon as we embed the > JVM in our own application front-end it fails with StackOverflowErrors > everywhere". :( I'm the one responsible for the small stack size of the process reaper thread. The result is that any mechanism that snacks on the stack, be it TLS or guard pages, will first cause the Process code to fail. If we bump up the reaper thread stack size, then what is a "safe" value? And any increase has its own risks, like potentially more memory and/or address space consumed, possibly leading to OOME. You have a choice between StackOverflowError and OutOfMemoryError. Or you could properly implement growable/movable/splittable stacks. From joel.borggren.franck at gmail.com Wed Dec 16 19:34:18 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Wed, 16 Dec 2015 19:34:18 +0000 Subject: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type In-Reply-To: <5671A4FB.5020401@oracle.com> References: <564DC981.8000207@oracle.com> <5668D0C9.6010806@oracle.com> <5669EC2A.1030308@oracle.com> <566F1C72.7010001@oracle.com> <5671A4FB.5020401@oracle.com> Message-ID: Thanks, change has been pushed. cheers /Joel On Wed, 16 Dec 2015 at 18:53 joe darcy wrote: > Hi Joel, > > FYI, ccc request now approved; thanks, > > -Joe > > > On 12/16/2015 1:15 AM, Joel Borggr?n-Franck wrote: > > Sounds good. > > I'll ping someone in my time zone to check the status of the ccc and push > once it is approved. > > Thanks for the review > > Cheers > /Joel > On m?n 14 dec. 2015 at 20:45 joe darcy wrote: > >> Hi Joel, >> >> Revised ccc request finalized for current version of the spec; should be >> approved in a day or two. >> >> Once that is approved, I think the current version can be pushed, >> enabling the refactorings you've alluded to to occur later. >> >> Thanks, >> >> -Joe >> >> >> On 12/13/2015 12:26 PM, Joel Borggr?n-Franck wrote: >> >> Hi Joe, >> >> Thanks for the comments, >> >> On Thu, 10 Dec 2015 at 22:18 joe darcy wrote: >> >>> Hi Joel, >>> >>> On 12/10/2015 12:27 PM, Joel Borggr?n-Franck wrote: >>> >>> Question, is it better to remove the throws clauses for the cases that >>> return null? >>> >>> >>> I think so; they aren't applicable in those case and it is fine to >>> remove exceptions in subtypes of course. >>> >>> >> Done. >> >> >>> Please also add @Override annotations to the methods in the subtypes as >>> a check that a new method is not accidentally being declared. >>> >>> >> Doh! Fixed. >> >>> >>> New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.02/ >>> Diff of patch 01 and patch 02 (a diff-diff): >>> http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v2.patch >>> >>> >>> >>> Please add an @implSpec note in AnnotatedType saying that "this >>> implementation returns null", or words to that effect. >>> >>> >> Done. >> >> >>> Shouldn't some of the implementation overrides in >>> AnnotatedTypeFactory.java which throw null now be removed? Ah, I see the >>> BaseImpl type is in the way. Is there an easy way to refactor that? >>> >>> >> I think it deserves a separate commit. I have another bugfix lined up, >> then I plan to refactor refactor the code a bit and clean up and improve >> testing. >> >> >>> (I'll take care of the ccc changes once the new spec is finalized.) >>> >>> >> Thanks! >> >> New webrev: http://cr.openjdk.java.net/~jfranck/8057804/webrev.03/ >> Delta vs 01: http://cr.openjdk.java.net/~jfranck/8057804/diff_v1-v3.patch >> >> cheers >> /Joel >> >> >> > From claes.redestad at oracle.com Wed Dec 16 19:36:47 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 16 Dec 2015 20:36:47 +0100 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5671B773.3070500@oracle.com> References: <5671B773.3070500@oracle.com> Message-ID: <5671BD4F.7030104@oracle.com> Good! /Claes On 2015-12-16 20:11, Aleksey Shipilev wrote: > Hi, > > I would like to suggest a simple cleanup/improvement in current > StringUTF16, which somewhat closes the gap between C1 and C2 performance > with Compact Strings: > https://bugs.openjdk.java.net/browse/JDK-8145428 > http://cr.openjdk.java.net/~shade/8145428/webrev.02/ > > It does improve the score on C1 (-client) configurations significantly, > without affecting C2 performance (because we basically modifying the > code that C2 would overthrow with vectorized intrinsic): > http://cr.openjdk.java.net/~shade/8145428/notes.txt > > ...and the generated code looks much better now. It also alleviates some > performance regressions on client configurations we observed in a > regular performance testing. > > The subsequent improvements may further eliminate range checks, plus > unroll/vectorize the loop, but I would like to defer that until array > comparison intrinsics are stable and exposed to both C1 and C2. > > Testing: microbenchmarks, JPRT > > Thanks, > -Aleksey > From Roger.Riggs at Oracle.com Wed Dec 16 19:47:05 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 16 Dec 2015 14:47:05 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56709BB8.3070809@gmail.com> References: <560D3F61.6040607@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> Message-ID: <5671BFB9.2020605@Oracle.com> Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushing). http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ Thanks, Roger On 12/15/2015 6:01 PM, Peter Levart wrote: > > > On 12/15/2015 11:48 PM, Roger Riggs wrote: >> Hi Peter, >> >> That will break up clearing the ref when the Cleanable is explicitly >> cleaned. >> Reference.clear() needs to be called from Cleanable.clean(). > > From PhantomCleanable (the superclass of PhantomCleanableRef): > > 253 @Override > 254 public final void clean() { > 255 if (remove()) { > 256 super.clear(); > 257 performCleanup(); > 258 } > 259 } > 260 > 261 /** > 262 * Unregister this PhantomCleanable and clear the reference. > 263 * Due to inherent concurrency, {@link #performCleanup()} > may still be invoked. > 264 */ > 265 @Override > 266 public final void clear() { > 267 if (remove()) { > 268 super.clear(); > 269 } > 270 } > > > ... clean() calls super.clear(), which is "invokespecial" (not a > virtual dispatch). > > > Regards, Peter > >> >> it might be nice to block that but to do so we'd need to go back to >> separate objects >> for the Reference and the Cleanable and we worked hard to get to a >> single object. >> >> Roger >> >> >> On 12/15/2015 5:38 PM, Peter Levart wrote: >>> Hi Roger, >>> >>> Just one thing about implementation: >>> >>> Since the type exposed to user is Cleaner.Cleanable that has only a >>> single method clean(), it would be good if the implementation class >>> (CleanerImpl.PhantomCleanableRef) overrode >>> CleanerImpl.PhantomCleanable.clear() method and threw >>> UnsupportedOperationException, otherwise users will be tempted to >>> cast the returned Cleaner.Cleanable to Reference and invoke clear() >>> method to de-register cleanup action without invoking it. This is >>> the only remaining public Reference method that is not disabled this >>> way. >>> >>> Regards, Peter >>> >>> On 12/09/2015 07:40 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> The example is revised to caution about inner classes and lambdas. >>>> >>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>> >>>> Thanks, Roger >>>> >>>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>>>> Hi Chris, >>>>> >>>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>>>> Peter, >>>>>> >>>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I think the only way to try to prevent such things is with a good >>>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>>> >>>>>>> >>>>>>> public static class CleanerExample implements AutoCloseable { >>>>>>> >>>>>>> private static final Cleaner cleaner = ...; // >>>>>>> preferably a >>>>>>> shared cleaner >>>>>>> >>>>>>> private final PrivateNativeResource pnr; >>>>>>> >>>>>>> private final Cleaner.Cleanable cleanable; >>>>>>> >>>>>>> public CleanerExample(args, ...) { >>>>>>> >>>>>>> // prepare captured state as local vars... >>>>>>> PrivateNativeResource _pnr = ...; >>>>>>> >>>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>>> // DON'T capture any instance fields with >>>>>>> lambda since >>>>>>> that would >>>>>>> // capture 'this' and prevent it from becoming >>>>>> >>>>>> I assume that the WARNING should include anonymous inner classes too >>>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>>> >>>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>>> the IDE ;-) >>>>> >>>>> 'this' only leaks to the 'referent' field of PhantomReference >>>>> where by definition is not accessible. >>>>> >>>>> 'this' can become phantom-reachable before CleanerExample >>>>> constructor ends. But this is harmless, because the code that may >>>>> execute at that time does not access the object any more, so the >>>>> object may be safely collected. >>>>> >>>>> Cleanup action can run at any time after registration even before >>>>> CleanerExample constructor ends. But this is harmless too, because >>>>> it only accesses PrivateNativeResource which is fully constructed >>>>> before registration of cleanup action. >>>>> >>>>> I see no issues apart from IDE(s) not seeing no issues. >>>>> >>>>> Regards, Peter >>>>> >>>>>> >>>>>> -Chris. >>>>>> >>>>>> >>>>>>> phantom-reachable!!! >>>>>>> _pnr.close(); >>>>>>> }); >>>>>>> >>>>>>> this.pnr = _pnr; >>>>>>> } >>>>>>> >>>>>>> public void close() { >>>>>>> cleanable.clean(); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Wed Dec 16 20:07:31 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Dec 2015 12:07:31 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5671BFB9.2020605@Oracle.com> References: <560D3F61.6040607@Oracle.com> <562687C8.1040106@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.20! 20605@Oracle.com> Message-ID: The change > On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: > > Hi Peter, > > It was a bit more involved than I expected, mostly in the tests to make this change. > > Is this what you expected? (just the deltas, I'll merge the patches before pushing). > > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ > This change looks good. Having clear() throwing UOE is right thing to do and prevent user code to cast and call Reference::clear. Nit: There is no return value and this @return is not needed. * @return does not return In the test: 228 Object o = r.get(); 229 if (!(r instanceof PhantomReference) && !cleaned) { 230 Reference expectedRef = test.getRef(); 231 Assert.assertEquals(expectedRef.get(), o, 232 "Object reference incorrect"); 233 } Curious on this test case: Is r.get() calling the overridden get() method that always throws null? Mandy > Thanks, Roger > > > > On 12/15/2015 6:01 PM, Peter Levart wrote: >> >> >> On 12/15/2015 11:48 PM, Roger Riggs wrote: >>> Hi Peter, >>> >>> That will break up clearing the ref when the Cleanable is explicitly cleaned. >>> Reference.clear() needs to be called from Cleanable.clean(). >> >> From PhantomCleanable (the superclass of PhantomCleanableRef): >> >> 253 @Override >> 254 public final void clean() { >> 255 if (remove()) { >> 256 super.clear(); >> 257 performCleanup(); >> 258 } >> 259 } >> 260 >> 261 /** >> 262 * Unregister this PhantomCleanable and clear the reference. >> 263 * Due to inherent concurrency, {@link #performCleanup()} may still be invoked. >> 264 */ >> 265 @Override >> 266 public final void clear() { >> 267 if (remove()) { >> 268 super.clear(); >> 269 } >> 270 } >> >> >> ... clean() calls super.clear(), which is "invokespecial" (not a virtual dispatch). >> >> >> Regards, Peter >> >>> >>> it might be nice to block that but to do so we'd need to go back to separate objects >>> for the Reference and the Cleanable and we worked hard to get to a single object. >>> >>> Roger >>> >>> >>> On 12/15/2015 5:38 PM, Peter Levart wrote: >>>> Hi Roger, >>>> >>>> Just one thing about implementation: >>>> >>>> Since the type exposed to user is Cleaner.Cleanable that has only a single method clean(), it would be good if the implementation class (CleanerImpl.PhantomCleanableRef) overrode CleanerImpl.PhantomCleanable.clear() method and threw UnsupportedOperationException, otherwise users will be tempted to cast the returned Cleaner.Cleanable to Reference and invoke clear() method to de-register cleanup action without invoking it. This is the only remaining public Reference method that is not disabled this way. >>>> >>>> Regards, Peter >>>> >>>> On 12/09/2015 07:40 PM, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> The example is revised to caution about inner classes and lambdas. >>>>> >>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>> >>>>> Thanks, Roger >>>>> >>>>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>>>>> Peter, >>>>>>> >>>>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I think the only way to try to prevent such things is with a good >>>>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>>>> >>>>>>>> >>>>>>>> public static class CleanerExample implements AutoCloseable { >>>>>>>> >>>>>>>> private static final Cleaner cleaner = ...; // preferably a >>>>>>>> shared cleaner >>>>>>>> >>>>>>>> private final PrivateNativeResource pnr; >>>>>>>> >>>>>>>> private final Cleaner.Cleanable cleanable; >>>>>>>> >>>>>>>> public CleanerExample(args, ...) { >>>>>>>> >>>>>>>> // prepare captured state as local vars... >>>>>>>> PrivateNativeResource _pnr = ...; >>>>>>>> >>>>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>>>> // DON'T capture any instance fields with lambda since >>>>>>>> that would >>>>>>>> // capture 'this' and prevent it from becoming >>>>>>> >>>>>>> I assume that the WARNING should include anonymous inner classes too >>>>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>>>> >>>>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>>>> the IDE ;-) >>>>>> >>>>>> 'this' only leaks to the 'referent' field of PhantomReference where by definition is not accessible. >>>>>> >>>>>> 'this' can become phantom-reachable before CleanerExample constructor ends. But this is harmless, because the code that may execute at that time does not access the object any more, so the object may be safely collected. >>>>>> >>>>>> Cleanup action can run at any time after registration even before CleanerExample constructor ends. But this is harmless too, because it only accesses PrivateNativeResource which is fully constructed before registration of cleanup action. >>>>>> >>>>>> I see no issues apart from IDE(s) not seeing no issues. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> >>>>>>>> phantom-reachable!!! >>>>>>>> _pnr.close(); >>>>>>>> }); >>>>>>>> >>>>>>>> this.pnr = _pnr; >>>>>>>> } >>>>>>>> >>>>>>>> public void close() { >>>>>>>> cleanable.clean(); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Wed Dec 16 20:30:06 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Dec 2015 12:30:06 -0800 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows Message-ID: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> This is a test fix to reduce the stack depth to avoid StackOverFlow when running with -Xcomp on solaris sparc. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8144553/webrev.00/index.html I verified the tests on solaris-sparcv9 machine with fastdebug VM -Xcomp -ea -esa. Mandy From martinrb at google.com Wed Dec 16 20:39:52 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Dec 2015 12:39:52 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: <56719557.7020606@gmail.com> References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <56717098.8020609@cs.oswego.edu> <56719557.7020606@gmail.com> Message-ID: I'm in agreement with Peter. I don't see "handle", but rather "exceptionally", as the analog of java "catch". I agree with both Doug and Peter that it would be nice to have whenComplete as the analog of finally, but as Peter points out, the exception from the finally block wins, and that strengthens my argument that we should not throw the source exception when the action throws. The existing specs are unclear. I see both -- In the case of method whenComplete, when the supplied action itself encounters an exception, then the stage exceptionally completes with this exception if not already completed exceptionally. If the supplied action itself encounters an exception, then the returned stage exceptionally completes with this exception unless this stage also completed exceptionally (in which case, the returned stage exceptionally completes with the original exception). -- and I am reading those differently (but "if not already completed exceptionally" is ambiguous!) It's time for wave 3, and our failure to agree here is in the way a little. On Wed, Dec 16, 2015 at 8:46 AM, Peter Levart wrote: > Hi Doug, > > > On 12/16/2015 03:09 PM, Doug Lea wrote: >> >> On 12/02/2015 07:51 PM, Martin Buchholz wrote: >>> >>> We're stuck. Peter wants to make Throwables cloneable, I want to >>> reverse the order of throwables and add the past Throwable as a >>> suppressed exception to the exception of a dependent action, and Doug >>> wants the current webrev behavior of adding the dependent action as a >>> suppressed exception of the source. >>> >> >> After letting this sit for a week or so, I think the main issue >> here is that we do not properly explain how and when to use >> whenComplete() vs handle(). We should explain that handle() >> should be used in the same way as "catch", and whenComplete as >> "finally"/try-with-resources. See below. >> >> Given this, the most appropriate response in whenComplete upon >> a secondary exception encountered when handling the primary exception >> is the same as the finally-based scheme used in try-with-resources: >> primary.addSuppressed(secondary). Which we should have done >> originally (vs dropping secondary), and is the current proposed >> webrev. >> >> (In contrast, if someone would like to translate one exception >> into another by throwing the new one, they could use handle().) >> >> Peter raised the issue that addSuppressed could visibly (but safely) >> alter the primary while it is visible to some concurrent action. >> Which is true, but also no different than is possible with >> try-with-resources (consider that the primary exception there could >> be already somehow accessible). > > > It could be, but in try-with-resources there is usually just a sequence of > actions in a single thread that is always deterministic, while in > whenCompleteAsync for example, a thread requesting the outcome of previous > stage can observe it's outcome with suppressed exception added or not, > depending on timing. > >> If exceptions were cloneable, >> it might be less surprising to users in both cases to create a new >> cloned exception with the suppressed secondary. But I think we now >> agree that pseudo-cloning exceptions has even more opportunity for >> surprising users, so should be done only when there aren't any >> alternatives. >> >> Agreed? > > > Agreed. Pseudo cloning (using reflection to invoke constructor) is not > reliable. > >> >> Here's a clarification for CompletionStage (un-reformatted). >> Improvements welcome. Someday we might consider adding some examples. >> >> * >> *
  • Two method forms support processing whether the triggering >> * stage completed normally or exceptionally: Method {@link >> ! * #whenComplete whenComplete} allows injection of an action >> * regardless of outcome, otherwise preserving the outcome in its >> ! * completion. Method {@link #handle handle} additionally allows the >> * stage to compute a replacement result that may enable further >> * processing by other dependent stages. In all other cases, if a >> * stage's computation terminates abruptly with an (unchecked) >> --- 58,66 ---- >> * >> *
  • Two method forms support processing whether the triggering >> * stage completed normally or exceptionally: Method {@link >> ! * #whenComplete whenComplete} is similar to a {@code finally} clause, >> allowing injection of an action >> * regardless of outcome, otherwise preserving the outcome in its > > > The finally block (in classical try/finally or in > try-with-resources/finally) preserves the outcome of try block only if the > finally block completes normally. Otherwise the outcome is replaced with the > exception thrown or value returned in finally block. For example: > > // IllegalStateException propagates out of: > > try { > throw new IllegalArgumentException(); > } finally { > throw new IllegalStateException(); > } > > // as well as out of: > > try (AutoCloseable r = () -> {}){ > throw new IllegalArgumentException(); > } finally { > throw new IllegalStateException(); > } > > // this method returns 2: > > public static int x() { > try { > return 1; > } finally { > return 2; > } > } > > If we are talking about the automatic clean-up action > (AutoCloseable::close()) and not of the finally block, then the exceptional > outcome of try block is always preserved and the exception thrown from > AutoCloseable::close() is just added as suppressed to the exception from try > block: > > // IllegalArgumentException propagates out of: > > try (AutoCloseable r = () -> { throw new IllegalStateException(); > }){ > throw new IllegalArgumentException(); > } > > ...but non-exceptional outcome of try block is replaced with the exception > from AutoCloseable::close(): > > // this method throws IllegalStateException: > > public static int x() throws Exception { > try (AutoCloseable r = () -> { throw new IllegalStateException(); > }){ > return 12; > } > } > > If we are talking about auto-closing, then the text should not speak about > "finally", as whenComplete is not equivalent to finally block then. > > Since whenComplete takes a BiConsumer, it can not "replace" the > non-exceptional outcome of previous stage. In this respect it is more > similar to void method AutoCloseable::close() than it is to finally block > which can return a value from the method. So perhaps we should model it to > the AutoCloseable::close() in try-with-resources then. Which is what is > proposed. It's just that non-determinism when multiple threads are involved > that might cause surprises. > > Regards, Peter > > >> ! * completion. Method {@link #handle handle} is similar to a {@code >> catch} clause, allowing the >> * stage to compute a replacement result that may enable further >> * processing by other dependent stages. In all other cases, if a >> * stage's computation terminates abruptly with an (unchecked) >> > From Roger.Riggs at Oracle.com Wed Dec 16 20:42:37 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 16 Dec 2015 15:42:37 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: References: <560D3F61.6040607@Oracle.com> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.2020605@Oracle.com> Message-ID: <5671CCBD.10501@Oracle.com> Hi Mandy, On 12/16/2015 3:07 PM, Mandy Chung wrote: > The change >> On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: >> >> Hi Peter, >> >> It was a bit more involved than I expected, mostly in the tests to make this change. >> >> Is this what you expected? (just the deltas, I'll merge the patches before pushing). >> >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ >> > This change looks good. Having clear() throwing UOE is right thing to do and prevent user code to cast and call Reference::clear. > > Nit: There is no return value and this @return is not needed. > * @return does not return right > > In the test: > 228 Object o = r.get(); > 229 if (!(r instanceof PhantomReference) && !cleaned) { > 230 Reference expectedRef = test.getRef(); > 231 Assert.assertEquals(expectedRef.get(), o, > 232 "Object reference incorrect"); > 233 } > > Curious on this test case: Is r.get() calling the overridden get() method that always throws null? The verifyGetRef is used to test both the subclassable XXXCleanable refs and the PhantomCleanableRef that is exposed using Cleaner.register. verifyGetRef can be simplified since it is only used (now) to verify the ref before it is cleaned so get returns non-null, except for phantoms. Thanks, Roger > > Mandy > > >> Thanks, Roger >> >> >> >> On 12/15/2015 6:01 PM, Peter Levart wrote: >>> >>> On 12/15/2015 11:48 PM, Roger Riggs wrote: >>>> Hi Peter, >>>> >>>> That will break up clearing the ref when the Cleanable is explicitly cleaned. >>>> Reference.clear() needs to be called from Cleanable.clean(). >>> From PhantomCleanable (the superclass of PhantomCleanableRef): >>> >>> 253 @Override >>> 254 public final void clean() { >>> 255 if (remove()) { >>> 256 super.clear(); >>> 257 performCleanup(); >>> 258 } >>> 259 } >>> 260 >>> 261 /** >>> 262 * Unregister this PhantomCleanable and clear the reference. >>> 263 * Due to inherent concurrency, {@link #performCleanup()} may still be invoked. >>> 264 */ >>> 265 @Override >>> 266 public final void clear() { >>> 267 if (remove()) { >>> 268 super.clear(); >>> 269 } >>> 270 } >>> >>> >>> ... clean() calls super.clear(), which is "invokespecial" (not a virtual dispatch). >>> >>> >>> Regards, Peter >>> >>>> it might be nice to block that but to do so we'd need to go back to separate objects >>>> for the Reference and the Cleanable and we worked hard to get to a single object. >>>> >>>> Roger >>>> >>>> >>>> On 12/15/2015 5:38 PM, Peter Levart wrote: >>>>> Hi Roger, >>>>> >>>>> Just one thing about implementation: >>>>> >>>>> Since the type exposed to user is Cleaner.Cleanable that has only a single method clean(), it would be good if the implementation class (CleanerImpl.PhantomCleanableRef) overrode CleanerImpl.PhantomCleanable.clear() method and threw UnsupportedOperationException, otherwise users will be tempted to cast the returned Cleaner.Cleanable to Reference and invoke clear() method to de-register cleanup action without invoking it. This is the only remaining public Reference method that is not disabled this way. >>>>> >>>>> Regards, Peter >>>>> >>>>> On 12/09/2015 07:40 PM, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> The example is revised to caution about inner classes and lambdas. >>>>>> >>>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>>> >>>>>> Thanks, Roger >>>>>> >>>>>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>>>>>> Peter, >>>>>>>> >>>>>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I think the only way to try to prevent such things is with a good >>>>>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>>>>> >>>>>>>>> >>>>>>>>> public static class CleanerExample implements AutoCloseable { >>>>>>>>> >>>>>>>>> private static final Cleaner cleaner = ...; // preferably a >>>>>>>>> shared cleaner >>>>>>>>> >>>>>>>>> private final PrivateNativeResource pnr; >>>>>>>>> >>>>>>>>> private final Cleaner.Cleanable cleanable; >>>>>>>>> >>>>>>>>> public CleanerExample(args, ...) { >>>>>>>>> >>>>>>>>> // prepare captured state as local vars... >>>>>>>>> PrivateNativeResource _pnr = ...; >>>>>>>>> >>>>>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>>>>> // DON'T capture any instance fields with lambda since >>>>>>>>> that would >>>>>>>>> // capture 'this' and prevent it from becoming >>>>>>>> I assume that the WARNING should include anonymous inner classes too >>>>>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>>>>> >>>>>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>>>>> the IDE ;-) >>>>>>> 'this' only leaks to the 'referent' field of PhantomReference where by definition is not accessible. >>>>>>> >>>>>>> 'this' can become phantom-reachable before CleanerExample constructor ends. But this is harmless, because the code that may execute at that time does not access the object any more, so the object may be safely collected. >>>>>>> >>>>>>> Cleanup action can run at any time after registration even before CleanerExample constructor ends. But this is harmless too, because it only accesses PrivateNativeResource which is fully constructed before registration of cleanup action. >>>>>>> >>>>>>> I see no issues apart from IDE(s) not seeing no issues. >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> >>>>>>>>> phantom-reachable!!! >>>>>>>>> _pnr.close(); >>>>>>>>> }); >>>>>>>>> >>>>>>>>> this.pnr = _pnr; >>>>>>>>> } >>>>>>>>> >>>>>>>>> public void close() { >>>>>>>>> cleanable.clean(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> From martinrb at google.com Wed Dec 16 20:48:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Dec 2015 12:48:55 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <56717098.8020609@cs.oswego.edu> <56719557.7020606@gmail.com> Message-ID: One more point - In try-with-resources it's clear that the try body is the "main event" while the auto-generated calls to close are intended to be "cleanup", so it's natural that the try body exception wins. With whenComplete: - it's less obvious that the whenComplete action is unimportant - both CompletionStages may remain accessible so the risk of losing the source exception is lower, and preserving the integrity of the source exception is more valuable. From mandy.chung at oracle.com Wed Dec 16 20:59:35 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Dec 2015 12:59:35 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5671CCBD.10501@Oracle.com> References: <560D3F61.6040607@Oracle.com> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.2020605@Oracle.com> <5671C! CBD.10501@Oracle.com> Message-ID: <847A34BA-27BF-4C00-9893-21E7CD569E90@oracle.com> > On Dec 16, 2015, at 12:42 PM, Roger Riggs wrote: > Nit: There is no return value and this @return is not needed. >> * @return does not return >> > right I?m seeing this in other places. You can take them out before you push (no new webrev needed). >> >> In the test: >> 228 Object o = r.get(); >> 229 if (!(r instanceof PhantomReference) && !cleaned) { >> 230 Reference expectedRef = test.getRef(); >> 231 Assert.assertEquals(expectedRef.get(), o, >> 232 "Object reference incorrect"); >> 233 } >> >> Curious on this test case: Is r.get() calling the overridden get() method that always throws null? >> > The verifyGetRef is used to test both the subclassable XXXCleanable refs and > the PhantomCleanableRef that is exposed using Cleaner.register. > verifyGetRef can be simplified since it is only used (now) to verify the ref before it is cleaned so get returns non-null, except for phantoms. > I see it now - this object is an instance of the test?s defined subclass. is not a PhantomCleanableRef (nor Weak/Soft). The confusion comes from: 234 } catch (UnsupportedOperationException uoe) { this method may verify the objects created from Cleaner. It may be a good future improvement to separate the custom subclass and Cleaner implementation to make it easier to understand. Thanks. No further comment from me. Mandy From xueming.shen at oracle.com Wed Dec 16 21:17:05 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 16 Dec 2015 13:17:05 -0800 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5671B773.3070500@oracle.com> References: <5671B773.3070500@oracle.com> Message-ID: <5671D4D1.6060200@oracle.com> +1 On 12/16/15, 11:11 AM, Aleksey Shipilev wrote: > Hi, > > I would like to suggest a simple cleanup/improvement in current > StringUTF16, which somewhat closes the gap between C1 and C2 performance > with Compact Strings: > https://bugs.openjdk.java.net/browse/JDK-8145428 > http://cr.openjdk.java.net/~shade/8145428/webrev.02/ > > It does improve the score on C1 (-client) configurations significantly, > without affecting C2 performance (because we basically modifying the > code that C2 would overthrow with vectorized intrinsic): > http://cr.openjdk.java.net/~shade/8145428/notes.txt > > ...and the generated code looks much better now. It also alleviates some > performance regressions on client configurations we observed in a > regular performance testing. > > The subsequent improvements may further eliminate range checks, plus > unroll/vectorize the loop, but I would like to defer that until array > comparison intrinsics are stable and exposed to both C1 and C2. > > Testing: microbenchmarks, JPRT > > Thanks, > -Aleksey > From joe.darcy at oracle.com Wed Dec 16 21:58:40 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 16 Dec 2015 13:58:40 -0800 Subject: JDK 9 RFR to problem list a failing test Message-ID: <5671DE90.10600@oracle.com> Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: error: cannot find symbol import sun.misc.BASE64Encoder; ^ symbol: class BASE64Encoder location: package sun.misc /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:43: error: cannot find symbol Class type = BASE64Encoder.class; ^ symbol: class BASE64Encoder location: class Test6277246 2 errors result: Failed. Compilation failed: Compilation failed While the underlying issues is being worked on (JDK-8145589), I'd like to problem list the test as shown in the patch below. Thanks, -Joe diff -r 98d9eb6f737f test/ProblemList.txt --- a/test/ProblemList.txt Wed Dec 16 20:00:03 2015 +0100 +++ b/test/ProblemList.txt Wed Dec 16 13:56:58 2015 -0800 @@ -126,6 +126,9 @@ java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all +# 8145589 +java/beans/Introspector/Test6277246.java generic-all + ############################################################################ # jdk_lang From xueming.shen at oracle.com Wed Dec 16 22:00:35 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 16 Dec 2015 14:00:35 -0800 Subject: JDK 9 RFR to problem list a failing test In-Reply-To: <5671DE90.10600@oracle.com> References: <5671DE90.10600@oracle.com> Message-ID: <5671DF03.3090309@oracle.com> + 1 On 12/16/15, 1:58 PM, joe darcy wrote: > Hello, > > The test > > java/beans/Introspector/Test6277246.java > > fails to compile after the change for JDK-8144479 , reporting an error > > /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: > error: cannot find symbol > import sun.misc.BASE64Encoder; > ^ > symbol: class BASE64Encoder > location: package sun.misc > /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:43: > error: cannot find symbol > Class type = BASE64Encoder.class; > ^ > symbol: class BASE64Encoder > location: class Test6277246 > 2 errors > result: Failed. Compilation failed: Compilation failed > > While the underlying issues is being worked on (JDK-8145589), I'd like > to problem list the test as shown in the patch below. > > Thanks, > > -Joe > > diff -r 98d9eb6f737f test/ProblemList.txt > --- a/test/ProblemList.txt Wed Dec 16 20:00:03 2015 +0100 > +++ b/test/ProblemList.txt Wed Dec 16 13:56:58 2015 -0800 > @@ -126,6 +126,9 @@ > java/beans/Introspector/8132566/OverridePropertyInfoTest.java > generic-all > java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java > generic-all > > +# 8145589 > +java/beans/Introspector/Test6277246.java generic-all > + > ############################################################################ > > > # jdk_lang > From mandy.chung at oracle.com Wed Dec 16 22:18:09 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Dec 2015 14:18:09 -0800 Subject: JDK 9 RFR to problem list a failing test In-Reply-To: <5671DE90.10600@oracle.com> References: <5671DE90.10600@oracle.com> Message-ID: > On Dec 16, 2015, at 1:58 PM, joe darcy wrote: > > > diff -r 98d9eb6f737f test/ProblemList.txt > --- a/test/ProblemList.txt Wed Dec 16 20:00:03 2015 +0100 > +++ b/test/ProblemList.txt Wed Dec 16 13:56:58 2015 -0800 > @@ -126,6 +126,9 @@ > java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all > java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all > > +# 8145589 > +java/beans/Introspector/Test6277246.java generic-all > + > ############################################################################ +1 JDK-8145589 missed to update this test. Mandy From Sergey.Bylokhov at oracle.com Wed Dec 16 22:20:54 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Dec 2015 01:20:54 +0300 Subject: JDK 9 RFR to problem list a failing test In-Reply-To: <5671DE90.10600@oracle.com> References: <5671DE90.10600@oracle.com> Message-ID: <5671E3C6.8040106@oracle.com> Hi, Joe. I think it is quite easy to fix the test itself. Just use some other existed class from sun.misc. On 17/12/15 00:58, joe darcy wrote: > Hello, > > The test > > java/beans/Introspector/Test6277246.java > > fails to compile after the change for JDK-8144479 , reporting an error > > /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: > error: cannot find symbol > import sun.misc.BASE64Encoder; > ^ > symbol: class BASE64Encoder > location: package sun.misc > /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:43: > error: cannot find symbol > Class type = BASE64Encoder.class; > ^ > symbol: class BASE64Encoder > location: class Test6277246 > 2 errors > result: Failed. Compilation failed: Compilation failed > > While the underlying issues is being worked on (JDK-8145589), I'd like > to problem list the test as shown in the patch below. > > Thanks, > > -Joe > > diff -r 98d9eb6f737f test/ProblemList.txt > --- a/test/ProblemList.txt Wed Dec 16 20:00:03 2015 +0100 > +++ b/test/ProblemList.txt Wed Dec 16 13:56:58 2015 -0800 > @@ -126,6 +126,9 @@ > java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all > java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java > generic-all > > +# 8145589 > +java/beans/Introspector/Test6277246.java generic-all > + > ############################################################################ > > # jdk_lang > -- Best regards, Sergey. From pbenedict at apache.org Wed Dec 16 22:25:00 2015 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 16 Dec 2015 16:25:00 -0600 Subject: JDK 9 RFR to problem list a failing test In-Reply-To: <5671DF03.3090309@oracle.com> References: <5671DE90.10600@oracle.com> <5671DF03.3090309@oracle.com> Message-ID: Unless there's a reason not to, sun.misc.BASE64Encoder can replaced with its equivalent java.util.Base64. Cheers, Paul On Wed, Dec 16, 2015 at 4:00 PM, Xueming Shen wrote: > + 1 > > > On 12/16/15, 1:58 PM, joe darcy wrote: > >> Hello, >> >> The test >> >> java/beans/Introspector/Test6277246.java >> >> fails to compile after the change for JDK-8144479 , reporting an error >> >> /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: >> error: cannot find symbol >> import sun.misc.BASE64Encoder; >> ^ >> symbol: class BASE64Encoder >> location: package sun.misc >> /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:43: >> error: cannot find symbol >> Class type = BASE64Encoder.class; >> ^ >> symbol: class BASE64Encoder >> location: class Test6277246 >> 2 errors >> result: Failed. Compilation failed: Compilation failed >> >> While the underlying issues is being worked on (JDK-8145589), I'd like to >> problem list the test as shown in the patch below. >> >> Thanks, >> >> -Joe >> >> diff -r 98d9eb6f737f test/ProblemList.txt >> --- a/test/ProblemList.txt Wed Dec 16 20:00:03 2015 +0100 >> +++ b/test/ProblemList.txt Wed Dec 16 13:56:58 2015 -0800 >> @@ -126,6 +126,9 @@ >> java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all >> java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java >> generic-all >> >> +# 8145589 >> +java/beans/Introspector/Test6277246.java generic-all >> + >> ############################################################################ >> >> >> # jdk_lang >> >> > From Sergey.Bylokhov at oracle.com Wed Dec 16 22:48:03 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Dec 2015 01:48:03 +0300 Subject: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections In-Reply-To: <66E32A01-D61A-4CB8-8BC4-5C3D07A3BFCA@oracle.com> References: <6474B0A2-884E-4152-8594-C8930A90FF0D@oracle.com> <566D5389.20709@oracle.com> <8FAF464A-C9A8-4E65-AE14-2F08593B6A5D@oracle.com> <66E32A01-D61A-4CB8-8BC4-5C3D07A3BFCA@oracle.com> Message-ID: <5671EA23.5050006@oracle.com> >>> What is the reason to use assertion? If the problem is not theoretical, > > That was tricky to spot :-) nearly missed it. > Since the queue is not "capacity-restricted" i think add(E) is the more appropriate choice. +1 I think so. > > ? > > I suspect this use of queues in AppletPanel could be cleaned up given the usages of with synchronised blocks (and the sun.misc.Queue style is probably a hangover from the java.util.Vector days). Anyway, that?s for another day if the AWT devs want to take that on :-) > > Paul. > >> >>> then probably OOM(or something like that) will be better? >> >> I don?t think OOM is quite right. Maybe ISE, as above is better? >> >> -Chris. >> >> >>> On 11/12/15 20:22, Chris Hegarty wrote: >>>> More technical debt in sun.misc? >>>> >>>> Java SE has had support for Queues in Collections for many major releases, >>>> sun.misc.Queue seems to predate that. I cannot find any usages outside of the >>>> JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to >>>> provide the necessary minimum functionality required by AppletPanel, FIFO >>>> blocking operations. >>>> >>>> The changes are quite small so I just included the diffs inline. >>>> >>>> Note: we could use either add(E) or offer(E) below, I don?t have a strong opinion >>>> either way. >>>> >>>> $ hg rm src/java.base/share/classes/sun/misc/Queue.java >>>> >>>> diff --git a/src/java.desktop/share/classes/sun/applet/AppletPanel.java b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>>> --- a/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>>> +++ b/src/java.desktop/share/classes/sun/applet/AppletPanel.java >>>> @@ -38,6 +38,7 @@ >>>> import java.security.*; >>>> import java.util.*; >>>> import java.util.Locale; >>>> +import java.util.concurrent.LinkedBlockingQueue; >>>> import sun.awt.AWTAccessor; >>>> import sun.awt.AppContext; >>>> import sun.awt.EmbeddedFrame; >>>> @@ -45,7 +46,6 @@ >>>> import sun.misc.ManagedLocalsThread; >>>> import sun.misc.MessageUtils; >>>> import sun.misc.PerformanceLogger; >>>> -import sun.misc.Queue; >>>> import sun.security.util.SecurityConstants; >>>> >>>> /** >>>> @@ -247,8 +247,7 @@ >>>> /** >>>> * AppletEvent Queue >>>> */ >>>> - private Queue queue = null; >>>> - >>>> + private LinkedBlockingQueue queue = null; >>>> >>>> public synchronized void addAppletListener(AppletListener l) { >>>> listeners = AppletEventMulticaster.add(listeners, l); >>>> @@ -276,10 +275,10 @@ >>>> synchronized(this) { >>>> if (queue == null) { >>>> //System.out.println("SEND0= " + id); >>>> - queue = new Queue<>(); >>>> + queue = new LinkedBlockingQueue<>(); >>>> } >>>> - Integer eventId = Integer.valueOf(id); >>>> - queue.enqueue(eventId); >>>> + boolean inserted = queue.offer(id); >>>> + assert inserted; >>>> notifyAll(); >>>> } >>>> if (id == APPLET_QUIT) { >>>> @@ -303,8 +302,8 @@ >>>> while (queue == null || queue.isEmpty()) { >>>> wait(); >>>> } >>>> - Integer eventId = queue.dequeue(); >>>> - return new AppletEvent(this, eventId.intValue(), null); >>>> + int eventId = queue.take(); >>>> + return new AppletEvent(this, eventId, null); >>>> } >>>> >>>> boolean emptyEventQueue() { >>>> >>>> -Chris. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > -- Best regards, Sergey. From aleksey.shipilev at oracle.com Wed Dec 16 22:53:10 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 01:53:10 +0300 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile Message-ID: <5671EB56.4070805@oracle.com> Hi, Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private volatile fields. Their only use is to cache keySet and valueSet implementations from java.util collections. However, all relevant java.util collections are not having any declared fields (an opaque reference to enclosing class is stored in final field), and they delegate straight to the backing collection. Therefore, any race on cache field is benign, and we can drop "volatile" from the fields: https://bugs.openjdk.java.net/browse/JDK-8145539 http://cr.openjdk.java.net/~shade/8145539/webrev.02/ This improves performance for keySet()/values() on AbstractMap implementations, because we don't emit barriers (volatile write in x86 case). This does not affect AbstractMap subclasses allocation performance, because the volatile field values were default since JDK-8035284. See: http://cr.openjdk.java.net/~shade/8145539/HashMapBench.java Testing: microbenchmarks, java/util jtreg on Linux x86_64 Thanks, -Aleksey From claes.redestad at oracle.com Wed Dec 16 23:26:45 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Dec 2015 00:26:45 +0100 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5671EB56.4070805@oracle.com> References: <5671EB56.4070805@oracle.com> Message-ID: <5671F335.1030207@oracle.com> Hi, yes, since the fields are package-private, this seems OK. /Claes On 2015-12-16 23:53, Aleksey Shipilev wrote: > Hi, > > Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as > package-private volatile fields. Their only use is to cache keySet and > valueSet implementations from java.util collections. > > However, all relevant java.util collections are not having any declared > fields (an opaque reference to enclosing class is stored in final > field), and they delegate straight to the backing collection. Therefore, > any race on cache field is benign, and we can drop "volatile" from the > fields: > https://bugs.openjdk.java.net/browse/JDK-8145539 > http://cr.openjdk.java.net/~shade/8145539/webrev.02/ > > This improves performance for keySet()/values() on AbstractMap > implementations, because we don't emit barriers (volatile write in x86 > case). This does not affect AbstractMap subclasses allocation > performance, because the volatile field values were default since > JDK-8035284. > > See: > http://cr.openjdk.java.net/~shade/8145539/HashMapBench.java > > Testing: microbenchmarks, java/util jtreg on Linux x86_64 > > Thanks, > -Aleksey > From Ulf.Zibis at CoSoCo.de Wed Dec 16 23:34:08 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Thu, 17 Dec 2015 00:34:08 +0100 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5671B773.3070500@oracle.com> References: <5671B773.3070500@oracle.com> Message-ID: <5671F4F0.4000505@CoSoCo.de> Hi, I'm wondering why moving the increment operation to an extra line wound enhance performance. To prevent others from redoing the change later, I think a comment is needed. -Ulf Am 16.12.2015 um 20:11 schrieb Aleksey Shipilev: > Hi, > > I would like to suggest a simple cleanup/improvement in current > StringUTF16, which somewhat closes the gap between C1 and C2 performance > with Compact Strings: > https://bugs.openjdk.java.net/browse/JDK-8145428 > http://cr.openjdk.java.net/~shade/8145428/webrev.02/ > > It does improve the score on C1 (-client) configurations significantly, > without affecting C2 performance (because we basically modifying the > code that C2 would overthrow with vectorized intrinsic): > http://cr.openjdk.java.net/~shade/8145428/notes.txt > > ...and the generated code looks much better now. It also alleviates some > performance regressions on client configurations we observed in a > regular performance testing. > > The subsequent improvements may further eliminate range checks, plus > unroll/vectorize the loop, but I would like to defer that until array > comparison intrinsics are stable and exposed to both C1 and C2. > > Testing: microbenchmarks, JPRT > > Thanks, > -Aleksey > > From powers.anirvan at gmail.com Thu Dec 17 04:40:06 2015 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Thu, 17 Dec 2015 10:10:06 +0530 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <5671796C.1030406@gmail.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> <5671796C.1030406@gmail.com> Message-ID: (Not an OpenJDK reviewer) Hi, I was wondering if the CRC32 implementation in TraditionalZipCryption could be replaced with java.util.zip.CRC32 class. Though I note that in this case TraditionalZipCryption#updateKeys(int c) will require CRC32#update(int crc, int b) method which is currently marked as private. Maybe its access specification could be relaxed a little to be package-private? Regards, Anirvan On 16 December 2015 at 20:17, Yasumasa Suenaga wrote: > Hi Sergey, > > Thank you for your comment. > > I added that description in new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ > > > Thanks, > > Yasumasa > > > > On 2015/12/16 22:19, Sergey Bylokhov wrote: > >> Should the new methods describe how they will work in case of null params? >> >> On 16/12/15 16:04, Yasumasa Suenaga wrote: >> >>> I adapted this enhancement after JDK-8145260: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>> >>>> Hi Sherman, >>>> >>>> Our proposal is affected by JDK-8142508. >>>> We have to change ZipFile.java and and ZipFile.c . >>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>>> repos. >>>> >>>> Do you have any comments about current webrev? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>> >>>> If you have comments, we will fix them in new webrev. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>> >>>>> Hi Sherman, >>>>> >>>>> Thanks for your quick response :) >>>>> >>>>> I aimed to implement the "traditional" at this proposal by the below >>>>> reasons. >>>>> >>>>> * We want to prepare API for encrypted zip files at first. >>>>> * Many people use the "traditional" in problem-free scope like a >>>>> temporary file. >>>>> * We do not know which implementation of the "stronger" is best for >>>>> openjdk. >>>>> * PKWare claims that they have patents about the "stronger" on >>>>> Zip[1]. >>>>> * OTOH, WinZip have the alternative implementation of the >>>>> "stronger" [2][3]. >>>>> * Instead, we prepared the extensibility by ZipCryption interface to >>>>> implement other encrypt engine, such as the AES based. >>>>> >>>>> Thus, I think this PoC should support the "traditional" only. >>>>> In the future, anyone who want to implement the "stronger" can easily >>>>> add their code by virtue of this proposal. >>>>> >>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>>> [2] >>>>> >>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>>> >>>>> [3] http://www.winzip.com/aes_info.htm >>>>> >>>>> Thanks, >>>>> Yuji >>>>> >>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>> >>>>>> >>>>>> Hi Yuji, >>>>>> >>>>>> I will take a look at your PoC. Might need some time and even bring >>>>>> in the >>>>>> security guy >>>>>> to evaluate the proposal. It seems like you are only interested in the >>>>>> "traditional PKWare >>>>>> decryption", which is, based on the wiki, "known to be seriously >>>>>> flawed, and >>>>>> in particular >>>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>>> "stronger" encryption >>>>>> mechanism, such as the AES based? >>>>>> >>>>>> Regards, >>>>>> Sherman >>>>>> >>>>>> >>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We need reviewer(s) for this PoC. >>>>>>> Could you please review this proposal and PoC ? >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>>>> >>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> * Sorry for my mistake. I re-post this mail because I sent before >>>>>>>> get >>>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>>> >>>>>>>> Our customers have to handle password-protected zip files. However, >>>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>>> third party library so far. >>>>>>>> >>>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>>> >>>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>>> The >>>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>>> implementation. >>>>>>>> >>>>>>>> We've created PoC and uploaded it as webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>>> >>>>>>>> Test code is as below. This code will let you know how this >>>>>>>> PoC >>>>>>>> works. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>>> >>>>>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>>> implement to >>>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>>> desired for many developers and users. >>>>>>>> >>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>>> (ysuenaga). >>>>>>>> We want to implement it if this proposal accepted. >>>>>>>> >>>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yuji >>>>>>>> >>>>>>> >>>>>> >>>>>> >> >> -- Anirvan From jeremymanson at google.com Thu Dec 17 06:05:25 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 16 Dec 2015 22:05:25 -0800 Subject: Need help to understand TLS behavior In-Reply-To: <5670F936.7010409@oracle.com> References: <566EB5A4.5080102@oracle.com> <566EB746.3040801@oracle.com> <566EBD2B.9010803@oracle.com> <566EBEC0.1000609@oracle.com> <566F2AFA.3000805@oracle.com> <566F9ABB.9050804@oracle.com> <566FC07C.8010509@oracle.com> <5670F936.7010409@oracle.com> Message-ID: On Tue, Dec 15, 2015 at 9:40 PM, David Holmes wrote: > > > On 16/12/2015 8:03 AM, Jeremy Manson wrote: > >> >> I expect the official answer from you guys about this is going to end up >> being "bump your Xss if you really care", which is deeply sad. >> > > As a point fix a way to change the stack size of the process reaper thread > might suffice. But that is a band-aid. I can imagine bugs of the form "when > we run our Java code stand-alone it runs fine, but as soon as we embed the > JVM in our own application front-end it fails with StackOverflowErrors > everywhere". :( > > Why do you think we have the local patch in the first place? The horse has bolted on this being a problem for real users. We're just lucky enough (or insane enough) to roll both our own glibc and our own JDK... Jeremy From yasuenag at gmail.com Thu Dec 17 06:40:55 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 17 Dec 2015 15:40:55 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> <5671796C.1030406@gmail.com> Message-ID: Hi Anirvan, j.u.z.CRC32 supports 8-bits value and byte array. update(int, int) which you suggested will calculate lower 8-bits value: http://docs.oracle.com/javase/8/docs/api/java/util/zip/CRC32.html#update-int - http://hg.openjdk.java.net/jdk9/dev/jdk/file/a204b8e18d46/src/java.base/share/classes/java/util/zip/CRC32.java#l58 http://hg.openjdk.java.net/jdk9/dev/jdk/file/a204b8e18d46/src/java.base/share/native/libzip/CRC32.c#l36 Thus this method cannot fit our purpose - we need calculate 32-bits value. If we use j.u.z.CRC32, we also have to add new API to it. Thanks, Yasumasa 2015/12/17 13:40 "Anirvan Sarkar" : > (Not an OpenJDK reviewer) > > Hi, > > I was wondering if the CRC32 implementation in TraditionalZipCryption > could be replaced with java.util.zip.CRC32 class. > > Though I note that in this case TraditionalZipCryption#updateKeys(int c) > will require CRC32#update(int crc, int b) method which is currently > marked as private. Maybe its access specification could be relaxed a > little to be package-private? > > Regards, > Anirvan > > On 16 December 2015 at 20:17, Yasumasa Suenaga wrote: > >> Hi Sergey, >> >> Thank you for your comment. >> >> I added that description in new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ >> >> >> Thanks, >> >> Yasumasa >> >> >> >> On 2015/12/16 22:19, Sergey Bylokhov wrote: >> >>> Should the new methods describe how they will work in case of null >>> params? >>> >>> On 16/12/15 16:04, Yasumasa Suenaga wrote: >>> >>>> I adapted this enhancement after JDK-8145260: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >>>> >>>> Could you review it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>>> >>>>> Hi Sherman, >>>>> >>>>> Our proposal is affected by JDK-8142508. >>>>> We have to change ZipFile.java and and ZipFile.c . >>>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>>>> repos. >>>>> >>>>> Do you have any comments about current webrev? >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>> >>>>> If you have comments, we will fix them in new webrev. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>>> >>>>>> Hi Sherman, >>>>>> >>>>>> Thanks for your quick response :) >>>>>> >>>>>> I aimed to implement the "traditional" at this proposal by the below >>>>>> reasons. >>>>>> >>>>>> * We want to prepare API for encrypted zip files at first. >>>>>> * Many people use the "traditional" in problem-free scope like a >>>>>> temporary file. >>>>>> * We do not know which implementation of the "stronger" is best for >>>>>> openjdk. >>>>>> * PKWare claims that they have patents about the "stronger" on >>>>>> Zip[1]. >>>>>> * OTOH, WinZip have the alternative implementation of the >>>>>> "stronger" [2][3]. >>>>>> * Instead, we prepared the extensibility by ZipCryption interface to >>>>>> implement other encrypt engine, such as the AES based. >>>>>> >>>>>> Thus, I think this PoC should support the "traditional" only. >>>>>> In the future, anyone who want to implement the "stronger" can easily >>>>>> add their code by virtue of this proposal. >>>>>> >>>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>>>> [2] >>>>>> >>>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>>>> >>>>>> [3] http://www.winzip.com/aes_info.htm >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>>> >>>>>>> >>>>>>> Hi Yuji, >>>>>>> >>>>>>> I will take a look at your PoC. Might need some time and even bring >>>>>>> in the >>>>>>> security guy >>>>>>> to evaluate the proposal. It seems like you are only interested in >>>>>>> the >>>>>>> "traditional PKWare >>>>>>> decryption", which is, based on the wiki, "known to be seriously >>>>>>> flawed, and >>>>>>> in particular >>>>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>>>> "stronger" encryption >>>>>>> mechanism, such as the AES based? >>>>>>> >>>>>>> Regards, >>>>>>> Sherman >>>>>>> >>>>>>> >>>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We need reviewer(s) for this PoC. >>>>>>>> Could you please review this proposal and PoC ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yuji >>>>>>>> >>>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> * Sorry for my mistake. I re-post this mail because I sent before >>>>>>>>> get >>>>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>>>> >>>>>>>>> Our customers have to handle password-protected zip files. However, >>>>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>>>> third party library so far. >>>>>>>>> >>>>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>>>> >>>>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>>>> The >>>>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>>>> implementation. >>>>>>>>> >>>>>>>>> We've created PoC and uploaded it as webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>>>> >>>>>>>>> Test code is as below. This code will let you know how this >>>>>>>>> PoC >>>>>>>>> works. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>>>> >>>>>>>>> In NTT, a Japanese telecommunications company. We are providing >>>>>>>>> many >>>>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>>>> implement to >>>>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>>>> desired for many developers and users. >>>>>>>>> >>>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>>>> (ysuenaga). >>>>>>>>> We want to implement it if this proposal accepted. >>>>>>>>> >>>>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yuji >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>> >>> > > > -- > Anirvan > From aleksey.shipilev at oracle.com Thu Dec 17 07:54:37 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 10:54:37 +0300 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5671F4F0.4000505@CoSoCo.de> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> Message-ID: <56726A3D.7020202@oracle.com> On 12/17/2015 02:34 AM, Ulf wrote: > I'm wondering why moving the increment operation to an extra line wound > enhance performance. Because C1 is very straightforward, and code movement like that is a poor man's instruction scheduling, that pads out the data dependency between index update and indexed access. I don't think it deserves a comment -- it is expected one will run the benchmarks when changing that code. Thanks, -Aleksey From vyom.tewari at oracle.com Thu Dec 17 08:14:35 2015 From: vyom.tewari at oracle.com (vyom) Date: Thu, 17 Dec 2015 13:44:35 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56716101.1080502@oracle.com> Message-ID: <56726EEB.6080203@oracle.com> Hi Martin, thanks for review, i undated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.2/ ) as per your comment after confirming that the corresponding "fd" if opened with "open64". Thanks, Vyom On Thursday 17 December 2015 12:38 AM, Martin Buchholz wrote: > Calling naked fstat without _FILE_OFFSET_BITS=64 is a bug. Don't you > need to call fstat64 if it's available? > > +jlong > +handleGetLength(FD fd) > +{ > + struct stat sb; > + if (fstat(fd, &sb) == 0) { > + return sb.st_size; > + } else { > + return -1; > + } > +} > > On Wed, Dec 16, 2015 at 5:02 AM, vyom wrote: >> Hi, >> >> Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ >> ) as per Martin >> review comment removed the _FILE_OFFSET_BITS from source. >> >> Thanks, >> Vyom >> >> >> >> On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: >>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >>> affects interoperability between translation units. It would be good >>> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but >>> that would be a big job. So traditionally the JDK has instead used >>> the functions made available via _LARGEFILE64_SOURCE. But that is >>> also a JDK-wide job now, because every call to plain stat in the >>> source code is broken on 32-bit systems with 64-bit inodes, which are >>> becoming more common. >>> >>> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job >>> for build-dev, not core-libs-dev. >>> >>> >>> >>> >>> On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs >>> wrote: >>>> Hi Yvom, >>>> >>>> Minor comments: >>>> >>>> src/java.base/share/native/libjava/RandomAccessFile.c: >>>> - "length fail" might be clearer as "GetLength failed" >>>> >>>> src/java.base/unix/native/libjava/io_util_md.c: >>>> >>>> - Please add a comment before the define of FILE_OFFSET_BITS to >>>> indicate >>>> where it is used and why it is there. >>>> - BTW, are there any unintended side effects? >>>> Perhaps a different issue but perhaps 64 bit offsets should be used >>>> everywhere >>>> >>>> src/java.base/windows/native/libjava/io_util_md.c >>>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>>> elsewhere in the file >>>> BTW, Testing for invalid handle might be unnecessary since the call >>>> to >>>> GetFileSizeEx will fail >>>> if it is invalid, yielding the same result. >>>> >>>> Roger >>>> >>>> >>>> On 12/10/2015 5:52 AM, vyom wrote: >>>>> Hi All, >>>>> >>>>> Please review my changes for below bug. >>>>> >>>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>>> >>>>> >>>>> This change ensure that length() does not temporarily changes the file >>>>> pointer and it will make sure that there is no race >>>>> condition in case of multi thread uses. >>>>> >>>>> Thanks, >>>>> Vyom >>>>> >>>>> >>>>> >>>>> From konstantin.shefov at oracle.com Thu Dec 17 08:26:54 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 17 Dec 2015 11:26:54 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> Message-ID: <567271CE.3080604@oracle.com> Hi Coleen You have previously reviewed this enhancement and made a few comments I have resolved them, so could you look at the webrevs again, please? I have added tests, removed cp tags that are not in JVM spec (100 - 105) and made some other changes. JDK: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04 HOTSPOT: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 Thanks -Konstantin On 12/16/2015 07:42 PM, Christian Thalinger wrote: > Looks good. Thanks. > >> On Dec 16, 2015, at 1:13 AM, Konstantin Shefov wrote: >> >> Christian >> >> I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. >> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ >> >> -Konstantin >> >> On 12/15/2015 08:36 PM, Christian Thalinger wrote: >>>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov > wrote: >>>> >>>> Hi Christian >>>> >>>> Thanks for reviewing, I have changed indents as you asked: >>>> >>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >>> Thanks. I?m still not comfortable with the enum. It would be great if we could get the values from the VM like in JVMCI: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >>> >>> but that would be overkill here. But I would like to see the enum entries take the integer values as arguments, like here: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >>> >>> and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. >>> >>>> -Konstantin >>>> >>>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov > wrote: >>>>>> >>>>>> Hello >>>>>> >>>>>> Please review the new version on the patch. >>>>>> >>>>>> New webrev: >>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>>> These newlines look ridiculous especially when it?s not even needed: >>>>> >>>>> + // Returns a class reference index for a method or a field. >>>>> + public int getClassRefIndexAt >>>>> + (int index) { return getClassRefIndexAt0 (constantPoolOop, index); } >>>>> >>>>> Either fix the indent or just add them like regular methods should look like. >>>>> >>>>>> What has been changed: >>>>>> 1. Added tests for the new added methods. >>>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and left only codes from the open JVM spec (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>>> >>>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>>> Coleen, >>>>>>> Thanks for review >>>>>>> >>>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>>> I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be added with the functionality changeset, not promised afterward. >>>>>>> I will add tests. >>>>>>>> Secondly, I do not like that JDK code knows the implementation details of the JVM's constant pool tags. These should be only for internal use. >>>>>>> The package "sun.reflect" is for internal use only, so it shouldn?t be a problem. >>>>>>>> My third comment is that I haven't looked carefully at this constant pool implementation but it seems very unsafe if the class is redefined and relies on an implementation detail in the JVM that can change. I will have more comments once I look more at the jvmti specification. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Please, review modified webrev. >>>>>>>>> >>>>>>>>> I have added methods >>>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type entry index from a method, field or indy entry index; >>>>>>>>> getClassRefIndexAt(int index) - to get class entry index from a method or field entry index; >>>>>>>>> >>>>>>>>> I removed previously added method >>>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now. >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Konstantin >>>>>>>>> >>>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>>> Remi, >>>>>>>>>> >>>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>>> May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. >>>>>>>>>> >>>>>>>>>> -Konstantin >>>>>>>>>> >>>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>>> Hi Konstantin, >>>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>>> >>>>>>>>>>> In term of API, I think it's better to decompose the API, i.e. to have a method >>>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>>> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. >>>>>>>>>>> >>>>>>>>>>> cheers, >>>>>>>>>>> R?mi >>>>>>>>>>> >>>>>>>>>>> ----- Mail original ----- >>>>>>>>>>>> De: "Christian Thalinger" > >>>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>>> Cc: "hotspot-dev developers" , core-libs-dev at openjdk.java.net >>>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool >>>>>>>>>>>> >>>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>>> >>>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello >>>>>>>>>>>>> >>>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>>> >>>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string >>>>>>>>>>>>> representation of name and type from a NameAndType constant pool entry >>>>>>>>>>>>> with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string >>>>>>>>>>>>> representation of name and type from an InvokeDynamic constant pool entry >>>>>>>>>>>>> with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant >>>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>>> >>>>>>>>>>>>> These three methods could be used for testing API working with constant >>>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>>> >>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Konstantin From abhijit.r.roy at oracle.com Thu Dec 17 08:55:45 2015 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Thu, 17 Dec 2015 00:55:45 -0800 (PST) Subject: Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter In-Reply-To: <2b3a86bc-807a-4a56-a85c-c4adeee62dc5@default> References: <567260F6.2070508@oracle.com> <7f1d3edc-b17d-47d9-97d5-069664a219e3@default> <2b3a86bc-807a-4a56-a85c-c4adeee62dc5@default> Message-ID: <12eea865-5de6-400b-8b8f-c445bcb35ada@default> Hi all, ?Please review a fix for Bug ?- https://bugs.openjdk.java.net/browse/JDK-8145545? Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ ?I have just rectified and modified those error. And moving forward it for review. ? ? Regards, Abhijit. From sean.coffey at oracle.com Thu Dec 17 11:29:55 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 Dec 2015 11:29:55 +0000 Subject: Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter In-Reply-To: <12eea865-5de6-400b-8b8f-c445bcb35ada@default> References: <567260F6.2070508@oracle.com> <7f1d3edc-b17d-47d9-97d5-069664a219e3@default> <2b3a86bc-807a-4a56-a85c-c4adeee62dc5@default> <12eea865-5de6-400b-8b8f-c445bcb35ada@default> Message-ID: <56729CB3.5050907@oracle.com> Looks fine. Regards, Sean. On 17/12/2015 08:55, Abhijit Roy wrote: > Hi all, > > Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145545 > > Bug - Typos in Javadoc of XmlAdapter > > Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ > > I have just rectified and modified those error. And moving forward it for review. > > > > > > Regards, > > Abhijit. From peter.levart at gmail.com Thu Dec 17 12:07:38 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Dec 2015 13:07:38 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5671BFB9.2020605@Oracle.com> References: <560D3F61.6040607@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.2020605@Oracle.com> Message-ID: <5672A58A.3010307@gmail.com> Hi Roger, On 12/16/2015 08:47 PM, Roger Riggs wrote: > Hi Peter, > > It was a bit more involved than I expected, mostly in the tests to > make this change. > > Is this what you expected? (just the deltas, I'll merge the patches > before pushing). > > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ > > Thanks, Roger Yes, that's what I meant. The method is not final any more, but that's OK for now as those classes are encapsulated. If this ever gets exposed as a public API, it could be made as public subclasses of CleanerImpl.XXXXCleanable classes and those subclasses could make the method final. I see no other issues left besides the reachability races that I talked about in previous messages. Do you know if Reference.reachabilityFence is being pushed before this API? Regards, Peter > > > > On 12/15/2015 6:01 PM, Peter Levart wrote: >> >> >> On 12/15/2015 11:48 PM, Roger Riggs wrote: >>> Hi Peter, >>> >>> That will break up clearing the ref when the Cleanable is explicitly >>> cleaned. >>> Reference.clear() needs to be called from Cleanable.clean(). >> >> From PhantomCleanable (the superclass of PhantomCleanableRef): >> >> 253 @Override >> 254 public final void clean() { >> 255 if (remove()) { >> 256 super.clear(); >> 257 performCleanup(); >> 258 } >> 259 } >> 260 >> 261 /** >> 262 * Unregister this PhantomCleanable and clear the reference. >> 263 * Due to inherent concurrency, {@link >> #performCleanup()} may still be invoked. >> 264 */ >> 265 @Override >> 266 public final void clear() { >> 267 if (remove()) { >> 268 super.clear(); >> 269 } >> 270 } >> >> >> ... clean() calls super.clear(), which is "invokespecial" (not a >> virtual dispatch). >> >> >> Regards, Peter >> >>> >>> it might be nice to block that but to do so we'd need to go back to >>> separate objects >>> for the Reference and the Cleanable and we worked hard to get to a >>> single object. >>> >>> Roger >>> >>> >>> On 12/15/2015 5:38 PM, Peter Levart wrote: >>>> Hi Roger, >>>> >>>> Just one thing about implementation: >>>> >>>> Since the type exposed to user is Cleaner.Cleanable that has only a >>>> single method clean(), it would be good if the implementation class >>>> (CleanerImpl.PhantomCleanableRef) overrode >>>> CleanerImpl.PhantomCleanable.clear() method and threw >>>> UnsupportedOperationException, otherwise users will be tempted to >>>> cast the returned Cleaner.Cleanable to Reference and invoke clear() >>>> method to de-register cleanup action without invoking it. This is >>>> the only remaining public Reference method that is not disabled >>>> this way. >>>> >>>> Regards, Peter >>>> >>>> On 12/09/2015 07:40 PM, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> The example is revised to caution about inner classes and lambdas. >>>>> >>>>> [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>>>> [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.html >>>>> >>>>> Thanks, Roger >>>>> >>>>> On 12/9/2015 11:04 AM, Peter Levart wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 12/09/2015 04:03 PM, Chris Hegarty wrote: >>>>>>> Peter, >>>>>>> >>>>>>> On 09/12/15 07:05, Peter Levart wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I think the only way to try to prevent such things is with a good >>>>>>>> example in javadoc that "screams" of possible miss-usages. >>>>>>>> >>>>>>>> >>>>>>>> public static class CleanerExample implements AutoCloseable { >>>>>>>> >>>>>>>> private static final Cleaner cleaner = ...; // >>>>>>>> preferably a >>>>>>>> shared cleaner >>>>>>>> >>>>>>>> private final PrivateNativeResource pnr; >>>>>>>> >>>>>>>> private final Cleaner.Cleanable cleanable; >>>>>>>> >>>>>>>> public CleanerExample(args, ...) { >>>>>>>> >>>>>>>> // prepare captured state as local vars... >>>>>>>> PrivateNativeResource _pnr = ...; >>>>>>>> >>>>>>>> this.cleanable = cleaner.register(this, () -> { >>>>>>>> // DON'T capture any instance fields with >>>>>>>> lambda since >>>>>>>> that would >>>>>>>> // capture 'this' and prevent it from becoming >>>>>>> >>>>>>> I assume that the WARNING should include anonymous inner classes >>>>>>> too >>>>>>> ( which I expect are quite common, though less now with lambda ) ? >>>>>>> >>>>>>> Is "leaking" 'this' in a constructor a potential issue with respect >>>>>>> to the visibility of pnr? As well as causing red-squiggly lines in >>>>>>> the IDE ;-) >>>>>> >>>>>> 'this' only leaks to the 'referent' field of PhantomReference >>>>>> where by definition is not accessible. >>>>>> >>>>>> 'this' can become phantom-reachable before CleanerExample >>>>>> constructor ends. But this is harmless, because the code that may >>>>>> execute at that time does not access the object any more, so the >>>>>> object may be safely collected. >>>>>> >>>>>> Cleanup action can run at any time after registration even before >>>>>> CleanerExample constructor ends. But this is harmless too, >>>>>> because it only accesses PrivateNativeResource which is fully >>>>>> constructed before registration of cleanup action. >>>>>> >>>>>> I see no issues apart from IDE(s) not seeing no issues. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> >>>>>>>> phantom-reachable!!! >>>>>>>> _pnr.close(); >>>>>>>> }); >>>>>>>> >>>>>>>> this.pnr = _pnr; >>>>>>>> } >>>>>>>> >>>>>>>> public void close() { >>>>>>>> cleanable.clean(); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Thu Dec 17 12:19:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Dec 2015 13:19:22 +0100 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5671EB56.4070805@oracle.com> References: <5671EB56.4070805@oracle.com> Message-ID: <5672A84A.9010206@gmail.com> Hi Aleksey, Wouldn't that change make a possible outcome of keySet() returning null in case it was invoked concurrently? Wouldn't you have to use a local variable to prevent that? Regards, Peter On 12/16/2015 11:53 PM, Aleksey Shipilev wrote: > Hi, > > Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as > package-private volatile fields. Their only use is to cache keySet and > valueSet implementations from java.util collections. > > However, all relevant java.util collections are not having any declared > fields (an opaque reference to enclosing class is stored in final > field), and they delegate straight to the backing collection. Therefore, > any race on cache field is benign, and we can drop "volatile" from the > fields: > https://bugs.openjdk.java.net/browse/JDK-8145539 > http://cr.openjdk.java.net/~shade/8145539/webrev.02/ > > This improves performance for keySet()/values() on AbstractMap > implementations, because we don't emit barriers (volatile write in x86 > case). This does not affect AbstractMap subclasses allocation > performance, because the volatile field values were default since > JDK-8035284. > > See: > http://cr.openjdk.java.net/~shade/8145539/HashMapBench.java > > Testing: microbenchmarks, java/util jtreg on Linux x86_64 > > Thanks, > -Aleksey > From paul.sandoz at oracle.com Thu Dec 17 12:53:48 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Dec 2015 13:53:48 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5672A58A.3010307@gmail.com> References: <560D3F61.6040607@Oracle.com> <20151123143205.51363@eggemoggin.niobe.net> <565F5355.6040209@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.2020605@Oracle.com> <5672A58A.30! 10307@gmail.com> Message-ID: <57F2014D-0CB9-4397-891F-B1D16FCEF29C@oracle.com> > On 17 Dec 2015, at 13:07, Peter Levart wrote: > > I see no other issues left besides the reachability races that I talked about in previous messages. Do you know if Reference.reachabilityFence is being pushed before this API? > It?s already pushed to hs-comp. I dunno when it will wind it?s way down into jdk9/dev (nor vice versa if java.lang.ref.Cleaner is pushed to dev). Paul. From kumar.x.srinivasan at oracle.com Thu Dec 17 13:32:30 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 17 Dec 2015 05:32:30 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: References: <567037AA.30801@oracle.com> <20151215231250.00004401.ecki@zusammenkunft.net> Message-ID: <5672B96E.7090105@oracle.com> On 12/16/2015 11:01 AM, Martin Buchholz wrote: > On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: >> Hello, >> >> I always like it when access() is used instead of stat() magic. >> >> I noticed that the new ProgramExists in java_md_common.c does not >> anymore reject directories (which are typically executable). Not sure >> it this matters or is intentional, it is a change in semantic. > Right. This is a small loss of robustness. Changing stat into access > here isn't really right because not stat has a superset of > functionality, and (like I keep saying) all the stat calls in the JDK > are potentially broken and need fixing. I agree this is a very small corner case, the caller (there is one call and will always test for the existence of a file). So I am going to go with this, unless I hear objections. Kumar From magnus.ihse.bursie at oracle.com Thu Dec 17 13:43:40 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Dec 2015 14:43:40 +0100 Subject: RFR: JDK-8145596 Enable debug symbols for all libraries Message-ID: <5672BC0C.2070307@oracle.com> For historical reasons, the FDS (Full Debug Symbols) project only enabled debug symbols for a few select libraries, since this was difficult to achieve in the old build. Also, the FDS project never enabled debug symbols for macosx on the JDK libraries. With the new build system, debug symbols come for free for all libraries, and we actually have to do extra work to keep them out. :-& We should just stop doing that. It hurts no-one to have proper debug information for all libraries, it might come in helpful, and just doing it everywhere would simplify build logic. This is mainly a build change, but I'm cc:ing the component teams just in case. This patch leverages JDK-8036003, but provides a cleaner implementation of this logic in the makefiles. Instead of the vague ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables: COMPILE_WITH_DEBUG_SYMBOLS COPY_DEBUG_SYMBOLS ZIP_EXTERNAL_DEBUG_SYMBOLS The various settings of --with-native-debug-symbols turns these variables on/off depending on what we want to achieve, and the makefiles check these variables to determine what compiler flags to use, whether to run objcopy (or similar) and whether to zip the extracted symbols, respectively. A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement this, but the way we handle stripping is complex in it's own right, and I've saved that for a separate patch. Note that this patch intentionally does not affect the Hotspot build system. The variables for the hotspot build is kept unchanged. When the new build-infra based hotspot build system arrives, the functionality introduced in this patch will be automatically used. Until then, I prefer not to mess any more than necessary with the hotspot makefiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8145596 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01 /Magnus From yasuenag at gmail.com Thu Dec 17 13:45:58 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 17 Dec 2015 22:45:58 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> <5671796C.1030406@gmail.com> Message-ID: <5672BC96.3080301@gmail.com> Hi Jason, Thank you for your comment. I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/ Thanks, Yasumasa On 2015/12/17 0:33, Jason Mehrens wrote: > The null check of 'entry' at line 351 of ZipFile.getInputStream is in conflict with line 350 and 348. > > ________________________________________ > From: core-libs-dev on behalf of Yasumasa Suenaga > Sent: Wednesday, December 16, 2015 8:47 AM > To: Sergey Bylokhov; Xueming Shen > Cc: core-libs-dev at openjdk.java.net > Subject: Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries > > Hi Sergey, > > Thank you for your comment. > > I added that description in new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ > > > Thanks, > > Yasumasa > > > On 2015/12/16 22:19, Sergey Bylokhov wrote: >> Should the new methods describe how they will work in case of null params? >> >> On 16/12/15 16:04, Yasumasa Suenaga wrote: >>> I adapted this enhancement after JDK-8145260: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>>> Hi Sherman, >>>> >>>> Our proposal is affected by JDK-8142508. >>>> We have to change ZipFile.java and and ZipFile.c . >>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>>> repos. >>>> >>>> Do you have any comments about current webrev? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>> >>>> If you have comments, we will fix them in new webrev. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>>> Hi Sherman, >>>>> >>>>> Thanks for your quick response :) >>>>> >>>>> I aimed to implement the "traditional" at this proposal by the below >>>>> reasons. >>>>> >>>>> * We want to prepare API for encrypted zip files at first. >>>>> * Many people use the "traditional" in problem-free scope like a >>>>> temporary file. >>>>> * We do not know which implementation of the "stronger" is best for >>>>> openjdk. >>>>> * PKWare claims that they have patents about the "stronger" on >>>>> Zip[1]. >>>>> * OTOH, WinZip have the alternative implementation of the >>>>> "stronger" [2][3]. >>>>> * Instead, we prepared the extensibility by ZipCryption interface to >>>>> implement other encrypt engine, such as the AES based. >>>>> >>>>> Thus, I think this PoC should support the "traditional" only. >>>>> In the future, anyone who want to implement the "stronger" can easily >>>>> add their code by virtue of this proposal. >>>>> >>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>>> [2] >>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>>> >>>>> [3] http://www.winzip.com/aes_info.htm >>>>> >>>>> Thanks, >>>>> Yuji >>>>> >>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>>> >>>>>> Hi Yuji, >>>>>> >>>>>> I will take a look at your PoC. Might need some time and even bring >>>>>> in the >>>>>> security guy >>>>>> to evaluate the proposal. It seems like you are only interested in the >>>>>> "traditional PKWare >>>>>> decryption", which is, based on the wiki, "known to be seriously >>>>>> flawed, and >>>>>> in particular >>>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>>> "stronger" encryption >>>>>> mechanism, such as the AES based? >>>>>> >>>>>> Regards, >>>>>> Sherman >>>>>> >>>>>> >>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We need reviewer(s) for this PoC. >>>>>>> Could you please review this proposal and PoC ? >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>>>> >>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> * Sorry for my mistake. I re-post this mail because I sent before get >>>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>>> >>>>>>>> Our customers have to handle password-protected zip files. However, >>>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>>> third party library so far. >>>>>>>> >>>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>>> >>>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>>> The >>>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>>> implementation. >>>>>>>> >>>>>>>> We've created PoC and uploaded it as webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>>> >>>>>>>> Test code is as below. This code will let you know how this PoC >>>>>>>> works. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>>> >>>>>>>> In NTT, a Japanese telecommunications company. We are providing many >>>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>>> implement to >>>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>>> desired for many developers and users. >>>>>>>> >>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>>> (ysuenaga). >>>>>>>> We want to implement it if this proposal accepted. >>>>>>>> >>>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yuji >>>>>> >>>>>> >> >> From aleksey.shipilev at oracle.com Thu Dec 17 13:46:06 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 16:46:06 +0300 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5672A84A.9010206@gmail.com> References: <5671EB56.4070805@oracle.com> <5672A84A.9010206@gmail.com> Message-ID: <5672BC9E.4010502@oracle.com> Hi Peter, On 12/17/2015 03:19 PM, Peter Levart wrote: > Wouldn't that change make a possible outcome of keySet() returning null > in case it was invoked concurrently? Wouldn't you have to use a local > variable to prevent that? Ah yes! Silly me. I remember looking at most usages and seeing that reads are performed only once, but missed that it should be applied consistently, including the AbstractMap itself. Fixed that, plus exploded inline assignments in subclasses : http://cr.openjdk.java.net/~shade/8145539/webrev.03/ Thanks, -Aleksey From Ulf.Zibis at CoSoCo.de Thu Dec 17 13:54:42 2015 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 17 Dec 2015 14:54:42 +0100 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <56726A3D.7020202@oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> Message-ID: <5672BEA2.8090708@CoSoCo.de> Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: > On 12/17/2015 02:34 AM, Ulf wrote: >> I'm wondering why moving the increment operation to an extra line wound >> enhance performance. > Because C1 is very straightforward, and code movement like that is a > poor man's instruction scheduling, that pads out the data dependency > between index update and indexed access. Thanks. Shouldn't this simple optimization be addressed to javac? Otherwise programmers always risk some performance when using the post-increment idiom, which IMHO is good code style. -Ulf From daniel.fuchs at oracle.com Thu Dec 17 14:02:42 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Dec 2015 15:02:42 +0100 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows In-Reply-To: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> References: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> Message-ID: <5672C082.2020009@oracle.com> Hi Mandy, I believe it would be good to have some test that go over the 1024 limit - as this has been useful to detect bugs when we were actively prototyping the API. So maybe we should first try to reduce from 2000 to e.g. 1028? best regards, -- daniel On 16/12/15 21:30, Mandy Chung wrote: > This is a test fix to reduce the stack depth to avoid StackOverFlow when running with -Xcomp on solaris sparc. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8144553/webrev.00/index.html > > I verified the tests on solaris-sparcv9 machine with fastdebug VM -Xcomp -ea -esa. > > Mandy > From chris.hegarty at oracle.com Thu Dec 17 14:46:11 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Dec 2015 14:46:11 +0000 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 Message-ID: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> The removal of BASE64Encoder, and a related types, in 8144479 [1] has triggered the failure of java/beans/Introspector/Test6277246.java. Another internal type should be used instead of sun.misc.BASE64Encoder. The sun.security.x509 package seems stable, and is being used in other areas, like langtools and jigsaw/jake to test accessibility. diff --git a/test/java/beans/Introspector/Test6277246.java b/test/java/beans/Introspector/Test6277246.java --- a/test/java/beans/Introspector/Test6277246.java +++ b/test/java/beans/Introspector/Test6277246.java @@ -25,7 +25,7 @@ * @test * @bug 6277246 * @summary Tests problem with java.beans use of reflection - * @modules java.base/sun.misc + * @modules java.base/sun.security.x509 * java.desktop * @run main/othervm Test6277246 * @author Jeff Nisewanger @@ -36,11 +36,10 @@ import java.beans.Introspector; import java.beans.MethodDescriptor; import java.lang.reflect.Method; -import sun.misc.BASE64Encoder; public class Test6277246 { public static void main(String[] args) throws IntrospectionException { - Class type = BASE64Encoder.class; + Class type = sun.security.x509.X509CertInfo.class; System.setSecurityManager(new SecurityManager()); BeanInfo info = Introspector.getBeanInfo(type); for (MethodDescriptor md : info.getMethodDescriptors()) { @@ -48,7 +47,7 @@ System.out.println(method); String name = method.getDeclaringClass().getName(); - if (name.startsWith("sun.misc.")) { + if (name.startsWith("sun.")) { throw new Error("found inaccessible method"); } } diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -126,9 +126,6 @@ java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all -# 8145589 -java/beans/Introspector/Test6277246.java generic-all - ############################################################################ # jdk_lang -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8144479 From Roger.Riggs at Oracle.com Thu Dec 17 14:52:37 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Dec 2015 09:52:37 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <57F2014D-0CB9-4397-891F-B1D16FCEF29C@oracle.com> References: <560D3F61.6040607@Oracle.com> <8E99FB8A-E71A-4356-9E8E-A1D235F67F7D@oracle.com> <5660B1F9.6090305@oracle.com> <5661C5A5.9020904@Oracle.com> <87718163-FCE6-48F3-9A90-10E94CC8779B@oracle.com> <56631E50.2090107@oracle.com> <5664D6DD.9010709@oracle.com> <5665D50E.3030606@oracle.com> <56669053.1080404@oracle.com> <56669348.7020603@oracle.com> <5666CC4B.9020303@gmail.com> <5666F89B.7050001@oracle.com> <566726AA.7070005@gmail.com> <3E86BBB0-85AA-4748-B082-298402E7DFF2@gmail.com> <56674A80.6070906@gmail.com> <566754C4.4060308@Oracle.com> <5667D2BC.2030505@gmail.com> <566842D2.1080200@oracle.com> <56685123.5030402@gmail.com> <5668759A.1070204@Oracle.com> <5670967B.4050209@gmail.com> <567098BB.4050001@Oracle.com> <56709BB8.3070809@gmail.com> <5671BFB9.2020605@Oracle.com> <5672A58A.30! 10307@gmail.com> <57F2014D-0CB9-4397-891F-B1D16FCEF29C@oracle.com> Message-ID: <5672CC35.2000805@Oracle.com> fyi, I filed a separate bug[1] to add the reachabilityFence calls when they reach jdk-dev. Roger [1] https://bugs.openjdk.java.net/browse/JDK-8145459 On 12/17/2015 7:53 AM, Paul Sandoz wrote: >> On 17 Dec 2015, at 13:07, Peter Levart wrote: >> >> I see no other issues left besides the reachability races that I talked about in previous messages. Do you know if Reference.reachabilityFence is being pushed before this API? >> > It?s already pushed to hs-comp. I dunno when it will wind it?s way down into jdk9/dev (nor vice versa if java.lang.ref.Cleaner is pushed to dev). > > Paul. From erik.joelsson at oracle.com Thu Dec 17 14:54:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Dec 2015 15:54:06 +0100 Subject: RFR: JDK-8145596 Enable debug symbols for all libraries In-Reply-To: <5672BC0C.2070307@oracle.com> References: <5672BC0C.2070307@oracle.com> Message-ID: <5672CC8E.5030004@oracle.com> Looks good to me. Note that this patch will conflict with the quick fix I did in jdk9/hs, so you will need to either wait for my patch, push in a forest that has my patch, or make sure the integrator can handle it correctly. /Erik On 2015-12-17 14:43, Magnus Ihse Bursie wrote: > For historical reasons, the FDS (Full Debug Symbols) project only > enabled debug symbols for a few select libraries, since this was > difficult to achieve in the old build. Also, the FDS project never > enabled debug symbols for macosx on the JDK libraries. > > With the new build system, debug symbols come for free for all > libraries, and we actually have to do extra work to keep them out. :-& > > We should just stop doing that. It hurts no-one to have proper debug > information for all libraries, it might come in helpful, and just > doing it everywhere would simplify build logic. > > This is mainly a build change, but I'm cc:ing the component teams just > in case. > > This patch leverages JDK-8036003, but provides a cleaner > implementation of this logic in the makefiles. Instead of the vague > ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables: > > COMPILE_WITH_DEBUG_SYMBOLS > COPY_DEBUG_SYMBOLS > ZIP_EXTERNAL_DEBUG_SYMBOLS > > The various settings of --with-native-debug-symbols turns these > variables on/off depending on what we want to achieve, and the > makefiles check these variables to determine what compiler flags to > use, whether to run objcopy (or similar) and whether to zip the > extracted symbols, respectively. > > A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement > this, but the way we handle stripping is complex in it's own right, > and I've saved that for a separate patch. > > Note that this patch intentionally does not affect the Hotspot build > system. The variables for the hotspot build is kept unchanged. When > the new build-infra based hotspot build system arrives, the > functionality introduced in this patch will be automatically used. > Until then, I prefer not to mess any more than necessary with the > hotspot makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145596 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01 > > /Magnus From Roger.Riggs at Oracle.com Thu Dec 17 14:54:12 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Dec 2015 09:54:12 -0500 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 In-Reply-To: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> References: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> Message-ID: <5672CC94.7050508@Oracle.com> Hi Chris, Looks fine. Roger On 12/17/2015 9:46 AM, Chris Hegarty wrote: > The removal of BASE64Encoder, and a related types, in 8144479 [1] > has triggered the failure of java/beans/Introspector/Test6277246.java. > Another internal type should be used instead of sun.misc.BASE64Encoder. > The sun.security.x509 package seems stable, and is being used in other > areas, like langtools and jigsaw/jake to test accessibility. > > > diff --git a/test/java/beans/Introspector/Test6277246.java b/test/java/beans/Introspector/Test6277246.java > --- a/test/java/beans/Introspector/Test6277246.java > +++ b/test/java/beans/Introspector/Test6277246.java > @@ -25,7 +25,7 @@ > * @test > * @bug 6277246 > * @summary Tests problem with java.beans use of reflection > - * @modules java.base/sun.misc > + * @modules java.base/sun.security.x509 > * java.desktop > * @run main/othervm Test6277246 > * @author Jeff Nisewanger > @@ -36,11 +36,10 @@ > import java.beans.Introspector; > import java.beans.MethodDescriptor; > import java.lang.reflect.Method; > -import sun.misc.BASE64Encoder; > > public class Test6277246 { > public static void main(String[] args) throws IntrospectionException { > - Class type = BASE64Encoder.class; > + Class type = sun.security.x509.X509CertInfo.class; > System.setSecurityManager(new SecurityManager()); > BeanInfo info = Introspector.getBeanInfo(type); > for (MethodDescriptor md : info.getMethodDescriptors()) { > @@ -48,7 +47,7 @@ > System.out.println(method); > > String name = method.getDeclaringClass().getName(); > - if (name.startsWith("sun.misc.")) { > + if (name.startsWith("sun.")) { > throw new Error("found inaccessible method"); > } > } > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -126,9 +126,6 @@ > java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all > java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all > > -# 8145589 > -java/beans/Introspector/Test6277246.java generic-all > - > ############################################################################ > > # jdk_lang > > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8144479 From Roger.Riggs at Oracle.com Thu Dec 17 14:55:31 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Dec 2015 09:55:31 -0500 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <56726A3D.7020202@oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> Message-ID: <5672CCE3.2050403@Oracle.com> Hi Alexsey, The 'expected to run benchmarks' might the operative comment in the code. 'Common' knowledge sometimes isn't so common. Roger On 12/17/2015 2:54 AM, Aleksey Shipilev wrote: > On 12/17/2015 02:34 AM, Ulf wrote: >> I'm wondering why moving the increment operation to an extra line wound >> enhance performance. > Because C1 is very straightforward, and code movement like that is a > poor man's instruction scheduling, that pads out the data dependency > between index update and indexed access. I don't think it deserves a > comment -- it is expected one will run the benchmarks when changing that > code. > > Thanks, > -Aleksey > From dl at cs.oswego.edu Thu Dec 17 15:07:53 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 17 Dec 2015 10:07:53 -0500 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5671EB56.4070805@oracle.com> References: <5671EB56.4070805@oracle.com> Message-ID: <5672CFC9.5030307@cs.oswego.edu> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: > Hi, > > Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as > package-private volatile fields. Their only use is to cache keySet and > valueSet implementations from java.util collections. I think these were declared volatile to be more clearly JMM compliant. They are definitely OK without it, but you should probably add some rationale in documentation, mentioning that all java.util.Map view class implementations using these fields have no non-final fields (or any fields at all except for outer-this). -Doug From chris.hegarty at oracle.com Thu Dec 17 15:08:53 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Dec 2015 15:08:53 +0000 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 In-Reply-To: <5672CC94.7050508@Oracle.com> References: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> <5672CC94.7050508@Oracle.com> Message-ID: On 17 Dec 2015, at 14:54, Roger Riggs wrote: > Hi Chris, > > Looks fine. Thanks Roger. Just a little addition to this review. While not strictly necessary, I?d like to clean up another, string, reference use in a reflective call. ( It is not causing a failure as the security manager will restrict access to sun.*, but it may avoid confusion in the future. diff --git a/test/java/beans/EventHandler/Test6277246.java b/test/java/beans/EventHandler/Test6277246.java --- a/test/java/beans/EventHandler/Test6277246.java +++ b/test/java/beans/EventHandler/Test6277246.java @@ -39,7 +39,7 @@ Class container = Class.forName("java.lang.Class"); Class parameter = Class.forName("java.lang.String"); Method method = container.getMethod("forName", parameter); - Object[] arglist = new Object[] {"sun.misc.BASE64Encoder"}; + Object[] arglist = new Object[] {"sun.security.x509.X509CertInfo"}; EventHandler eh = new EventHandler(Test6277246.class, "forName", "", "forName"); Object object = eh.invoke(null, method, arglist); throw new Error((object != null) ? "test failure" : "test error?); -Chris. > Roger > > > On 12/17/2015 9:46 AM, Chris Hegarty wrote: >> The removal of BASE64Encoder, and a related types, in 8144479 [1] >> has triggered the failure of java/beans/Introspector/Test6277246.java. >> Another internal type should be used instead of sun.misc.BASE64Encoder. >> The sun.security.x509 package seems stable, and is being used in other >> areas, like langtools and jigsaw/jake to test accessibility. >> >> >> diff --git a/test/java/beans/Introspector/Test6277246.java b/test/java/beans/Introspector/Test6277246.java >> --- a/test/java/beans/Introspector/Test6277246.java >> +++ b/test/java/beans/Introspector/Test6277246.java >> @@ -25,7 +25,7 @@ >> * @test >> * @bug 6277246 >> * @summary Tests problem with java.beans use of reflection >> - * @modules java.base/sun.misc >> + * @modules java.base/sun.security.x509 >> * java.desktop >> * @run main/othervm Test6277246 >> * @author Jeff Nisewanger >> @@ -36,11 +36,10 @@ >> import java.beans.Introspector; >> import java.beans.MethodDescriptor; >> import java.lang.reflect.Method; >> -import sun.misc.BASE64Encoder; >> public class Test6277246 { >> public static void main(String[] args) throws IntrospectionException { >> - Class type = BASE64Encoder.class; >> + Class type = sun.security.x509.X509CertInfo.class; >> System.setSecurityManager(new SecurityManager()); >> BeanInfo info = Introspector.getBeanInfo(type); >> for (MethodDescriptor md : info.getMethodDescriptors()) { >> @@ -48,7 +47,7 @@ >> System.out.println(method); >> String name = method.getDeclaringClass().getName(); >> - if (name.startsWith("sun.misc.")) { >> + if (name.startsWith("sun.")) { >> throw new Error("found inaccessible method"); >> } >> } >> >> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >> --- a/test/ProblemList.txt >> +++ b/test/ProblemList.txt >> @@ -126,9 +126,6 @@ >> java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all >> java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all >> -# 8145589 >> -java/beans/Introspector/Test6277246.java generic-all >> - >> ############################################################################ >> # jdk_lang >> >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8144479 > From chris.hegarty at oracle.com Thu Dec 17 15:15:25 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Dec 2015 15:15:25 +0000 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 In-Reply-To: References: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> <5672CC94.7050508@Oracle.com> Message-ID: <2FF02E24-99BC-424F-9704-801D7E0DE3C0@oracle.com> For ease of review, I moved the complete changes into a webrev. http://cr.openjdk.java.net/~chegar/8145589/webrev/ -Chris. On 17 Dec 2015, at 15:08, Chris Hegarty wrote: > On 17 Dec 2015, at 14:54, Roger Riggs wrote: > >> Hi Chris, >> >> Looks fine. > > Thanks Roger. Just a little addition to this review. > > While not strictly necessary, I?d like to clean up another, string, > reference use in a reflective call. ( It is not causing a failure as > the security manager will restrict access to sun.*, but it may > avoid confusion in the future. > > diff --git a/test/java/beans/EventHandler/Test6277246.java b/test/java/beans/EventHandler/Test6277246.java > --- a/test/java/beans/EventHandler/Test6277246.java > +++ b/test/java/beans/EventHandler/Test6277246.java > @@ -39,7 +39,7 @@ > Class container = Class.forName("java.lang.Class"); > Class parameter = Class.forName("java.lang.String"); > Method method = container.getMethod("forName", parameter); > - Object[] arglist = new Object[] {"sun.misc.BASE64Encoder"}; > + Object[] arglist = new Object[] {"sun.security.x509.X509CertInfo"}; > EventHandler eh = new EventHandler(Test6277246.class, "forName", "", "forName"); > Object object = eh.invoke(null, method, arglist); > throw new Error((object != null) ? "test failure" : "test error?); > > -Chris. > >> Roger >> >> >> On 12/17/2015 9:46 AM, Chris Hegarty wrote: >>> The removal of BASE64Encoder, and a related types, in 8144479 [1] >>> has triggered the failure of java/beans/Introspector/Test6277246.java. >>> Another internal type should be used instead of sun.misc.BASE64Encoder. >>> The sun.security.x509 package seems stable, and is being used in other >>> areas, like langtools and jigsaw/jake to test accessibility. >>> >>> >>> diff --git a/test/java/beans/Introspector/Test6277246.java b/test/java/beans/Introspector/Test6277246.java >>> --- a/test/java/beans/Introspector/Test6277246.java >>> +++ b/test/java/beans/Introspector/Test6277246.java >>> @@ -25,7 +25,7 @@ >>> * @test >>> * @bug 6277246 >>> * @summary Tests problem with java.beans use of reflection >>> - * @modules java.base/sun.misc >>> + * @modules java.base/sun.security.x509 >>> * java.desktop >>> * @run main/othervm Test6277246 >>> * @author Jeff Nisewanger >>> @@ -36,11 +36,10 @@ >>> import java.beans.Introspector; >>> import java.beans.MethodDescriptor; >>> import java.lang.reflect.Method; >>> -import sun.misc.BASE64Encoder; >>> public class Test6277246 { >>> public static void main(String[] args) throws IntrospectionException { >>> - Class type = BASE64Encoder.class; >>> + Class type = sun.security.x509.X509CertInfo.class; >>> System.setSecurityManager(new SecurityManager()); >>> BeanInfo info = Introspector.getBeanInfo(type); >>> for (MethodDescriptor md : info.getMethodDescriptors()) { >>> @@ -48,7 +47,7 @@ >>> System.out.println(method); >>> String name = method.getDeclaringClass().getName(); >>> - if (name.startsWith("sun.misc.")) { >>> + if (name.startsWith("sun.")) { >>> throw new Error("found inaccessible method"); >>> } >>> } >>> >>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>> --- a/test/ProblemList.txt >>> +++ b/test/ProblemList.txt >>> @@ -126,9 +126,6 @@ >>> java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all >>> java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all >>> -# 8145589 >>> -java/beans/Introspector/Test6277246.java generic-all >>> - >>> ############################################################################ >>> # jdk_lang >>> >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8144479 >> > From mandy.chung at oracle.com Thu Dec 17 15:22:07 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 07:22:07 -0800 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows In-Reply-To: <5672C082.2020009@oracle.com> References: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> <5672C082.2020009@oracle.com> Message-ID: <8860B54C-C536-43B0-84C8-0D9A290A085A@oracle.com> > On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I believe it would be good to have some test that go over > the 1024 limit - as this has been useful to detect bugs > when we were actively prototyping the API. > > So maybe we should first try to reduce from 2000 to e.g. 1028? > Are you relating 1024 to the MaxJavaStackTraceDepth? That is the max depth of builtin backtrace. StackWalker no longer has the maxDepth. Mandy > best regards, > > -- daniel > > On 16/12/15 21:30, Mandy Chung wrote: >> This is a test fix to reduce the stack depth to avoid StackOverFlow when running with -Xcomp on solaris sparc. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8144553/webrev.00/index.html >> >> I verified the tests on solaris-sparcv9 machine with fastdebug VM -Xcomp -ea -esa. >> >> Mandy >> > From Roger.Riggs at Oracle.com Thu Dec 17 15:28:27 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Dec 2015 10:28:27 -0500 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 In-Reply-To: <2FF02E24-99BC-424F-9704-801D7E0DE3C0@oracle.com> References: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> <5672CC94.7050508@Oracle.com> <2FF02E24-99BC-424F-9704-801D7E0DE3C0@oracle.com> Message-ID: <5672D49B.5090900@Oracle.com> +1 On 12/17/2015 10:15 AM, Chris Hegarty wrote: > For ease of review, I moved the complete changes into a webrev. > > http://cr.openjdk.java.net/~chegar/8145589/webrev/ > > -Chris. > > On 17 Dec 2015, at 15:08, Chris Hegarty wrote: > >> On 17 Dec 2015, at 14:54, Roger Riggs wrote: >> >>> Hi Chris, >>> >>> Looks fine. >> Thanks Roger. Just a little addition to this review. >> >> While not strictly necessary, I?d like to clean up another, string, >> reference use in a reflective call. ( It is not causing a failure as >> the security manager will restrict access to sun.*, but it may >> avoid confusion in the future. >> >> diff --git a/test/java/beans/EventHandler/Test6277246.java b/test/java/beans/EventHandler/Test6277246.java >> --- a/test/java/beans/EventHandler/Test6277246.java >> +++ b/test/java/beans/EventHandler/Test6277246.java >> @@ -39,7 +39,7 @@ >> Class container = Class.forName("java.lang.Class"); >> Class parameter = Class.forName("java.lang.String"); >> Method method = container.getMethod("forName", parameter); >> - Object[] arglist = new Object[] {"sun.misc.BASE64Encoder"}; >> + Object[] arglist = new Object[] {"sun.security.x509.X509CertInfo"}; >> EventHandler eh = new EventHandler(Test6277246.class, "forName", "", "forName"); >> Object object = eh.invoke(null, method, arglist); >> throw new Error((object != null) ? "test failure" : "test error?); >> >> -Chris. >> >>> Roger >>> >>> >>> On 12/17/2015 9:46 AM, Chris Hegarty wrote: >>>> The removal of BASE64Encoder, and a related types, in 8144479 [1] >>>> has triggered the failure of java/beans/Introspector/Test6277246.java. >>>> Another internal type should be used instead of sun.misc.BASE64Encoder. >>>> The sun.security.x509 package seems stable, and is being used in other >>>> areas, like langtools and jigsaw/jake to test accessibility. >>>> >>>> >>>> diff --git a/test/java/beans/Introspector/Test6277246.java b/test/java/beans/Introspector/Test6277246.java >>>> --- a/test/java/beans/Introspector/Test6277246.java >>>> +++ b/test/java/beans/Introspector/Test6277246.java >>>> @@ -25,7 +25,7 @@ >>>> * @test >>>> * @bug 6277246 >>>> * @summary Tests problem with java.beans use of reflection >>>> - * @modules java.base/sun.misc >>>> + * @modules java.base/sun.security.x509 >>>> * java.desktop >>>> * @run main/othervm Test6277246 >>>> * @author Jeff Nisewanger >>>> @@ -36,11 +36,10 @@ >>>> import java.beans.Introspector; >>>> import java.beans.MethodDescriptor; >>>> import java.lang.reflect.Method; >>>> -import sun.misc.BASE64Encoder; >>>> public class Test6277246 { >>>> public static void main(String[] args) throws IntrospectionException { >>>> - Class type = BASE64Encoder.class; >>>> + Class type = sun.security.x509.X509CertInfo.class; >>>> System.setSecurityManager(new SecurityManager()); >>>> BeanInfo info = Introspector.getBeanInfo(type); >>>> for (MethodDescriptor md : info.getMethodDescriptors()) { >>>> @@ -48,7 +47,7 @@ >>>> System.out.println(method); >>>> String name = method.getDeclaringClass().getName(); >>>> - if (name.startsWith("sun.misc.")) { >>>> + if (name.startsWith("sun.")) { >>>> throw new Error("found inaccessible method"); >>>> } >>>> } >>>> >>>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>>> --- a/test/ProblemList.txt >>>> +++ b/test/ProblemList.txt >>>> @@ -126,9 +126,6 @@ >>>> java/beans/Introspector/8132566/OverridePropertyInfoTest.java generic-all >>>> java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all >>>> -# 8145589 >>>> -java/beans/Introspector/Test6277246.java generic-all >>>> - >>>> ############################################################################ >>>> # jdk_lang >>>> >>>> >>>> -Chris. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8144479 From daniel.fuchs at oracle.com Thu Dec 17 15:39:08 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Dec 2015 16:39:08 +0100 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows In-Reply-To: <8860B54C-C536-43B0-84C8-0D9A290A085A@oracle.com> References: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> <5672C082.2020009@oracle.com> <8860B54C-C536-43B0-84C8-0D9A290A085A@oracle.com> Message-ID: <5672D71C.1040900@oracle.com> On 17/12/15 16:22, Mandy Chung wrote: >> On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: >> > >> >Hi Mandy, >> > >> >I believe it would be good to have some test that go over >> >the 1024 limit - as this has been useful to detect bugs >> >when we were actively prototyping the API. >> > >> >So maybe we should first try to reduce from 2000 to e.g. 1028? >> > > Are you relating 1024 to the MaxJavaStackTraceDepth? That is the max depth of builtin backtrace. StackWalker no longer has the maxDepth. Yes. Is this truly gone? I thought it was still lurking :-) StackStreamFactory.java 918: private static final int MAX_STACK_FRAMES = 1024; best regards, -- daniel From aleksey.shipilev at oracle.com Thu Dec 17 15:54:05 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 18:54:05 +0300 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5672CFC9.5030307@cs.oswego.edu> References: <5671EB56.4070805@oracle.com> <5672CFC9.5030307@cs.oswego.edu> Message-ID: <5672DA9D.3020804@oracle.com> On 12/17/2015 06:07 PM, Doug Lea wrote: > On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >> package-private volatile fields. Their only use is to cache keySet and >> valueSet implementations from java.util collections. > > I think these were declared volatile to be more clearly JMM compliant. > They are definitely OK without it, but you should probably add some > rationale in documentation, mentioning that all java.util.Map view class > implementations using these fields have no non-final fields (or any > fields at all except for outer-this). Good idea, did so: http://cr.openjdk.java.net/~shade/8145539/webrev.04/ (There is also an @implSpec on keySet() and values() that say no synchronization is performed) Thanks, -Aleksey From mandy.chung at oracle.com Thu Dec 17 16:07:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 08:07:58 -0800 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows In-Reply-To: <5672D71C.1040900@oracle.com> References: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> <5672C082.2020009@oracle.com> <8860B54C-C536-43B0-84C8-0D9A290A085A@oracle.com> <5672D71C.1040900@oracle.com> Message-ID: <960E4A4F-8AB5-48F0-8949-1D73B953ED36@oracle.com> > On Dec 17, 2015, at 7:39 AM, Daniel Fuchs wrote: > > On 17/12/15 16:22, Mandy Chung wrote: >>> On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: >>> > >>> >Hi Mandy, >>> > >>> >I believe it would be good to have some test that go over >>> >the 1024 limit - as this has been useful to detect bugs >>> >when we were actively prototyping the API. >>> > >>> >So maybe we should first try to reduce from 2000 to e.g. 1028? >>> > >> Are you relating 1024 to the MaxJavaStackTraceDepth? That is the max depth of builtin backtrace. StackWalker no longer has the maxDepth. > > Yes. Is this truly gone? I thought it was still lurking :-) > > StackStreamFactory.java > 918: private static final int MAX_STACK_FRAMES = 1024; > This is for StackTrace which is used to generate Thread::dumpStack and Thread::getStackTrace with a limit on the number of stack trace elements. Mandy From daniel.fuchs at oracle.com Thu Dec 17 16:10:57 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Dec 2015 17:10:57 +0100 Subject: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows In-Reply-To: <960E4A4F-8AB5-48F0-8949-1D73B953ED36@oracle.com> References: <95AF6171-5E9F-4534-A6C2-69DBA8FC68A3@oracle.com> <5672C082.2020009@oracle.com> <8860B54C-C536-43B0-84C8-0D9A290A085A@oracle.com> <5672D71C.1040900@oracle.com> <960E4A4F-8AB5-48F0-8949-1D73B953ED36@oracle.com> Message-ID: <5672DE91.2080800@oracle.com> On 17/12/15 17:07, Mandy Chung wrote: > >> On Dec 17, 2015, at 7:39 AM, Daniel Fuchs wrote: >> >> On 17/12/15 16:22, Mandy Chung wrote: >>>> On Dec 17, 2015, at 6:02 AM, Daniel Fuchs wrote: >>>>> >>>>> Hi Mandy, >>>>> >>>>> I believe it would be good to have some test that go over >>>>> the 1024 limit - as this has been useful to detect bugs >>>>> when we were actively prototyping the API. >>>>> >>>>> So maybe we should first try to reduce from 2000 to e.g. 1028? >>>>> >>> Are you relating 1024 to the MaxJavaStackTraceDepth? That is the max depth of builtin backtrace. StackWalker no longer has the maxDepth. >> >> Yes. Is this truly gone? I thought it was still lurking :-) >> >> StackStreamFactory.java >> 918: private static final int MAX_STACK_FRAMES = 1024; Oh - OK then. -- daniel >> > > > This is for StackTrace which is used to generate Thread::dumpStack and Thread::getStackTrace with a limit on the number of stack trace elements. > > Mandy > From aleksey.shipilev at oracle.com Thu Dec 17 16:37:57 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 19:37:57 +0300 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5672CCE3.2050403@Oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> <5672CCE3.2050403@Oracle.com> Message-ID: <5672E4E5.1050004@oracle.com> Hi Roger, Um, do you really want to spell out "thou shalt run thee benchmarks while changing the String hotpath" in source code comments? I disagree: documenting development processes in the source code is odd. But equally odd is the suggestion that a common development practice would *not* involve running benchmarks when changing the ubiquitous codepath in the standard library, *or* studying the prior history for the code under modification. Some knowledge really is common. Can we pretty please get this done, and move on to other interesting things? Thanks, -Aleksey On 12/17/2015 05:55 PM, Roger Riggs wrote: > Hi Alexsey, > > The 'expected to run benchmarks' might the operative comment in the code. > 'Common' knowledge sometimes isn't so common. > > Roger > > > On 12/17/2015 2:54 AM, Aleksey Shipilev wrote: >> On 12/17/2015 02:34 AM, Ulf wrote: >>> I'm wondering why moving the increment operation to an extra line wound >>> enhance performance. >> Because C1 is very straightforward, and code movement like that is a >> poor man's instruction scheduling, that pads out the data dependency >> between index update and indexed access. I don't think it deserves a >> comment -- it is expected one will run the benchmarks when changing that >> code. >> >> Thanks, >> -Aleksey >> > From daniel.fuchs at oracle.com Thu Dec 17 16:42:05 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Dec 2015 17:42:05 +0100 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger Message-ID: <5672E5DD.1080302@oracle.com> Hi, Please find below a small enhancement for the method that infers the calling class name and method name in SimpleConsoleLogger and LogRecord. The idea is that since these methods now use the new StackWalker API they should take advantage of that in order to skip classes that implement System.Logger. This should make it possible for components that need it to easily wrap a System.Logger (and even a j.u.l.Logger). 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger https://bugs.openjdk.java.net/browse/JDK-8145686 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.00/ best regards, -- daniel From aleksey.shipilev at oracle.com Thu Dec 17 16:47:01 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 19:47:01 +0300 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5672BEA2.8090708@CoSoCo.de> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> <5672BEA2.8090708@CoSoCo.de> Message-ID: <5672E705.6060105@oracle.com> On 12/17/2015 04:54 PM, Ulf Zibis wrote: > Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: >> On 12/17/2015 02:34 AM, Ulf wrote: >>> I'm wondering why moving the increment operation to an extra line wound >>> enhance performance. >> Because C1 is very straightforward, and code movement like that is a >> poor man's instruction scheduling, that pads out the data dependency >> between index update and indexed access. > > Thanks. > Shouldn't this simple optimization be addressed to javac? > Otherwise programmers always risk some performance when using the > post-increment idiom, which IMHO is good code style. No, it should not be addressed in javac, as good optimizing compiler would handle this without involving bytecode scheduling in the Java compiler. With C1, it is always the "low-cost" branch of cost-benefit game -- if you can spend a few hours polishing the code to make it perform better with C1, then you should do it. But, wasting man-years of effort to please C1 is not almost wise resource investment. This is why I am resistant to any sort of bikeshedding w.r.t. these particular changes -- we did them, they improved C1, let's move on. Thanks, -Aleksey From Roger.Riggs at Oracle.com Thu Dec 17 16:54:21 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 17 Dec 2015 11:54:21 -0500 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5672E4E5.1050004@oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> <5672CCE3.2050403@Oracle.com> <5672E4E5.1050004@oracle.com> Message-ID: <5672E8BD.7080107@Oracle.com> Hi Aleksey, I should have worded it as a suggestion (and provided the words) so as avoided impeding progress. It could have been as general as saying that an @implNote that String is uniquely performance sensitive, that would apply to the whole file, not just a few expressions, and it should probably have been there for 20 years. You are particularly sensitive to performance, not every developer is and they assume that the compiler does reasonable optimizations (it doesn't) and that what look like equivalent expressions should work the same. As the comments to your original change elicited, the change is tuning the source code for a particular optimization (or lack of) in C1. I agree that you should just push it and move on. Roger On 12/17/2015 11:37 AM, Aleksey Shipilev wrote: > Hi Roger, > > Um, do you really want to spell out "thou shalt run thee benchmarks > while changing the String hotpath" in source code comments? > > I disagree: documenting development processes in the source code is odd. > But equally odd is the suggestion that a common development practice > would *not* involve running benchmarks when changing the ubiquitous > codepath in the standard library, *or* studying the prior history for > the code under modification. Some knowledge really is common. > > Can we pretty please get this done, and move on to other interesting things? > > Thanks, > -Aleksey > > On 12/17/2015 05:55 PM, Roger Riggs wrote: >> Hi Alexsey, >> >> The 'expected to run benchmarks' might the operative comment in the code. >> 'Common' knowledge sometimes isn't so common. >> >> Roger >> >> >> On 12/17/2015 2:54 AM, Aleksey Shipilev wrote: >>> On 12/17/2015 02:34 AM, Ulf wrote: >>>> I'm wondering why moving the increment operation to an extra line wound >>>> enhance performance. >>> Because C1 is very straightforward, and code movement like that is a >>> poor man's instruction scheduling, that pads out the data dependency >>> between index update and indexed access. I don't think it deserves a >>> comment -- it is expected one will run the benchmarks when changing that >>> code. >>> >>> Thanks, >>> -Aleksey >>> > From martinrb at google.com Thu Dec 17 16:58:00 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Dec 2015 08:58:00 -0800 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56726EEB.6080203@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56716101.1080502@oracle.com> <56726EEB.6080203@oracle.com> Message-ID: Looks good! On Thu, Dec 17, 2015 at 12:14 AM, vyom wrote: > Hi Martin, > > thanks for review, i undated the > webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.2/ > ) as per your > comment after confirming that the corresponding "fd" if opened with > "open64". > > Thanks, > Vyom > > > > On Thursday 17 December 2015 12:38 AM, Martin Buchholz wrote: >> >> Calling naked fstat without _FILE_OFFSET_BITS=64 is a bug. Don't you >> need to call fstat64 if it's available? >> >> +jlong >> +handleGetLength(FD fd) >> +{ >> + struct stat sb; >> + if (fstat(fd, &sb) == 0) { >> + return sb.st_size; >> + } else { >> + return -1; >> + } >> +} >> >> On Wed, Dec 16, 2015 at 5:02 AM, vyom wrote: >>> >>> Hi, >>> >>> Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ >>> ) as per Martin >>> review comment removed the _FILE_OFFSET_BITS from source. >>> >>> Thanks, >>> Vyom >>> >>> >>> >>> On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: >>>> >>>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >>>> affects interoperability between translation units. It would be good >>>> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but >>>> that would be a big job. So traditionally the JDK has instead used >>>> the functions made available via _LARGEFILE64_SOURCE. But that is >>>> also a JDK-wide job now, because every call to plain stat in the >>>> source code is broken on 32-bit systems with 64-bit inodes, which are >>>> becoming more common. >>>> >>>> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job >>>> for build-dev, not core-libs-dev. >>>> >>>> >>>> >>>> >>>> On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs >>>> wrote: >>>>> >>>>> Hi Yvom, >>>>> >>>>> Minor comments: >>>>> >>>>> src/java.base/share/native/libjava/RandomAccessFile.c: >>>>> - "length fail" might be clearer as "GetLength failed" >>>>> >>>>> src/java.base/unix/native/libjava/io_util_md.c: >>>>> >>>>> - Please add a comment before the define of FILE_OFFSET_BITS to >>>>> indicate >>>>> where it is used and why it is there. >>>>> - BTW, are there any unintended side effects? >>>>> Perhaps a different issue but perhaps 64 bit offsets should be >>>>> used >>>>> everywhere >>>>> >>>>> src/java.base/windows/native/libjava/io_util_md.c >>>>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>>>> elsewhere in the file >>>>> BTW, Testing for invalid handle might be unnecessary since the >>>>> call >>>>> to >>>>> GetFileSizeEx will fail >>>>> if it is invalid, yielding the same result. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 12/10/2015 5:52 AM, vyom wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review my changes for below bug. >>>>>> >>>>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>>>> >>>>>> >>>>>> This change ensure that length() does not temporarily changes the >>>>>> file >>>>>> pointer and it will make sure that there is no race >>>>>> condition in case of multi thread uses. >>>>>> >>>>>> Thanks, >>>>>> Vyom >>>>>> >>>>>> >>>>>> >>>>>> > From paul.sandoz at oracle.com Thu Dec 17 17:18:40 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Dec 2015 18:18:40 +0100 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <5672E8BD.7080107@Oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> <5672CCE3.2050403@Oracle.com> <5672E4E5.1050004@oracle.com> <5672E8BD.7080107@Oracle.com> Message-ID: <3687B5A4-DAF2-4D7E-B575-6588C3ACC361@oracle.com> > On 17 Dec 2015, at 17:54, Roger Riggs wrote: > > I agree that you should just push it and move on. > +1 Paul. From paul.sandoz at oracle.com Thu Dec 17 17:21:39 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Dec 2015 18:21:39 +0100 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <5672DA9D.3020804@oracle.com> References: <5671EB56.4070805@oracle.com> <5672CFC9.5030307@cs.oswego.edu> <5672DA9D.3020804@oracle.com> Message-ID: <2F87A961-56B9-4EB8-B3DA-F2A4240A3238@oracle.com> > On 17 Dec 2015, at 16:54, Aleksey Shipilev wrote: > > On 12/17/2015 06:07 PM, Doug Lea wrote: >> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >>> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >>> package-private volatile fields. Their only use is to cache keySet and >>> valueSet implementations from java.util collections. >> >> I think these were declared volatile to be more clearly JMM compliant. >> They are definitely OK without it, but you should probably add some >> rationale in documentation, mentioning that all java.util.Map view class >> implementations using these fields have no non-final fields (or any >> fields at all except for outer-this). > > Good idea, did so: > http://cr.openjdk.java.net/~shade/8145539/webrev.04/ > > (There is also an @implSpec on keySet() and values() that say no > synchronization is performed) > +1 Paul. From aleksey.shipilev at oracle.com Thu Dec 17 17:47:25 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 17 Dec 2015 20:47:25 +0300 Subject: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1 In-Reply-To: <3687B5A4-DAF2-4D7E-B575-6588C3ACC361@oracle.com> References: <5671B773.3070500@oracle.com> <5671F4F0.4000505@CoSoCo.de> <56726A3D.7020202@oracle.com> <5672CCE3.2050403@Oracle.com> <5672E4E5.1050004@oracle.com> <5672E8BD.7080107@Oracle.com> <3687B5A4-DAF2-4D7E-B575-6588C3ACC361@oracle.com> Message-ID: <5672F52D.1060306@oracle.com> On 12/17/2015 08:18 PM, Paul Sandoz wrote: > >> On 17 Dec 2015, at 17:54, Roger Riggs wrote: >> >> I agree that you should just push it and move on. >> > > +1 Thanks Claes, Sherman, Roger, and Paul! Pushed. Cheers, -Aleksey From mandy.chung at oracle.com Thu Dec 17 18:02:33 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 10:02:33 -0800 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger In-Reply-To: <5672E5DD.1080302@oracle.com> References: <5672E5DD.1080302@oracle.com> Message-ID: <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> > On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a small enhancement for the method that infers > the calling class name and method name in SimpleConsoleLogger > and LogRecord. > > The idea is that since these methods now use the new StackWalker API > they should take advantage of that in order to skip classes that > implement System.Logger. This should make it possible for components > that need it to easily wrap a System.Logger (and even a j.u.l.Logger). > > 8145686: SimpleConsoleLogger and LogRecord should take advantage > of StackWalker to skip classes implementing System.Logger > https://bugs.openjdk.java.net/browse/JDK-8145686 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.00/ What is the difference between skipLoggingFrame and isLoggerImplFrame? Mandy From nadeesh.tv at oracle.com Thu Dec 17 18:13:54 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 17 Dec 2015 23:43:54 +0530 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> Message-ID: <5672FB62.9090608@oracle.com> Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ Thanks and Regards, Nadeesh On 12/4/2015 3:56 AM, Stephen Colebourne wrote: > In the interests of harmony and getting something in, I'll accept that. > > I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY > > Stephen > > > > On 3 December 2015 at 22:09, Roger Riggs wrote: >> Hi Sherman, >> >> It makes sense to me to provide the missing time/date as an explicit >> parameter >> for toEpochSeconds instead of assuming some constant. >> >> localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); >> localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); >> offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); >> >> We'll have to add the LocalDate.EPOCHDAY constant. >> >> It makes it a bit heavier weight to use but can still be optimized and won't >> create garbage. >> >> Roger >> >> >> >> On 12/01/2015 12:33 PM, Xueming Shen wrote: >>> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>>> As Roger says, these new methods are about performance as well as >>>> conversion. >>>> >>>> While I fully acknowledge the time methods make an assumption, it is >>>> not a crazy one, after all 1970-01-01 is just zero. >>>> >>>> Key I think is it allows: >>>> long epochSecs = date.toEpochSeconds(offset) + >>>> time.toEpochSeconds(offset); >>>> to efficiently merge two objects without garbage. >>> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >>> approach >>> >>> LocalDate date = ... >>> LocalDate time = ... >>> ZoneOffset offset = ... >>> >>> ==> long spochSecs = LocalDateTime.of(date, time).toEpochSeconds(offset); >>> >>> we are adding APIs to provide a "fastpath" with the special assumption >>> that the LocalDate "date" >>> here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) >>> and the LocalTime "time" >>> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to let >>> the third party "libraries" >>> to fool the basic date/time abstract in java.time package, simply to >>> avoid creating the garbage >>> middle man, localDateTime? it really does not sound right to me. >>> >>> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >>> epoch seconds in their >>> libraries, they really SHOULD think hard about the conversion and make it >>> right (it should not >>> be encouraged to use these classes LocalDate, LocalTime and Offset without >>> even understand >>> what these classes are). But if we really have to provide such fastpath, >>> personally I think it might >>> be better either to provide these "utility/convenient" methods in a >>> "utilities" class, or with an >>> explicit date/time parameters (instead of the false assumption) for the >>> missing date/time piece, >>> such as >>> >>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >>> >>> Sherman >>> >>> >>>> It also means that no-one has to think hard about the conversion, as >>>> it is just there. It tends to be when people try to work this stuff >>>> out for themselves that they get it wrong. >>>> >>>> Stephen >>>> >>>> >>>> On 1 December 2015 at 14:21, Roger Riggs wrote: >>>>> Hi Sherman, >>>>> >>>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>>> largest number of votes on SO: >>>>>>> >>>>>>> >>>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>>> The proposed method is designed to make the conversion easier. It also >>>>>>> plugs an obvious gap in the API. >>>>>>> >>>>>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>>>>> having them would result in inconsistency between the various classes. >>>>>>> We've already added factory methods to LocalTime for Java 9, these are >>>>>>> just the other half of the picture. >>>>>>> >>>>>> I'm not sure I understand the idea of "the proposed method is designed >>>>>> to >>>>>> make the conversion easier", as the SO is mainly about >>>>>> j.u.Date->LocalDate, >>>>>> not the other way around, from LocalDate -> j.u.Date. >>>>> I think the issue is about *other* libraries that manipulate time via >>>>> epochSeconds >>>>> not about j.u.Date conversions. The concern was about performance and >>>>> creating garbage along the way. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>>> As I said in the previous email, it might be "common" to use the >>>>>> j.u.Date >>>>>> to >>>>>> abstract a "local date" and/or a "local time" (no other choice) before >>>>>> java.time, >>>>>> and now there is the need to provide a migration path from those "local >>>>>> date/ >>>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>>> date/time >>>>>> type to the "old" j.u.Date should not be encouraged (guess this is also >>>>>> the >>>>>> consensus we agreed on back to jsr203). >>>>>> >>>>>> What are the "factory methods" you are referring to here? JDK-8133079, >>>>>> The >>>>>> LocalDate/LocalTime.ofInstant()? >>>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>>> >>>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>>> "super-set" >>>>>> of >>>>>> date/time to a "sub-set", without any assumption of "default value", it >>>>>> is >>>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>>> "small" >>>>>> improvement >>>>>> >>>>>> from| >>>>>> Date input = new Date(); >>>>>> LocalDatedate >>>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>>> >>>>>> to >>>>>> >>>>>> |LocalDatedate >>>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>>> >>>>>> The proposed pair toEpochSecond() however is doing the other way around >>>>>> and >>>>>> with an unusual assumption of the missing date/time piece to a "default >>>>>> value" >>>>>> (midnight, the epoch day). >>>>>> >>>>>> personally I think >>>>>> >>>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>>> >>>>>> is clean and good enough to help this backward conversion (with the >>>>>> addition >>>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>>>>> remove that LocalDateTime middle man, with some arrangement. >>>>>> >>>>>> -Sherman >>>>>> >>>>>>> Note that these methods are specifically not referencing >>>>>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>>>>> form here, and still widely used. >>>>>>> >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 30 November 2015 at 19:36, Xueming Shen >>>>>>> wrote: >>>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>>> These >>>>>>>>> methods aim to provide a simpler and faster approach, particularly >>>>>>>>> for >>>>>>>>> cases converting to/from java.util.Date. >>>>>>>> Can you be a little more specific on this one? We now have >>>>>>>> Instance<=> >>>>>>>> Date, >>>>>>>> and considerably we might add LocalDateTime<=> Date with an offset, >>>>>>>> if >>>>>>>> really >>>>>>>> really desired (for performance? to save a Instant object as the >>>>>>>> bridge?). >>>>>>>> But I'm >>>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>>> epoch >>>>>>>> seconds >>>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>>> >>>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>>> >>>>>>>> and uses the converted j.u.Date to represent a local date (date with >>>>>>>> time >>>>>>>> part to >>>>>>>> be 0) and/or the local time (with year/month/day to be epoch time) in >>>>>>>> the >>>>>>>> "old" >>>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>>> abstract >>>>>>>> the >>>>>>>> "local >>>>>>>> date" and "local time"? >>>>>>>> >>>>>>>> I think we agreed back to JSR310 that we don't try to add such kind >>>>>>>> of >>>>>>>> "bridge/ >>>>>>>> convenient/utility" methods into the new java.time package, but only >>>>>>>> in >>>>>>>> the >>>>>>>> old date/calendar classes, if really needed. So if these methods are >>>>>>>> only to >>>>>>>> help >>>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>>> java.time >>>>>>>> might not be the best place for them? >>>>>>>> >>>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>>> commonly used in many codebases. >>>>>>>>> >>>>>>>> I'm not sure about that, especially the "natural" part. It might be >>>>>>>> "common" >>>>>>>> in >>>>>>>> the old days if you only have j.u.Date", and might be forced to use >>>>>>>> 1970-01-01 >>>>>>>> to fill in the "date" part even when you are really only interested >>>>>>>> in >>>>>>>> "time" part >>>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is now >>>>>>>> we >>>>>>>> have >>>>>>>> separate abstract for these different need, I don't see the common >>>>>>>> need >>>>>>>> of >>>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>>> misunderstood >>>>>>>> something here. >>>>>>>> >>>>>>>> -Sherman >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Stephen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 30 November 2015 at 18:15, Xueming Shen >>>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> While it is kinda understandable to have >>>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of the >>>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>>> Local/OffsetTime >>>>>>>>>> to have two public methods with the assumption of the "date" is at >>>>>>>>>> epoch >>>>>>>>>> year/month/day. What's the use case/scenario for these two proposed >>>>>>>>>> methods? >>>>>>>>>> >>>>>>>>>> -Sherman >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>>> The method Javadoc (specs) for each of the three new methods needs >>>>>>>>>>> to >>>>>>>>>>> be enhanced. >>>>>>>>>>> >>>>>>>>>>> For the date ones it needs to say >>>>>>>>>>> "The resulting date will have a time component of midnight at the >>>>>>>>>>> start of the day." >>>>>>>>>>> >>>>>>>>>>> For the time ones it needs to say >>>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>>> >>>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>>> indented >>>>>>>>>>> correctly. >>>>>>>>>>> >>>>>>>>>>> Otherwise looks fine, >>>>>>>>>>> thanks >>>>>>>>>>> Stephen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for >>>>>>>>>>>> >>>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>>> >>>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>>> >>>>>>>>>>>> webrev -http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>>> Nadeesh TV >>>>>>>>> -- Thanks and Regards, Nadeesh TV From martinrb at google.com Thu Dec 17 18:26:14 2015 From: martinrb at google.com (Martin Buchholz) Date: Thu, 17 Dec 2015 10:26:14 -0800 Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem In-Reply-To: <5672B96E.7090105@oracle.com> References: <567037AA.30801@oracle.com> <20151215231250.00004401.ecki@zusammenkunft.net> <5672B96E.7090105@oracle.com> Message-ID: This is surely progress, but no one seems to own the problem of fixing all the stat calls in the JDK. Instead of failing at startup, we may get a more obscure failure later at runtime, which not everyone will think is progress. On Thu, Dec 17, 2015 at 5:32 AM, Kumar Srinivasan wrote: > > On 12/16/2015 11:01 AM, Martin Buchholz wrote: >> >> On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels >> wrote: >>> >>> Hello, >>> >>> I always like it when access() is used instead of stat() magic. >>> >>> I noticed that the new ProgramExists in java_md_common.c does not >>> anymore reject directories (which are typically executable). Not sure >>> it this matters or is intentional, it is a change in semantic. >> >> Right. This is a small loss of robustness. Changing stat into access >> here isn't really right because not stat has a superset of >> functionality, and (like I keep saying) all the stat calls in the JDK >> are potentially broken and need fixing. > > > I agree this is a very small corner case, the caller (there is one call and > will always > test for the existence of a file). So I am going to go with this, unless I > hear objections. > > Kumar > > From daniel.fuchs at oracle.com Thu Dec 17 19:23:55 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Dec 2015 20:23:55 +0100 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger In-Reply-To: <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> References: <5672E5DD.1080302@oracle.com> <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> Message-ID: <56730BCB.9020600@oracle.com> On 12/17/15 7:02 PM, Mandy Chung wrote: > >> On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a small enhancement for the method that infers >> the calling class name and method name in SimpleConsoleLogger >> and LogRecord. >> >> The idea is that since these methods now use the new StackWalker API >> they should take advantage of that in order to skip classes that >> implement System.Logger. This should make it possible for components >> that need it to easily wrap a System.Logger (and even a j.u.l.Logger). >> >> 8145686: SimpleConsoleLogger and LogRecord should take advantage >> of StackWalker to skip classes implementing System.Logger >> https://bugs.openjdk.java.net/browse/JDK-8145686 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.00/ > > What is the difference between skipLoggingFrame and isLoggerImplFrame? isLoggingImplFrame stops when it finds the concrete logger implementation. It will unstack all the LogRecord, Handler, Filter implementations etc... (which could be custom application classes) skipLoggingFrame will skip everything above the first method found on the concrete Logger implementation until it reaches something that looks like a calling frame. In particular it should skip other methods of the logger implementation (e.g. log() calls log(LogRecord), default interface methods provided by the logging framework, reflection/method handle frames etc... In particular it should skip any Logger wrapper classes. For instance, RMI has a logger that wraps a j.u.l.Logger so ideally that should be skipped too... JMX remote has a ClassLogger that should also be skipped. etc... -- daniel > > Mandy > From kim.barrett at oracle.com Thu Dec 17 21:30:55 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Dec 2015 16:30:55 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >> >>> [Indeed, this whole section isn't strictly necessary; all of it can be >>> inferred from information in other places.] >> >> Agree. This section is no longer necessary and maybe just remove it: > > I wasn't actually intending to suggest removal. It seems like there > is useful overview information to be had here, rather than requiring > readers to make not necessarily obvious inferences. My impression is > that readability is valued more highly than terseness in Java > documentation. Sorry for the long gap in the discussion. Mandy and I have been talking about what to do about the "Automatically-cleared references" section that was the topic of some debate. We've decided to eliminate it, which led us to some additional modifications. Here's the latest set of webrevs: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ They've been rebased to hs-rt tip, which required resolving a minor merge conflict with a nearby change to logging in referenceProcessor.cpp. Other than that, there are only specification wording changes. Here's the incremental change from the previous version: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ We are treating the discussions around changing PhantomReference to forbid a null queue as out of scope for this change. As Mandy said earlier, she might propose a separate change for that in the future. From aleksey.shipilev at oracle.com Thu Dec 17 22:45:57 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 18 Dec 2015 01:45:57 +0300 Subject: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile In-Reply-To: <2F87A961-56B9-4EB8-B3DA-F2A4240A3238@oracle.com> References: <5671EB56.4070805@oracle.com> <5672CFC9.5030307@cs.oswego.edu> <5672DA9D.3020804@oracle.com> <2F87A961-56B9-4EB8-B3DA-F2A4240A3238@oracle.com> Message-ID: <56733B25.5060101@oracle.com> On 12/17/2015 08:21 PM, Paul Sandoz wrote: >> On 17 Dec 2015, at 16:54, Aleksey Shipilev wrote: >> On 12/17/2015 06:07 PM, Doug Lea wrote: >>> On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: >>>> Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as >>>> package-private volatile fields. Their only use is to cache keySet and >>>> valueSet implementations from java.util collections. >>> >>> I think these were declared volatile to be more clearly JMM compliant. >>> They are definitely OK without it, but you should probably add some >>> rationale in documentation, mentioning that all java.util.Map view class >>> implementations using these fields have no non-final fields (or any >>> fields at all except for outer-this). >> >> Good idea, did so: >> http://cr.openjdk.java.net/~shade/8145539/webrev.04/ >> >> (There is also an @implSpec on keySet() and values() that say no >> synchronization is performed) >> > > +1 Thanks for reviews, Claes, Peter, Doug and Paul! With no other comments, I pushed the changeset. Thanks, -Aleksey From huizhe.wang at oracle.com Fri Dec 18 00:25:40 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 17 Dec 2015 16:25:40 -0800 Subject: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty Message-ID: <56735284.6060203@oracle.com> Hi, Adding a convenient method isEmpty to javax.xml.transform.Source and org.xml.sax.InputSource. JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ Thanks, Joe From mandy.chung at oracle.com Fri Dec 18 02:22:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 18:22:22 -0800 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger In-Reply-To: <56730BCB.9020600@oracle.com> References: <5672E5DD.1080302@oracle.com> <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> <56730BCB.9020600@oracle.com> Message-ID: <040D9BD4-11BA-4F34-9D5F-0D9F10971B48@oracle.com> > On Dec 17, 2015, at 11:23 AM, Daniel Fuchs wrote: > > On 12/17/15 7:02 PM, Mandy Chung wrote: >> >>> On Dec 17, 2015, at 8:42 AM, Daniel Fuchs wrote: >>> >>> Hi, >>> >>> Please find below a small enhancement for the method that infers >>> the calling class name and method name in SimpleConsoleLogger >>> and LogRecord. >>> >>> The idea is that since these methods now use the new StackWalker API >>> they should take advantage of that in order to skip classes that >>> implement System.Logger. This should make it possible for components >>> that need it to easily wrap a System.Logger (and even a j.u.l.Logger). >>> >>> 8145686: SimpleConsoleLogger and LogRecord should take advantage >>> of StackWalker to skip classes implementing System.Logger >>> https://bugs.openjdk.java.net/browse/JDK-8145686 >>> >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.00/ >> >> What is the difference between skipLoggingFrame and isLoggerImplFrame? > > isLoggingImplFrame stops when it finds the concrete logger implementation. It will unstack all the LogRecord, Handler, Filter > implementations etc... (which could be custom application classes) > > skipLoggingFrame will skip everything above the first method found > on the concrete Logger implementation until it reaches something that > looks like a calling frame. In particular it should skip other > methods of the logger implementation (e.g. log() calls log(LogRecord), > default interface methods provided by the logging framework, > reflection/method handle frames etc... > In particular it should skip any Logger wrapper classes. > It?d be helpful to add some comment in the skipLoggingFrame method. Maybe even better to change this method to isFilteredFrame?? Reflection frames and lambda forms should already be skipped by StackWalker. The remaining to skip are method handles, doPrivileged, other logging internal (do you have the case that the logging internal are called via reflection and is that why they are included here)? Looks like it?s good to check if this list should be cleaned up. Should Formatting::skipLoggingFrame to return true if System.Logger.class.isAssignableFrom(t.getDeclaringClass()) so that that check doesn?t need to be duplicated in both SimpleConsoleLogger and LogRecord? 422 if (cname.startsWith("java.lang.System$Logger")) return true; This line can be removed. > For instance, RMI has a logger that wraps a j.u.l.Logger so > ideally that should be skipped too... > JMX remote has a ClassLogger that should also be skipped. > etc? That might be the reason why skipLoggingFrame filters sun.rmi.runtime.Log? Is this necessary? This white list needs to be maintained manually which is fragile. 186 @Override public StackWalker run() { - Nit: separate @Override into a separate line Mandy From mandy.chung at oracle.com Fri Dec 18 05:34:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Dec 2015 21:34:53 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > Hi Kim, > > 34 *

    Suppose the garbage collector determines at a certain point in time > 35 * that an object is > 36 * phantom reachable. At that time it will atomically clear > 37 * all phantom references to that object and all phantom references to > 38 * any other phantom-reachable objects from which that object is reachable. > 39 * At the same time or at some later time it will enqueue those newly-cleared > 40 * phantom references that are registered with reference queues. > > XYZRefenrece concept is never being understood too well besides the authors who spend time grinding words. WeakReference (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) states this: "At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references." > > On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? > Yes it is and this is not strictly needed. For phantom reference case, this can be left ?unqualified? as it?s basically a chain of any reference type. > In addition, in src/java.base/share/classes/java/lang/ref/package-info.java, can we add WeakHashMap (https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as a concrete example of so-called canonicalized mappings to help readers understand its usage? I always need to look up for what "canonicalized mappings" really means and end up with "OK, it's WeakHashMap?. In the Notification section, it does reference WeakHashMap (although it might not contain the exact description you are looking at). Mandy > Thanks. > Tao Mao > > > > On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> > >>> [Indeed, this whole section isn't strictly necessary; all of it can be > >>> inferred from information in other places.] > >> > >> Agree. This section is no longer necessary and maybe just remove it: > > > > I wasn't actually intending to suggest removal. It seems like there > > is useful overview information to be had here, rather than requiring > > readers to make not necessarily obvious inferences. My impression is > > that readability is valued more highly than terseness in Java > > documentation. > > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > > From peter.levart at gmail.com Fri Dec 18 10:12:51 2015 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 18 Dec 2015 11:12:51 +0100 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: <5673DC23.4050304@gmail.com> Hi, Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs and _discoveredCleanerRefs is not needed any more right? Will this be a separate simplification? Regards, Peter On 12/17/2015 10:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: >> On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: >>>> [Indeed, this whole section isn't strictly necessary; all of it can be >>>> inferred from information in other places.] >>> Agree. This section is no longer necessary and maybe just remove it: >> I wasn't actually intending to suggest removal. It seems like there >> is useful overview information to be had here, rather than requiring >> readers to make not necessarily obvious inferences. My impression is >> that readability is valued more highly than terseness in Java >> documentation. > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > From Sergey.Bylokhov at oracle.com Fri Dec 18 10:52:01 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Dec 2015 13:52:01 +0300 Subject: RFR [9] 8145589: Test6277246.java fails to compile after JDK-8144479 In-Reply-To: <5672D49B.5090900@Oracle.com> References: <04440C8A-DDBF-48F2-A84F-5914D65A865A@oracle.com> <5672CC94.7050508@Oracle.com> <2FF02E24-99BC-424F-9704-801D7E0DE3C0@oracle.com> <5672D49B.5090900@Oracle.com> Message-ID: <5673E551.5090907@oracle.com> Looks fine. On 17/12/15 18:28, Roger Riggs wrote: > +1 > > On 12/17/2015 10:15 AM, Chris Hegarty wrote: >> For ease of review, I moved the complete changes into a webrev. >> >> http://cr.openjdk.java.net/~chegar/8145589/webrev/ >> >> -Chris. >> >> On 17 Dec 2015, at 15:08, Chris Hegarty wrote: >> >>> On 17 Dec 2015, at 14:54, Roger Riggs wrote: >>> >>>> Hi Chris, >>>> >>>> Looks fine. >>> Thanks Roger. Just a little addition to this review. >>> >>> While not strictly necessary, I?d like to clean up another, string, >>> reference use in a reflective call. ( It is not causing a failure as >>> the security manager will restrict access to sun.*, but it may >>> avoid confusion in the future. >>> >>> diff --git a/test/java/beans/EventHandler/Test6277246.java >>> b/test/java/beans/EventHandler/Test6277246.java >>> --- a/test/java/beans/EventHandler/Test6277246.java >>> +++ b/test/java/beans/EventHandler/Test6277246.java >>> @@ -39,7 +39,7 @@ >>> Class container = Class.forName("java.lang.Class"); >>> Class parameter = Class.forName("java.lang.String"); >>> Method method = container.getMethod("forName", parameter); >>> - Object[] arglist = new Object[] {"sun.misc.BASE64Encoder"}; >>> + Object[] arglist = new Object[] >>> {"sun.security.x509.X509CertInfo"}; >>> EventHandler eh = new EventHandler(Test6277246.class, >>> "forName", "", "forName"); >>> Object object = eh.invoke(null, method, arglist); >>> throw new Error((object != null) ? "test failure" : >>> "test error?); >>> >>> -Chris. >>> >>>> Roger >>>> >>>> >>>> On 12/17/2015 9:46 AM, Chris Hegarty wrote: >>>>> The removal of BASE64Encoder, and a related types, in 8144479 [1] >>>>> has triggered the failure of java/beans/Introspector/Test6277246.java. >>>>> Another internal type should be used instead of >>>>> sun.misc.BASE64Encoder. >>>>> The sun.security.x509 package seems stable, and is being used in other >>>>> areas, like langtools and jigsaw/jake to test accessibility. >>>>> >>>>> >>>>> diff --git a/test/java/beans/Introspector/Test6277246.java >>>>> b/test/java/beans/Introspector/Test6277246.java >>>>> --- a/test/java/beans/Introspector/Test6277246.java >>>>> +++ b/test/java/beans/Introspector/Test6277246.java >>>>> @@ -25,7 +25,7 @@ >>>>> * @test >>>>> * @bug 6277246 >>>>> * @summary Tests problem with java.beans use of reflection >>>>> - * @modules java.base/sun.misc >>>>> + * @modules java.base/sun.security.x509 >>>>> * java.desktop >>>>> * @run main/othervm Test6277246 >>>>> * @author Jeff Nisewanger >>>>> @@ -36,11 +36,10 @@ >>>>> import java.beans.Introspector; >>>>> import java.beans.MethodDescriptor; >>>>> import java.lang.reflect.Method; >>>>> -import sun.misc.BASE64Encoder; >>>>> public class Test6277246 { >>>>> public static void main(String[] args) throws >>>>> IntrospectionException { >>>>> - Class type = BASE64Encoder.class; >>>>> + Class type = sun.security.x509.X509CertInfo.class; >>>>> System.setSecurityManager(new SecurityManager()); >>>>> BeanInfo info = Introspector.getBeanInfo(type); >>>>> for (MethodDescriptor md : info.getMethodDescriptors()) { >>>>> @@ -48,7 +47,7 @@ >>>>> System.out.println(method); >>>>> String name = method.getDeclaringClass().getName(); >>>>> - if (name.startsWith("sun.misc.")) { >>>>> + if (name.startsWith("sun.")) { >>>>> throw new Error("found inaccessible method"); >>>>> } >>>>> } >>>>> >>>>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>>>> --- a/test/ProblemList.txt >>>>> +++ b/test/ProblemList.txt >>>>> @@ -126,9 +126,6 @@ >>>>> java/beans/Introspector/8132566/OverridePropertyInfoTest.java >>>>> generic-all >>>>> java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java generic-all >>>>> >>>>> -# 8145589 >>>>> -java/beans/Introspector/Test6277246.java >>>>> generic-all >>>>> - >>>>> ############################################################################ >>>>> >>>>> # jdk_lang >>>>> >>>>> >>>>> -Chris. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8144479 > -- Best regards, Sergey. From hdthanh at tma.com.vn Fri Dec 18 11:03:20 2015 From: hdthanh at tma.com.vn (Thanh Hong Dai) Date: Fri, 18 Dec 2015 18:03:20 +0700 Subject: JDK-8144811 regex.Matcher.quoteReplacement doesn't quote '&' inside the replacement string Message-ID: <041501d13983$b49d9420$1dd8bc60$@tma.com.vn> JDK-8144811: https://bugs.openjdk.java.net/browse/JDK-8144811 No repro on 8u66. Test code: import java.util.regex.Matcher; public class JDK8144811 { public static void main(String args[]) { String s = "Dogs and cats are lovely pets but cost some money to see a vet"; s = s.replaceAll("money", Matcher.quoteReplacement("$")); String and_1 = s.replaceAll("and", "&"); System.out.println(and_1); String and_2 = s.replaceAll("and", Matcher.quoteReplacement("&")); System.out.println(and_2); String workaround = s.replaceAll("and", Matcher.quoteReplacement("\\\\&")); System.out.println(workaround); } } Output: Dogs & cats are lovely pets but cost some $ to see a vet Dogs & cats are lovely pets but cost some $ to see a vet Dogs \\& cats are lovely pets but cost some $ to see a vet It's unclear what the bug reporter expects the result to be. From daniel.fuchs at oracle.com Fri Dec 18 11:30:03 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Dec 2015 12:30:03 +0100 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56716101.1080502@oracle.com> <56726EEB.6080203@oracle.com> Message-ID: <5673EE3B.7090505@oracle.com> Hu Vyom, On 17/12/15 17:58, Martin Buchholz wrote: > Looks good! Since you got Martin's blessing I will sponsor this and push it for you :-) best regards, -- daniel > > On Thu, Dec 17, 2015 at 12:14 AM, vyom wrote: >> Hi Martin, >> >> thanks for review, i undated the >> webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.2/ >> ) as per your >> comment after confirming that the corresponding "fd" if opened with >> "open64". >> >> Thanks, >> Vyom >> >> >> >> On Thursday 17 December 2015 12:38 AM, Martin Buchholz wrote: >>> >>> Calling naked fstat without _FILE_OFFSET_BITS=64 is a bug. Don't you >>> need to call fstat64 if it's available? >>> >>> +jlong >>> +handleGetLength(FD fd) >>> +{ >>> + struct stat sb; >>> + if (fstat(fd, &sb) == 0) { >>> + return sb.st_size; >>> + } else { >>> + return -1; >>> + } >>> +} >>> >>> On Wed, Dec 16, 2015 at 5:02 AM, vyom wrote: >>>> >>>> Hi, >>>> >>>> Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ >>>> ) as per Martin >>>> review comment removed the _FILE_OFFSET_BITS from source. >>>> >>>> Thanks, >>>> Vyom >>>> >>>> >>>> >>>> On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: >>>>> >>>>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >>>>> affects interoperability between translation units. It would be good >>>>> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but >>>>> that would be a big job. So traditionally the JDK has instead used >>>>> the functions made available via _LARGEFILE64_SOURCE. But that is >>>>> also a JDK-wide job now, because every call to plain stat in the >>>>> source code is broken on 32-bit systems with 64-bit inodes, which are >>>>> becoming more common. >>>>> >>>>> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job >>>>> for build-dev, not core-libs-dev. >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs >>>>> wrote: >>>>>> >>>>>> Hi Yvom, >>>>>> >>>>>> Minor comments: >>>>>> >>>>>> src/java.base/share/native/libjava/RandomAccessFile.c: >>>>>> - "length fail" might be clearer as "GetLength failed" >>>>>> >>>>>> src/java.base/unix/native/libjava/io_util_md.c: >>>>>> >>>>>> - Please add a comment before the define of FILE_OFFSET_BITS to >>>>>> indicate >>>>>> where it is used and why it is there. >>>>>> - BTW, are there any unintended side effects? >>>>>> Perhaps a different issue but perhaps 64 bit offsets should be >>>>>> used >>>>>> everywhere >>>>>> >>>>>> src/java.base/windows/native/libjava/io_util_md.c >>>>>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>>>>> elsewhere in the file >>>>>> BTW, Testing for invalid handle might be unnecessary since the >>>>>> call >>>>>> to >>>>>> GetFileSizeEx will fail >>>>>> if it is invalid, yielding the same result. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> On 12/10/2015 5:52 AM, vyom wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review my changes for below bug. >>>>>>> >>>>>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>>>>> >>>>>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>>>>> >>>>>>> >>>>>>> This change ensure that length() does not temporarily changes the >>>>>>> file >>>>>>> pointer and it will make sure that there is no race >>>>>>> condition in case of multi thread uses. >>>>>>> >>>>>>> Thanks, >>>>>>> Vyom >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> From dmitry.samersoff at oracle.com Fri Dec 18 12:05:17 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 18 Dec 2015 15:05:17 +0300 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56712726.806@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56712726.806@oracle.com> Message-ID: <5673F67D.8040506@oracle.com> Vyom, If I read the changes correctly, current code returns result of lseek() but your code returns result of fstat(). I'm not sure it's a correct replacement. dooku:test#truncate --size=102400 test.me dooku:test#./test STAT: 102400 0 Success SEEK: 2 0 Success Moreover, if you truncate a file to value that large than available free space, lseek returns appropriate error but stat - not. -Dmitry On 2015-12-16 11:56, vyom wrote: > Hi All, > > Please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ > ). I > incorporated the review comments by Roger Riggs. > > Thanks, > Vyom > > > On Tuesday 15 December 2015 10:01 PM, Roger Riggs wrote: >> Hi Yvom, >> >> Minor comments: >> >> src/java.base/share/native/libjava/RandomAccessFile.c: >> - "length fail" might be clearer as "GetLength failed" >> >> src/java.base/unix/native/libjava/io_util_md.c: >> >> - Please add a comment before the define of FILE_OFFSET_BITS to >> indicate where it is used and why it is there. >> - BTW, are there any unintended side effects? >> Perhaps a different issue but perhaps 64 bit offsets should be used >> everywhere >> >> src/java.base/windows/native/libjava/io_util_md.c >> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >> elsewhere in the file >> BTW, Testing for invalid handle might be unnecessary since the call >> to GetFileSizeEx will fail >> if it is invalid, yielding the same result. >> >> Roger >> >> On 12/10/2015 5:52 AM, vyom wrote: >>> Hi All, >>> >>> Please review my changes for below bug. >>> >>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>> >>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>> >>> >>> This change ensure that length() does not temporarily changes the >>> file pointer and it will make sure that there is no race >>> condition in case of multi thread uses. >>> >>> Thanks, >>> Vyom >>> >>> >>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sundararajan.athijegannathan at oracle.com Fri Dec 18 12:23:59 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 18 Dec 2015 17:53:59 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on Message-ID: <5673FADF.1040504@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8145750 Adding missing permissions for jdk.dynalink module. Note that it used to be part of jdk.scripting.nashorn module in the past and therefore got AllPermission. Thanks, -Sundar From magnus.ihse.bursie at oracle.com Fri Dec 18 12:40:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 13:40:21 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <5673FEB5.3080804@oracle.com> On 2015-12-16 14:50, Magnus Ihse Bursie wrote: > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus Kumar had a reply to this which unfortunately ended up on a different thread on which the component teams were not cc'ed. Here are the relevant parts: > On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote: > On 2015-12-16 16:33, Kumar Srinivasan wrote: >> Hello, >> >> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html >> >> >> You are undefining Windows math.h OVERFLOW, what is it defined >> as ? With you redefining this, will it cause problems for users of >> this API, likely to affect JNI apps. >> >> Probably need to redefine the pack200 OVERFLOW constant to >> something else, probably PACK200_OVERFLOW to prevent namespace >> collisions. > > I agree, this is a better solution. I've updated the webrev with this > solution (although I used the name PSIZE_OVERFLOW to align with > PSIZE_MAX). > > http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 > > > /Magnus /Magnus From Alan.Bateman at oracle.com Fri Dec 18 12:52:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Dec 2015 12:52:26 +0000 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5673FADF.1040504@oracle.com> References: <5673FADF.1040504@oracle.com> Message-ID: <5674018A.1040001@oracle.com> On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8145750 > > Adding missing permissions for jdk.dynalink module. Note that it used > to be part of jdk.scripting.nashorn module in the past and therefore > got AllPermission. Is it really necessary to grant it AllPermission? Just wondering how hard it would be to figure out the permissions that it really needs. If test/tools/jjs is new then it would be good to this test directory into one of the test groups so that the tests are run, maybe jdk_other. -Alan From sundararajan.athijegannathan at oracle.com Fri Dec 18 12:55:55 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 18 Dec 2015 18:25:55 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674018A.1040001@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> Message-ID: <5674025B.9090508@oracle.com> inline comments below.. On 12/18/2015 6:22 PM, Alan Bateman wrote: > > > On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8145750 >> >> Adding missing permissions for jdk.dynalink module. Note that it used >> to be part of jdk.scripting.nashorn module in the past and therefore >> got AllPermission. > Is it really necessary to grant it AllPermission? Just wondering how > hard it would be to figure out the permissions that it really needs. May be, not. But I tried giving only sun.reflect package access -- didn't work. There are a few doPrivileged blocks in dynalink code as well. This needs further analysis. But dynalink code was part of nashorn and so was getting AllPermission so far - so there is no permission enhancement by adding this missing permission block. That said, we can revisit reduced permission set for dynalink module. I'd prefer to track that as separate bug. > If test/tools/jjs is new then it would be good to this test directory > into one of the test groups so that the tests are run, maybe jdk_other. okay, I'll find out that. -Sundar > -Alan From magnus.ihse.bursie at oracle.com Fri Dec 18 13:35:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Dec 2015 14:35:19 +0100 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> Message-ID: <56740B97.5000901@oracle.com> On 2015-12-15 18:25, Martin Buchholz wrote: > _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it > affects interoperability between translation units. It would be good > to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but > that would be a big job. So traditionally the JDK has instead used > the functions made available via _LARGEFILE64_SOURCE. But that is > also a JDK-wide job now, because every call to plain stat in the > source code is broken on 32-bit systems with 64-bit inodes, which are > becoming more common. > > I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job > for build-dev, not core-libs-dev. If I understand things correctly, then setting _FILE_OFFSET_BITS=64 would mean two things: 1) Just pass this additional define to all C files being compiled (a build change) 2) Update all calls to file operating functions to make sure the proper 64-bit types are used (changes in source code). The change for 1) is a trivial one liner, while getting 2) correct is a serious undertaking in the source code. Such a change must be done by the component teams, not the build team. With that said, I think it is a reasonable change and I'll support it as much as I can. But as the division of labour is done here, it's not the work of the build team to go and make heavy modifications to the product source code. /Magnus > > > > > On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs wrote: >> Hi Yvom, >> >> Minor comments: >> >> src/java.base/share/native/libjava/RandomAccessFile.c: >> - "length fail" might be clearer as "GetLength failed" >> >> src/java.base/unix/native/libjava/io_util_md.c: >> >> - Please add a comment before the define of FILE_OFFSET_BITS to indicate >> where it is used and why it is there. >> - BTW, are there any unintended side effects? >> Perhaps a different issue but perhaps 64 bit offsets should be used >> everywhere >> >> src/java.base/windows/native/libjava/io_util_md.c >> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >> elsewhere in the file >> BTW, Testing for invalid handle might be unnecessary since the call to >> GetFileSizeEx will fail >> if it is invalid, yielding the same result. >> >> Roger >> >> >> On 12/10/2015 5:52 AM, vyom wrote: >>> Hi All, >>> >>> Please review my changes for below bug. >>> >>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>> >>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>> >>> >>> This change ensure that length() does not temporarily changes the file >>> pointer and it will make sure that there is no race >>> condition in case of multi thread uses. >>> >>> Thanks, >>> Vyom >>> >>> >>> >>> From weijun.wang at oracle.com Fri Dec 18 14:11:23 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Dec 2015 22:11:23 +0800 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> Hi Vinnie I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? Thanks Max > On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: > > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus From hannes.wallnoefer at oracle.com Fri Dec 18 14:18:57 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 18 Dec 2015 15:18:57 +0100 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5673FADF.1040504@oracle.com> References: <5673FADF.1040504@oracle.com> Message-ID: <567415D1.2060607@oracle.com> Looks good. Some of the new test scripts have an incomplete @summary line, e.g. jjs-strictTest.sh: # @summary Test that output of 'jjs -strict' Hannes Am 2015-12-18 um 13:23 schrieb Sundararajan Athijegannathan: > Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8145750 > > Adding missing permissions for jdk.dynalink module. Note that it used > to be part of jdk.scripting.nashorn module in the past and therefore > got AllPermission. > > Thanks, > -Sundar From vyom.tewari at oracle.com Fri Dec 18 20:42:00 2015 From: vyom.tewari at oracle.com (vyom) Date: Sat, 19 Dec 2015 02:12:00 +0530 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <5673F67D.8040506@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56712726.806@oracle.com> <5673F67D.8040506@oracle.com> Message-ID: <56746F98.7050300@oracle.com> Hi Dmitry, thanks for the review can you please explain little bit more, as per my testing and implementation i did not found any differences with fix and without fix. Even i checked the java.io.File.length() and there also it looks like we are using stat64(). as per you mail i truncate the file and with and without fix length is 102400, can you please explain little bit more about the problem that you mention it will be help full for me to debug further. Thanks, Vyom On Friday 18 December 2015 05:35 PM, Dmitry Samersoff wrote: > Vyom, > > If I read the changes correctly, current code returns result of lseek() > but your code returns result of fstat(). > > I'm not sure it's a correct replacement. > > > dooku:test#truncate --size=102400 test.me > > dooku:test#./test > STAT: 102400 0 Success > SEEK: 2 0 Success > > Moreover, if you truncate a file to value that large than available free > space, lseek returns appropriate error but stat - not. > > -Dmitry > > > > On 2015-12-16 11:56, vyom wrote: >> Hi All, >> >> Please find the updated >> webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ >> ). I >> incorporated the review comments by Roger Riggs. >> >> Thanks, >> Vyom >> >> >> On Tuesday 15 December 2015 10:01 PM, Roger Riggs wrote: >>> Hi Yvom, >>> >>> Minor comments: >>> >>> src/java.base/share/native/libjava/RandomAccessFile.c: >>> - "length fail" might be clearer as "GetLength failed" >>> >>> src/java.base/unix/native/libjava/io_util_md.c: >>> >>> - Please add a comment before the define of FILE_OFFSET_BITS to >>> indicate where it is used and why it is there. >>> - BTW, are there any unintended side effects? >>> Perhaps a different issue but perhaps 64 bit offsets should be used >>> everywhere >>> >>> src/java.base/windows/native/libjava/io_util_md.c >>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>> elsewhere in the file >>> BTW, Testing for invalid handle might be unnecessary since the call >>> to GetFileSizeEx will fail >>> if it is invalid, yielding the same result. >>> >>> Roger >>> >>> On 12/10/2015 5:52 AM, vyom wrote: >>>> Hi All, >>>> >>>> Please review my changes for below bug. >>>> >>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>> >>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>> >>>> >>>> This change ensure that length() does not temporarily changes the >>>> file pointer and it will make sure that there is no race >>>> condition in case of multi thread uses. >>>> >>>> Thanks, >>>> Vyom >>>> >>>> >>>> >>>> > From vladimir.x.ivanov at oracle.com Fri Dec 18 15:58:51 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 Dec 2015 18:58:51 +0300 Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed In-Reply-To: <56658B4D.1080905@oracle.com> References: <5661BF14.6070705@oracle.com> <1612154831.177401.1449488543418.JavaMail.zimbra@u-pem.fr> <56658B4D.1080905@oracle.com> Message-ID: <56742D3B.8050509@oracle.com> > http://cr.openjdk.java.net/~redestad/8144723/webrev.02/ Looks good. Best regards, Vladimir Ivanov From yiyeguhu at gmail.com Fri Dec 18 02:05:53 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Thu, 17 Dec 2015 18:05:53 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> Message-ID: Hi Kim, 34 *

    Suppose the garbage collector determines at a certain point in time 35 * that an object is 36 * phantom reachable. At that time it will atomically clear 37 * all phantom references to that object and all phantom references to 38 * any other phantom-reachable objects from which that object is reachable. 39 * At the same time or at some later time it will enqueue those newly-cleared 40 * phantom references that are registered with reference queues. XYZRefenrece concept is never being understood too well besides the authors who spend time grinding words. WeakReference ( https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) states this: "At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references." On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? In addition, in src/java.base/share/classes/java/lang/ref/package-info.java, can we add WeakHashMap ( https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as a concrete example of so-called canonicalized mappings to help readers understand its usage? I always need to look up for what "canonicalized mappings" really means and end up with "OK, it's WeakHashMap". Thanks. Tao Mao On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett wrote: > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung wrote: > >> > >>> [Indeed, this whole section isn't strictly necessary; all of it can be > >>> inferred from information in other places.] > >> > >> Agree. This section is no longer necessary and maybe just remove it: > > > > I wasn't actually intending to suggest removal. It seems like there > > is useful overview information to be had here, rather than requiring > > readers to make not necessarily obvious inferences. My impression is > > that readability is valued more highly than terseness in Java > > documentation. > > Sorry for the long gap in the discussion. Mandy and I have been > talking about what to do about the "Automatically-cleared references" > section that was the topic of some debate. We've decided to eliminate > it, which led us to some additional modifications. > > Here's the latest set of webrevs: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > They've been rebased to hs-rt tip, which required resolving a minor > merge conflict with a nearby change to logging in > referenceProcessor.cpp. Other than that, there are only specification > wording changes. Here's the incremental change from the previous > version: > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > We are treating the discussions around changing PhantomReference to > forbid a null queue as out of scope for this change. As Mandy said > earlier, she might propose a separate change for that in the future. > > From yiyeguhu at gmail.com Fri Dec 18 05:46:40 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Thu, 17 Dec 2015 21:46:40 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> Message-ID: On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote: > > > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > > > Hi Kim, > > > > 34 *

    Suppose the garbage collector determines at a certain point in > time > > 35 * that an object is > > 36 * phantom reachable. At that time it will atomically clear > > 37 * all phantom references to that object and all phantom references > to > > 38 * any other phantom-reachable objects from which that object is > reachable. > > 39 * At the same time or at some later time it will enqueue those > newly-cleared > > 40 * phantom references that are registered with reference queues. > > > > XYZRefenrece concept is never being understood too well besides the > authors who spend time grinding words. WeakReference ( > https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) > states this: "At that time it will atomically clear all weak references to > that object and all weak references to any other weakly-reachable objects > from which that object is reachable through a chain of strong and soft > references." > > > > On line 38, can we also add "through a chain of strong, soft, and weak > references." to the above, which I think is the case? > > > > Yes it is and this is not strictly needed. For phantom reference case, > this can be left ?unqualified? as it?s basically a chain of any reference > type. > Strictly speaking, any reference type but phantom reference. > > > In addition, in > src/java.base/share/classes/java/lang/ref/package-info.java, can we add > WeakHashMap ( > https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html) as > a concrete example of so-called canonicalized mappings to help readers > understand its usage? I always need to look up for what "canonicalized > mappings" really means and end up with "OK, it's WeakHashMap?. > > In the Notification section, it does reference WeakHashMap (although it > might not contain the exact description you are looking at). > Good, I see it. > > Mandy > > > Thanks. > > Tao Mao > > > > > > > > On Thu, Dec 17, 2015 at 1:30 PM, Kim Barrett > wrote: > > On Dec 4, 2015, at 1:07 PM, Kim Barrett wrote: > > > > > > On Dec 3, 2015, at 6:04 PM, Mandy Chung > wrote: > > >> > > >>> [Indeed, this whole section isn't strictly necessary; all of it can > be > > >>> inferred from information in other places.] > > >> > > >> Agree. This section is no longer necessary and maybe just remove it: > > > > > > I wasn't actually intending to suggest removal. It seems like there > > > is useful overview information to be had here, rather than requiring > > > readers to make not necessarily obvious inferences. My impression is > > > that readability is valued more highly than terseness in Java > > > documentation. > > > > Sorry for the long gap in the discussion. Mandy and I have been > > talking about what to do about the "Automatically-cleared references" > > section that was the topic of some debate. We've decided to eliminate > > it, which led us to some additional modifications. > > > > Here's the latest set of webrevs: > > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/ > > http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/ > > > > They've been rebased to hs-rt tip, which required resolving a minor > > merge conflict with a nearby change to logging in > > referenceProcessor.cpp. Other than that, there are only specification > > wording changes. Here's the incremental change from the previous > > version: > > http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/ > > > > We are treating the discussions around changing PhantomReference to > > forbid a null queue as out of scope for this change. As Mandy said > > earlier, she might propose a separate change for that in the future. > > > > > > From mandy.chung at oracle.com Fri Dec 18 17:02:54 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Dec 2015 09:02:54 -0800 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: <5673DC23.4050304@gmail.com> References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <5673DC23.4050304@gmail.com> Message-ID: > On Dec 18, 2015, at 2:12 AM, Peter Levart wrote: > > Hi, > > Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs and _discoveredCleanerRefs is not needed any more right? Will this be a separate simplification? Yes that?s the plan. http://bugs.openjdk.java.net/browse/JDK-8143847 Mandy From daniel.fuchs at oracle.com Fri Dec 18 19:07:17 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Dec 2015 20:07:17 +0100 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger In-Reply-To: <040D9BD4-11BA-4F34-9D5F-0D9F10971B48@oracle.com> References: <5672E5DD.1080302@oracle.com> <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> <56730BCB.9020600@oracle.com> <040D9BD4-11BA-4F34-9D5F-0D9F10971B48@oracle.com> Message-ID: <56745965.20006@oracle.com> Hi Mandy, Thanks for the feedback! New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.01/ On 18/12/15 03:22, Mandy Chung wrote: > It?d be helpful to add some comment in the skipLoggingFrame method. > Maybe even better to change this method to isFilteredFrame?? Done. I renamed the method. > Reflection frames and lambda forms should already be skipped by StackWalker. Good point. > The remaining to skip are method handles, doPrivileged, other logging > internal (do you have the case that the logging internal are called via > reflection and is that why they are included here)? No - it's just that if you invoke Logger.log() through reflection you don't want to see Method.invoke as the caller. But since this should be skipped by the StackWalker anyway, I removed it. > Looks like it?s good to check if this list should be cleaned up. Done. > Should Formatting::skipLoggingFrame to return true if System.Logger.class.isAssignableFrom(t.getDeclaringClass()) > so that that check doesn?t need to be duplicated in both SimpleConsoleLogger and LogRecord? Done. > 422 if (cname.startsWith("java.lang.System$Logger")) return true; > > This line can be removed. Done. >> >For instance, RMI has a logger that wraps a j.u.l.Logger so >> >ideally that should be skipped too... >> >JMX remote has a ClassLogger that should also be skipped. >> >etc? > > That might be the reason why skipLoggingFrame filters sun.rmi.runtime.Log? Is this necessary? Yes - that's the reason. At some point I'm planing to convert components that can be converted to using System.getLogger. RMI may be a tough nut to crack because IIRW it's calling java.util.logging configuration methods. > This white list needs to be maintained manually which is fragile. Hence the idea of skipping methods on classes that implement System.Logger. Those won't need to be put in the whitelist. And as a consequence they won't need to resort to calling logp in order to work around the caller inference issue (which is good since #1. logp may not be implemented by the backend, and #2. it requires either using java.util.logging or using jdk internal APIs). > 186 @Override public StackWalker run() { > > - Nit: separate @Override into a separate line Done. > > Mandy > > From martinrb at google.com Fri Dec 18 19:08:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Dec 2015 11:08:55 -0800 Subject: RFR: jsr166 jdk9 integration wave 2 In-Reply-To: References: <5652E25F.70408@gmail.com> <56531EE2.8020402@cs.oswego.edu> <5653305E.3010703@gmail.com> <5654E502.8080102@gmail.com> <56556BD8.5070203@gmail.com> <56559FB5.5090402@cs.oswego.edu> <5655CD53.7050206@gmail.com> <56717098.8020609@cs.oswego.edu> <56719557.7020606@gmail.com> Message-ID: Very sorry to muddy the waters after call for votes has gone out, but I thought of another course of action: Instead of calling addSuppressed on the source exception, call addSuppressed on the wrapping CompletionException. This has the upside that the integrity of both original exceptions is maintained, but the downside that the suppressed exception is likely to be discarded since the CompletionException is "just a wrapper". In fact, get() will do that. But we can modify reportGet to transfer any suppressed exceptions from the CompletionException to the ExecutionException, somewhat mitigating this problem, at the cost of a small tax on all users of get() who encounter abnormal completion. As to which exception gets to be the cause and which the suppressed, I still think it makes sense for the action exception to be the cause and the source exception to be suppressed, by analogy with "finally". On Wed, Dec 16, 2015 at 12:48 PM, Martin Buchholz wrote: > One more point - In try-with-resources it's clear that the try body is > the "main event" while the auto-generated calls to close are intended > to be "cleanup", so it's natural that the try body exception wins. > With whenComplete: > - it's less obvious that the whenComplete action is unimportant > - both CompletionStages may remain accessible so the risk of losing > the source exception is lower, and preserving the integrity of the > source exception is more valuable. From sean.mullan at oracle.com Fri Dec 18 19:40:40 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Dec 2015 14:40:40 -0500 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674025B.9090508@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> Message-ID: <56746138.5090806@oracle.com> On 12/18/2015 07:55 AM, Sundararajan Athijegannathan wrote: > inline comments below.. > > On 12/18/2015 6:22 PM, Alan Bateman wrote: >> >> >> On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8145750 >>> >>> Adding missing permissions for jdk.dynalink module. Note that it used >>> to be part of jdk.scripting.nashorn module in the past and therefore >>> got AllPermission. >> Is it really necessary to grant it AllPermission? Just wondering how >> hard it would be to figure out the permissions that it really needs. > > May be, not. But I tried giving only sun.reflect package access -- > didn't work. There are a few doPrivileged blocks in dynalink code as > well. This needs further analysis. > But dynalink code was part of nashorn and so was getting AllPermission > so far - so there is no permission enhancement by adding this missing > permission block. > > That said, we can revisit reduced permission set for dynalink module. > I'd prefer to track that as separate bug. Yes, please file a separate bug to track this as de-privileging is one of the main advantages of loading the module with the extension class loader. Thanks, Sean From martinrb at google.com Fri Dec 18 19:59:09 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Dec 2015 11:59:09 -0800 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56740B97.5000901@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56740B97.5000901@oracle.com> Message-ID: On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie wrote: > On 2015-12-15 18:25, Martin Buchholz wrote: >> >> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >> affects interoperability between translation units. It would be good >> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but >> that would be a big job. So traditionally the JDK has instead used >> the functions made available via _LARGEFILE64_SOURCE. But that is >> also a JDK-wide job now, because every call to plain stat in the >> source code is broken on 32-bit systems with 64-bit inodes, which are >> becoming more common. >> >> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job >> for build-dev, not core-libs-dev. > > > If I understand things correctly, then setting _FILE_OFFSET_BITS=64 would > mean two things: > 1) Just pass this additional define to all C files being compiled (a build > change) > 2) Update all calls to file operating functions to make sure the proper > 64-bit types are used (changes in source code). > > The change for 1) is a trivial one liner, while getting 2) correct is a > serious undertaking in the source code. If everyone is properly pairing up their function calls with proper types (i.e. using off_t consistently), then everything should Just Work. Such a change must be done by the > component teams, not the build team. I think this is an openjdk cultural problem - changes like this can and should be done by one person, with help from component teams where necessary. It's safer to add _FILE_OFFSET_BITS=64 everywhere at once (although hotspot and libraries can probably be cleanly separated) to avoid type size disagreement between translation units. For bonus points, we can later change all of those *64 functions back to their standard equivalents. With that said, I think it is a > reasonable change and I'll support it as much as I can. But as the division > of labour is done here, it's not the work of the build team to go and make > heavy modifications to the product source code. From kim.barrett at oracle.com Fri Dec 18 20:20:05 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Dec 2015 15:20:05 -0500 Subject: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do In-Reply-To: References: <314C97C7-9A42-4EBA-ABED-BF6F96CC2F93@oracle.com> <56603D28.6040206@gmail.com> <66282BAA-3442-4323-856A-5FF648EFC2E2@oracle.com> <5660868C.3050509@gmail.com> <4A296CC7-3671-4E6F-ABB4-52DB6EBC1FDA@oracle.com> <5632AF71-6691-42DE-AC1E-C03AF355F8B1@oracle.com> <84A72B6D-A101-435E-88D5-7D9EE1363EC9@oracle.com> Message-ID: <4B0BD0CA-957B-4CA6-8D1C-1FBEA28400A6@oracle.com> On Dec 18, 2015, at 12:46 AM, Tao Mao wrote: > > > On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote: > > > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote: > > On line 38, can we also add "through a chain of strong, soft, and weak references." to the above, which I think is the case? > > > > Yes it is and this is not strictly needed. For phantom reference case, this can be left ?unqualified? as it?s basically a chain of any reference type. > > Strictly speaking, any reference type but phantom reference. This wording (for weak references, with similar wording for others): At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references. exists to require that an implementation ensures that, after a reference has been cleared, it is no longer possible for an application to recover the former referent of that reference via a sequence of references of the same or greater strength as that reference. It can be shown by induction that the same reference type as that being cleared doesn't need to be mentioned in order to achieve that effect. Adding the cleared reference type to the chain list might impose a stronger requirement on implementations. However, we don't think an implementation can usefully take advantage of any difference, so in the case of phantom references we opted for shorter wording. From mandy.chung at oracle.com Fri Dec 18 21:41:34 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Dec 2015 13:41:34 -0800 Subject: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger In-Reply-To: <56745965.20006@oracle.com> References: <5672E5DD.1080302@oracle.com> <5E9F18FC-AA3E-40E4-92A3-5D29D5F8490B@oracle.com> <56730BCB.9020600@oracle.com> <040D9BD4-11BA-4F34-9D5F-0D9F10971B48@oracle.com> <56745965.20006@oracle.com> Message-ID: > On Dec 18, 2015, at 11:07 AM, Daniel Fuchs wrote: > > New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.01/ Looks good. Mandy From iris.clark at oracle.com Fri Dec 18 21:55:16 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:16 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565628C5.1040905@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> Message-ID: <92b9301d-2418-4618-b877-b13c88216520@default> Hi, Joe. Thanks for the review comments. >>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ > Is the intention that downstream JDK distributions, such as > IcedTea, whether based on OpenJDK or otherwise, would provide > their own specialization of the jdk.Version class? No. Downstream users may provide their own specialization, but there is no requirement that they must do so. jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. I've filed the following bug to address the more general use case: 8145793: Provide vendor-specific interpretation of a JDK version string https://bugs.openjdk.java.net/browse/JDK-8145793 > The equals / hashCode behavior of Version and OracleVersion is bit > surprising and I think somewhat underspecified given the possibility > of defining subclasses. Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > How is this API supposed to behave if the component version strings have a > numerical value greater than Integer.MAX_VALUE? >From the specification of the only instance method, Version.parse(): * @throws NumberFormatException * If an element of the version number or the build number cannot * be represented as an {@link Integer} > Was using Longs to record numerical versions rather than Integers > considered? Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. An updated webrev is forthcoming. Thanks, iris PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. From iris.clark at oracle.com Fri Dec 18 21:55:42 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:42 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565CF8C4.1020208@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> <565CF8C4.1020208@oracle.com> Message-ID: <6a1cda33-4134-4529-a97f-5e02c4158e03@default> Hi, Joe. You make a good point regarding the inconsistency between compareTo (which ignores $OPT) and equals (which includes $OPT). To resolve this difference, I will introduce two new methods so that users may choose to uniformly consider $OPT in comparisons. We now have the following: public int compareTo(Version ob); public int compareToIgnoreOpt(Version ob); public boolean equals(Version ob); public boolean equalsIgnoreOpt(Version ob); The names parallel String.{compareTo|equals}{IgnoreCase}*. I've re-arranged the code a bit around the implementation and tests for equals*() and compareTo*() to take advantage of code re-use. Thanks, iris -----Original Message----- From: joe darcy Sent: Monday, November 30, 2015 5:33 PM To: Magnus Ihse Bursie; Iris Clark; core-libs-dev at openjdk.java.net Cc: verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: > On 2015-11-25 02:54, Iris Clark wrote: >> Hi. >> >> Please review the new classes jdk.Version and jdk.OracleVersion. >> These are >> simple Java APIs to parse, validate, and compare version numbers. >> >> Bug >> >> 8072379: Implement jdk.Version and jdk.OracleVersion >> https://bugs.openjdk.java.net/browse/JDK-8072379 >> >> Webrev >> >> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > > Hi Iris, > > I thought the end agreement was that the + should always be present > even if build was empty, if opt was present but not pre. That is, > "9-foo" should unambigiously parse as vnum=9 and pre="foo", while > "9-+foo" should umambigously parse as vnum=9 and opt="foo". The > javadoc does not seem to reflect this. > > I've also had to read and re-read the regexp and parsing logic in the > constructor to convince myself that this (most likely) will be > correctly handled. Perhaps a few comments around this would be helpful? > > The comparison of two version strings which differs only in "pre" does > not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared > numerically when they consist only of digits, and lexiographically > otherwise. Numeric identifiers are considered to be less than > non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a > > I'm also surprised that equals() does not produce the same result as > compareTo(). If opt is to be ignored, surely it should be so in > equals() as well? > I'm one of the maintainers of BigDecimal, one of the few Comparable classes in the JDK where compareTo is "inconsistent with equals" (see "Effective Java, 2nd edition", Item 12 - Considering implementing Comparable). It is consistently surprising to users if compareTo is inconsistent with equals ;-) Therefore, if at all possible it is preferable to have compareTo be *consistent* rather than *inconsistent* with equals; although there are cases where the inconsistency is necessary or at least defensible. I suggest providing multiple compareFoo methods for version that did or did not include certain components, some of these could be consistent with equals and others not. HTH, -Joe From iris.clark at oracle.com Fri Dec 18 21:55:55 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:55 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56564B07.8000601@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <56564B07.8000601@oracle.com> Message-ID: Hi, Joe. It is not the intention that all JDK distributions must provide their own specializations of jdk.Version. However, downstream users may wish to provide additional semantics to the version string via encapsulation rather than inheritance. In order to facilitate this, the following bug has been filed to consider that case: 8145793: Provide vendor-specific interpretation of a JDK version string https://bugs.openjdk.java.net/browse/JDK-8145793 Thanks, iris -----Original Message----- From: joe darcy Sent: Wednesday, November 25, 2015 3:58 PM To: Mandy Chung; Iris Clark Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion PS If the concepts the two classes Version and OracleVersion are trying to capture is a "Vendor-Version" then perhaps that can be surfaced more directly in the API. That is, if the basic notion is to interpret a version string in a way appropriate to and specialized for a given vendor of the JDK (a la the java.vendor system property), then perhaps a type like // API sketch public final class VendorVersion { public VendorVersion(String vendor, Version version, Comparator versionComp>) { ...} @Override public boolean equals(VendorVersion vv) { // Usual instance of checks return Objects.equals(vendor, vv.vendor()) && versionComp.version(), vv.version()); } int compareVersion(VendorVersion vv) { if (!vendor.equals(vv.vendor())) // throw an exception return versionComp(version, vv.version); } // ... } might serve the purposes at hand. HTH, -Joe From iris.clark at oracle.com Fri Dec 18 21:55:58 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:58 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565B95AE.3030505@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <56564B07.8000601@oracle.com> <565B95AE.3030505@oracle.com> Message-ID: Hi, Joe. I've filed the following JDK 9 RFE to provide this functionality: 8145794: Provide Verona interpretation of historical JDK version strings https://bugs.openjdk.java.net/browse/JDK-8145794 Thanks, iris -----Original Message----- From: joe darcy Sent: Sunday, November 29, 2015 4:18 PM To: Mandy Chung; Iris Clark Cc: verona-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion PPS Perhaps this is already planned as future work, but it might be a kindness to those analyzing JDK version strings if there was a class that did a "best effort" at understanding Sun and Oracle JDK version strings pre-Verona to those post-Verona. In other words, a version class where new JdkVersion("1.8.0_25") would have major() == 8 and minor() == 25, but have the specified meaning for strings for Verona strings where the first group was numerically 9 or larger. Cheers, -Joe From iris.clark at oracle.com Fri Dec 18 21:56:36 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:56:36 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56586A7A.2040007@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> Message-ID: <9758b221-b38c-4028-9153-c6dd6b9977ce@default> Hi, Magnus. Thanks for the review comments. >> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > I thought the end agreement was that the + should always be present even if build was empty, if opt was present but not pre. That is, "9-foo" > should unambigiously parse as vnum=9 and pre="foo", while "9-+foo" > should umambigously parse as vnum=9 and opt="foo". The javadoc does not seem to reflect this. You have correctly summarized the expectation and the implementation. I've made the following update the class javadoc: From: * 

       *     $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)?
   *
    To: * 
       *     $VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)?
   *
    > The comparison of two version strings which differs only in "pre" does not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared numerically when they consist only of digits, and lexiographically otherwise. Numeric identifiers are considered to be less than non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a The current choice of comparison is motivated by Semantic Versioning. A goal of jdk.Version is to subset this scheme. The sorting may be counter-intuitive and it is possible that in the future we may decide that perfect alignment with semver.org is not critical. For now, we're settling with documenting the behavior. > I'm also surprised that equals() does not produce the same result as compareTo(). If opt is to be ignored, surely it should be so in equals() as well? Based on your comment and Joe's, I've added comparison methods compareTo()/equals() and compareToIgnoreOpt()/equalsIngnoreOpt() for consistency. I'll be sending an updated webrev shortly. Thanks, iris From iris.clark at oracle.com Fri Dec 18 21:56:41 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:56:41 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565626A0.6010703@Oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <565626A0.6010703@Oracle.com> Message-ID: <2bb10329-3fce-436c-bf03-85e8951270d5@default> Hi, Roger. Thanks for the feedback. >> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > I see the JEP says JDK specific, but does that rule out putting the version API in a Java.* package? For now, we should avoid including this API in java.*. If for no other reason but that we may need to evolve the API in an update release. > Version.java: > 229: The IAE("Terminal...") exception may not be that easily understood; can it > say concisely > that the build and optional elements are missing I've changed it to this which is technically more accurate (but verbose): IAE("'+' found with neither build or optional components: ':" + s + "'"). If you have a more succinct suggestion, let me know. > 264: current() should cache the value from the parse; it is likely to be called > more than once and parsing > an version string is a relatively expensive. Done. > 334: the naming of one of the version elements as 'optional' may be confusing > because optional is an adjective. > Especially when the element is optional and the method named optional returns an Optional. > Can the name be a cogent noun. how about 'info' for informational string The term "optional" to refer to this portion of the string is used in quite a few places, both inside and outside of OpenJDK code. I don't think that it would be helpful to refer to this by two different names. If you feel strongly that the name should be changed, I can file an RFE to investigate the full impact to do so. > 396: I'm not sure why BigInteger is needed; other than perhaps because it has a > constructor that takes a string. The components of $VNUM are constrained to be ints, hence if a string of numbers greater than Integer.MAX_VALUE is passed, construction of the Version will fail. $PRE is an arbitrary length String which may consist entirely of digits. As long as the string of digits may be represented as a String, there is no constraint on how many digits there are. The only time when the number of digits is a potential problem is during Version comparison. In the case when both of the Version objects contain $PRE consisting entirely of digits, we need to consider the case where the number of digits would result in a integer larger than Integer.MAX_VALUE. > 433: Optional has a .ifPresent(xxx) method that could be used to streamline the > code. > pre.ifPresent( v -> sb.append("-").append(v)); Done. > OracleVersion.java: Can this be renamed more functionally to reflect > that the 4'th component is a patch number. > It might be useful to folks other than Oracle. > > 107: the constructor should be declared private since it is not needed > outside the class. OracleVersion.java is gone. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. jdk.Version is now final, with a private constructor. An updated webrev is forthcoming. Regards, iris -----Original Message----- From: Roger Riggs Sent: Wednesday, November 25, 2015 1:23 PM To: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Hi Iris, I see the JEP says JDK specific, but does that rule out putting the version API in a Java.* package? It would support the values found in the java.version, etc properties. Perhaps as an nested class of System or Runtime? Version.java: Line 213: Seems a bit wasteful to reparse the string after the matcher has done its work; but does not use the groups for the version components. 229: The IAE("Terminal...") exception may not be that easily understood; can it say concisely that the build and optional elements are missing 264: current() should cache the value from the parse; it is likely to be called more than once and parsing an version string is a relatively expensive. 334: the naming of one of the version elements as 'optional' may be confusing because optional is an adjective. Especially when the element is optional and the method named optional returns an Optional. Can the name be a cogent noun. how about 'info' for informational string 396: I'm not sure why BigInteger is needed; other than perhaps because it has a constructor that takes a string. 433: Optional has a .ifPresent(xxx) method that could be used to streamline the code. pre.ifPresent( v -> sb.append("-").append(v)); OracleVersion.java: Can this be renamed more functionally to reflect that the 4'th component is a patch number. It might be useful to folks other than Oracle. 107: the constructor should be declared private since it is not needed outside the class. I would have preferred the Tests to be written using TestNG. Thanks, Roger From iris.clark at oracle.com Fri Dec 18 21:56:53 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:56:53 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <50765a19-34e4-4115-a32d-cea84c25394e@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> Message-ID: <1b214934-562a-414d-aa23-cd775a1edff1@default> Hi. Updated webrev and JavaDoc: Webrev http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ JavaDoc http://cr.openjdk.java.net/~iris/verona/8072379/doc.2/jdk/Version.html Thanks, iris PS: Please note that I'll be out the week of 21 December, back on 4 January. Access to e-mail will be intermittent at best. From kim.barrett at oracle.com Sat Dec 19 00:41:49 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Dec 2015 19:41:49 -0500 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: > > There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. > > This patch is provided by Timo Kinnunen . I am sponsoring this patch. > > The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. > > I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 > > /Magnus I only looked at hotspot files. Breaking this up into smaller and more focused chunks would be nice. Large changes that do 17 different things are hard to deal with. I think the various casts to uintptr_t (commented with "What???" below) should be done differently. They are addressing problems of differences between pointer size and various integer sizes, and conversions between them. I think in some cases there is a poorly chosen surrounding type involved. For the 0xdeadbeef cases, there probably ought to be a centralized helper for that sort of thing, since doing it properly on across different platforms might be tricky, and that trickiness ought to be in one place. There are a couple of "TBD"s below that I need to spend more time on. ------------------------------------------------------------------------------ Sprinkling lots of files with the following seems like a bad idea. #if _MSC_VER >= 1900 #pragma warning( disable : 4091 ) // typedef ignored on left when no variable is declared #endif Especially since these warnings may indicate actual bugs. https://msdn.microsoft.com/en-us/library/eehkcz60.aspx ------------------------------------------------------------------------------ hotspot/src/share/vm/utilities/globalDefinitions.hpp 1062 #define badAddress ((address)(intptr_t)::badAddressVal) Change the type of badAddressVal to intptr_t instead. ------------------------------------------------------------------------------ hotspot/src/share/vm/runtime/os.cpp 127 #elif defined(_WIN32) && _MSC_VER > 1800 128 const time_t zone = _timezone; Why does (recent) Windows need special handling here? ------------------------------------------------------------------------------ hotspot/src/share/vm/utilities/globalDefinitions_visCPP.hpp 198 #if _MSC_VER <= 1800 Shouldn't that be "<" the version that introduced the missing function? ------------------------------------------------------------------------------ hotspot/src/share/vm/prims/whitebox.cpp 1286 return (jlong)(uintptr_t)ikh->constants(); What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/type.cpp 53 { Bad, T_ILLEGAL, "bad", false, (int)Node::NotAMachineReg, relocInfo::none }, // Bad 61 { Bad, T_ILLEGAL, "tuple:", false, (int)Node::NotAMachineReg, relocInfo::none }, // Tuple 62 { Bad, T_ARRAY, "array:", false, (int)Node::NotAMachineReg, relocInfo::none }, // Array These are narrowing conversions in brace initializers, which are forbidden by C++11. The type of the member is int, while the initialization expressions are non-literal uint. In my opinion, it would be better to figure out how to fix the type mismatch than to sprinkle with casts. A way to look for these that doesn't require VS2015 would be to use g++ -Wnarrowing. ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/split_if.cpp 258 Node *prior_n = (Node*)(uintptr_t)0xdeadbeef; 305 prior_n = (Node*)(uintptr_t)0xdeadbeef; // Reset IDOM walk What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/gcm.cpp 1448 _node_latency = (GrowableArray *)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/compile.cpp 2398 _cfg = (PhaseCFG*)(uintptr_t)0xdeadbeef; 2399 _regalloc = (PhaseChaitin*)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/opto/buildOopMap.cpp 618 Block *pred = (Block*)(uintptr_t)0xdeadbeef; What??? ------------------------------------------------------------------------------ hotspot/src/share/vm/oops/typeArrayOop.hpp 132 *long_at_addr(which) = (jlong)contents; Yes! Fortunately, it looks like metadata_at_put is never called. ------------------------------------------------------------------------------ hotspot/src/share/vm/memory/allocation.hpp 38 #if defined _WINDOWS && _MSC_VER >= 1900 39 // 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc 40 #pragma warning( disable : 4577 ) 41 #endif Another C++11 change. Dynamic exception specifications (e.g. "throw(TYPELISTopt)" were deprecated by C++11. I think MSVC++ has always implemented "throw()" as "throwing an exception invokes undefined behavior". C++11 introduced "noexcept". I think it would be better to turn this off in the build system, rather than with with this conditional #pragma. Alternatively, perhaps replace existing uses of "throw()" with a VM_NOEXCEPT macro (or some other name) which expands into "throw()" or "noexcept" depending on the compiler and options. ------------------------------------------------------------------------------ hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp -- many, many lines -- Ouch! I'm not looking at this in detail... ------------------------------------------------------------------------------ hotspot/src/share/vm/adlc/arena.hpp 74 // Usual (non-placement) deallocation function to allow placement delete use size_t 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. 76 void operator delete(void* p); and associated code in the .cpp file. --- TBD ------------------------------------------------------------------------------ hotspot/agent/src/share/native/sadis.c 96 return (int)strlen(buf); --- TBD ------------------------------------------------------------------------------ From claes.redestad at oracle.com Sat Dec 19 01:32:30 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 19 Dec 2015 02:32:30 +0100 Subject: RFR(S): 8144723: MethodHandleImpl.initStatics is no longer needed In-Reply-To: <56742D3B.8050509@oracle.com> References: <5661BF14.6070705@oracle.com> <1612154831.177401.1449488543418.JavaMail.zimbra@u-pem.fr> <56658B4D.1080905@oracle.com> <56742D3B.8050509@oracle.com> Message-ID: <5674B3AE.9030800@oracle.com> Vladimir, R?mi and Michael, thanks for reviewing this! /Claes On 2015-12-18 16:58, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~redestad/8144723/webrev.02/ > Looks good. > > Best regards, > Vladimir Ivanov From amaembo at gmail.com Sat Dec 19 05:45:37 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sat, 19 Dec 2015 11:45:37 +0600 Subject: Producing streams in java.time? In-Reply-To: <566F3D2E.2010900@Oracle.com> References: <851620702.20151210223156@gmail.com> <566F3D2E.2010900@Oracle.com> Message-ID: <39804180.20151219114537@gmail.com> Hello, Roger! Thank you for looking at my proposal. RR> What are the use cases? It could be used to generate some per-day/per-month/per-year reports. For example, consider you have a collection of Deal objects, each with LocalDate: List deals; Using Java-8 you can easily group them by date: Map> map = deals.stream() .collect(groupingBy(Deal::getDate)); Now suppose you want to know how many deals you have for each day in the current month (including days when there are no deals). Using the proposed API you may write: YearMonth.now().days() .map(date -> date+": "+map.getOrDefault(date, Collections.emptyList()).size()+" deal(s)") .forEach(System.out::println); RR> Does it need to be more convenient? RR> It seems relatively easy to do in application code. It's relatively easy, but it's necessary to refer to the temporal object twice. Here's how it could be done now without creating additional methods: IntStream.range(1, YearMonth.now().lengthOfMonth()) .mapToObj(YearMonth.now()::atDay) .map(...).forEach(...) Such code may break when executed during the month change, so to make it robust you should introduce a variable: YearMonth now = YearMonth.now(); IntStream.range(1, now.lengthOfMonth()) .mapToObj(now::atDay) .map(...).forEach(...) Of course the static method could be introduced into some utility class in the application: public class DateStreams { public static Stream days(YearMonth ym) { return IntStream.range(1, ym.lengthOfMonth()).mapToObj(ym::atDay); } } And used like this: DateStreams.days(YearMonth.now()) .map(date -> date+": "+map.getOrDefault(date, Collections.emptyList()).size()+" deal(s)") .forEach(System.out::println); But having it in the JDK looks more natural. Especially given the fact that java.time classes are final, so cannot be extended by some third-party library. RR> Could there be a more general form that would be as useful but add fewer RR> methods? Well for convenient use I cannot imagine how to reduce the number of methods. It's possible to omit months() and days() and replace year.months() with something like this: year.atMonth(1).monthsUntil(year.plusYears(1).atMonth(1)) But it's even worse than not using the new API at all: IntStream.range(1, 12).mapToObj(year::atMonth) With best regards, Tagir Valeev. RR> Roger RR> On 12/10/2015 11:31 AM, Tagir F. Valeev wrote: >> Hello! >> >> Currently it seems that java.time package does not use Stream API in >> any way. I think it would be nice to add some methods which produce >> the streams. For example: >> >> - in class Year: >> >> // Returns sequential ordered stream of all months within this Year: >> Stream months(); >> // Returns sequential ordered stream of all days within this Year: >> Stream days(); >> // Returns sequential ordered stream of all years starting from this >> // Year until the supplied year, exclusive >> Stream yearsUntil(Temporal endExclusive); >> >> - in class YearMonth: >> >> // Returns sequential ordered stream of all days within this YearMonth: >> Stream days(); >> // Returns sequential ordered stream of all months starting from this >> // YearMonth until the supplied YearMonth, exclusive >> Stream monthsUntil(Temporal endExclusive); >> >> - in class LocalDate: >> >> // Returns sequential ordered stream of all months starting from this >> // LocalDate until the supplied LocalDate, exclusive >> Stream daysUntil(Temporal endExclusive); >> >> The implementation of these methods could be quite simple. For example: >> >> class Year { >> public Stream days() { >> return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); >> } >> } >> >> What do you think? >> >> With best regards, >> Tagir Valeev. >> From amaembo at gmail.com Sat Dec 19 05:50:04 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sat, 19 Dec 2015 11:50:04 +0600 Subject: Producing streams in java.time? In-Reply-To: <39804180.20151219114537@gmail.com> References: <851620702.20151210223156@gmail.com> <566F3D2E.2010900@Oracle.com> <39804180.20151219114537@gmail.com> Message-ID: <369657612.20151219115004@gmail.com> Fix for the previous letter: TFV> IntStream.range(1, YearMonth.now().lengthOfMonth()) TFV> .mapToObj(YearMonth.now()::atDay) TFV> .map(...).forEach(...) Of course I meant IntStream.rangeClosed instead of IntStream.range in every code sample. This just demonstrates that manual implementation of such feature is error-prone. With best regards, Tagir Valeev. From dmitry.samersoff at oracle.com Sat Dec 19 11:52:07 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 19 Dec 2015 14:52:07 +0300 Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe In-Reply-To: <56746F98.7050300@oracle.com> References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com> <56704076.8050203@Oracle.com> <56712726.806@oracle.com> <5673F67D.8040506@oracle.com> <56746F98.7050300@oracle.com> Message-ID: <567544E7.3060202@oracle.com> Vyom, I did some tests and the problem mentioned below is not relevant to Java. I can't reproduce it with Java testcase. Sorry for a noise. -Dmitry On 2015-12-18 23:42, vyom wrote: > Hi Dmitry, > > thanks for the review can you please explain little bit more, as per my > testing and implementation i did not found any differences with fix and > without fix. Even i checked the java.io.File.length() and there also it > looks like we are using stat64(). > > as per you mail i truncate the file and with and without fix length is > 102400, can you please explain little bit more about the problem that > you mention it will be help full for me to debug further. > > Thanks, > Vyom > > > On Friday 18 December 2015 05:35 PM, Dmitry Samersoff wrote: >> Vyom, >> >> If I read the changes correctly, current code returns result of lseek() >> but your code returns result of fstat(). >> >> I'm not sure it's a correct replacement. >> >> >> dooku:test#truncate --size=102400 test.me >> >> dooku:test#./test >> STAT: 102400 0 Success >> SEEK: 2 0 Success >> >> Moreover, if you truncate a file to value that large than available free >> space, lseek returns appropriate error but stat - not. >> >> -Dmitry >> >> >> >> On 2015-12-16 11:56, vyom wrote: >>> Hi All, >>> >>> Please find the updated >>> webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ >>> ). I >>> incorporated the review comments by Roger Riggs. >>> >>> Thanks, >>> Vyom >>> >>> >>> On Tuesday 15 December 2015 10:01 PM, Roger Riggs wrote: >>>> Hi Yvom, >>>> >>>> Minor comments: >>>> >>>> src/java.base/share/native/libjava/RandomAccessFile.c: >>>> - "length fail" might be clearer as "GetLength failed" >>>> >>>> src/java.base/unix/native/libjava/io_util_md.c: >>>> >>>> - Please add a comment before the define of FILE_OFFSET_BITS to >>>> indicate where it is used and why it is there. >>>> - BTW, are there any unintended side effects? >>>> Perhaps a different issue but perhaps 64 bit offsets should be used >>>> everywhere >>>> >>>> src/java.base/windows/native/libjava/io_util_md.c >>>> - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used >>>> elsewhere in the file >>>> BTW, Testing for invalid handle might be unnecessary since the call >>>> to GetFileSizeEx will fail >>>> if it is invalid, yielding the same result. >>>> >>>> Roger >>>> >>>> On 12/10/2015 5:52 AM, vyom wrote: >>>>> Hi All, >>>>> >>>>> Please review my changes for below bug. >>>>> >>>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ >>>>> >>>>> >>>>> This change ensure that length() does not temporarily changes the >>>>> file pointer and it will make sure that there is no race >>>>> condition in case of multi thread uses. >>>>> >>>>> Thanks, >>>>> Vyom >>>>> >>>>> >>>>> >>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From claes.redestad at oracle.com Sat Dec 19 13:07:58 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 19 Dec 2015 14:07:58 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base Message-ID: <567556AE.3080301@oracle.com> Hi, initializing volatile fields to their default value has a well-known performance penalty, and removing these should typically be safe. This patch addresses java.base. There are however some corner cases that we need to check for, see examples and discussion in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html When meticulously going through and checking each usage for odd pattern like this I accidentally did a bit of extra cleanup, mostly addressing a number of cases where the volatile field was being read twice. Sorry! Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.01/ It's easy to demonstrate the potential speed-up in microbenchmarks, e.g., http://cr.openjdk.java.net/~redestad/8145680/DefaultInitBench.java Note: when the parent bug was filed back in 2008 there was some internal discussion about improving javac and/or the compiler to elide these stores. That apparently led nowhere due to difficulty in detecting various corner cases, and then the actual cleanup was forgotten. Let's not go there this time, shall we? Thanks! /Claes From nadeesh.tv at oracle.com Sat Dec 19 13:45:51 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Sat, 19 Dec 2015 19:15:51 +0530 Subject: RFR:JDK-8145166 : Duration.toString violates specification Message-ID: <56755F8F.8020406@oracle.com> Hi all, Please review Bug Id - https://bugs.openjdk.java.net/browse/JDK-8145166 Issue - Duration.toString violates specification for Durations which have value in the range -59 to -60, -119 to -120 seconds etc. webrev - http://cr.openjdk.java.net/~ntv/8145166/webrev.00/ -- Thanks and Regards, Nadeesh TV From xueming.shen at oracle.com Sun Dec 20 07:35:30 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 20 Dec 2015 15:35:30 +0800 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <5672BC96.3080301@gmail.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> <5671796C.1030406@gmail.com> <5672BC96.3080301@gmail.com> Message-ID: <56765A42.3060307@oracle.com> You Yasumasa, It is no longer necessary to touch the native code (zip_util.c/h) after the native ZipFile implementation has been moved up to the java level. Those native code are for vm access only now, which I dont think care about the password support at all. But before getting into the implementation details, it might be worth having some design discussion first. Here are some questions we can start the discussion. (1) what's the benefit of exposing the public interface ZipCryption? the real question is whether or not this interface is good enough for other encryption implementation to plugin their implementation to support the ZipFile/Input/ OutputStream to their encryption spec. (2) it seems like it might be possible to hide most of the implementation and only expose the "String password" (instead of the ZipCryption) as the public interface to support the "traditional" encryption. This depends on the result of (1) though. (3) I'm concerned of pushing ZipCryption into InflaterInputStream/DeflaterOutputStream. It might be worth considering to replace the ZipCryption implementation with a pair of FilterOutput/InputStream. It would be easy and reasonable to use the FilterOutputStream for the ZipOutputStream and the FilterInputStream for the ZipFile. The PushbackInputStream in ZipInputStream might be an issue ... (4) It seems the ZipOutputStream only supports the "stream based" password, while the ZipInputStream supports the "entry based" password. Do we really need "entry based" support here? -Sherman On 12/17/15, 9:45 PM, Yasumasa Suenaga wrote: > Hi Jason, > > Thank you for your comment. > I've fixed it in new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/ > > > Thanks, > > Yasumasa > > > On 2015/12/17 0:33, Jason Mehrens wrote: >> The null check of 'entry' at line 351 of ZipFile.getInputStream is >> in conflict with line 350 and 348. >> >> ________________________________________ >> From: core-libs-dev on >> behalf of Yasumasa Suenaga >> Sent: Wednesday, December 16, 2015 8:47 AM >> To: Sergey Bylokhov; Xueming Shen >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: [PING] PoC for JDK-4347142: Need method to set >> Password protection to Zip entries >> >> Hi Sergey, >> >> Thank you for your comment. >> >> I added that description in new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/16 22:19, Sergey Bylokhov wrote: >>> Should the new methods describe how they will work in case of null >>> params? >>> >>> On 16/12/15 16:04, Yasumasa Suenaga wrote: >>>> I adapted this enhancement after JDK-8145260: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >>>> >>>> Could you review it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>>>> Hi Sherman, >>>>> >>>>> Our proposal is affected by JDK-8142508. >>>>> We have to change ZipFile.java and and ZipFile.c . >>>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>>>> repos. >>>>> >>>>> Do you have any comments about current webrev? >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>> >>>>> If you have comments, we will fix them in new webrev. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>>>> Hi Sherman, >>>>>> >>>>>> Thanks for your quick response :) >>>>>> >>>>>> I aimed to implement the "traditional" at this proposal by the below >>>>>> reasons. >>>>>> >>>>>> * We want to prepare API for encrypted zip files at first. >>>>>> * Many people use the "traditional" in problem-free scope >>>>>> like a >>>>>> temporary file. >>>>>> * We do not know which implementation of the "stronger" is >>>>>> best for >>>>>> openjdk. >>>>>> * PKWare claims that they have patents about the "stronger" on >>>>>> Zip[1]. >>>>>> * OTOH, WinZip have the alternative implementation of the >>>>>> "stronger" [2][3]. >>>>>> * Instead, we prepared the extensibility by ZipCryption >>>>>> interface to >>>>>> implement other encrypt engine, such as the AES based. >>>>>> >>>>>> Thus, I think this PoC should support the "traditional" only. >>>>>> In the future, anyone who want to implement the "stronger" can >>>>>> easily >>>>>> add their code by virtue of this proposal. >>>>>> >>>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>>>> [2] >>>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>>>> >>>>>> >>>>>> [3] http://www.winzip.com/aes_info.htm >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>>>> >>>>>>> Hi Yuji, >>>>>>> >>>>>>> I will take a look at your PoC. Might need some time and even >>>>>>> bring >>>>>>> in the >>>>>>> security guy >>>>>>> to evaluate the proposal. It seems like you are only interested >>>>>>> in the >>>>>>> "traditional PKWare >>>>>>> decryption", which is, based on the wiki, "known to be seriously >>>>>>> flawed, and >>>>>>> in particular >>>>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>>>> "stronger" encryption >>>>>>> mechanism, such as the AES based? >>>>>>> >>>>>>> Regards, >>>>>>> Sherman >>>>>>> >>>>>>> >>>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We need reviewer(s) for this PoC. >>>>>>>> Could you please review this proposal and PoC ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yuji >>>>>>>> >>>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> * Sorry for my mistake. I re-post this mail because I sent >>>>>>>>> before get >>>>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>>>> >>>>>>>>> Our customers have to handle password-protected zip files. >>>>>>>>> However, >>>>>>>>> Java SE does not provide the APIs to handle it yet, so we must >>>>>>>>> use >>>>>>>>> third party library so far. >>>>>>>>> >>>>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>>>> >>>>>>>>> The current zlib in JDK is completely unaffected by this >>>>>>>>> proposal. >>>>>>>>> The >>>>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>>>> implementation. >>>>>>>>> >>>>>>>>> We've created PoC and uploaded it as webrev: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>>>> >>>>>>>>> Test code is as below. This code will let you know how >>>>>>>>> this PoC >>>>>>>>> works. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>>>> >>>>>>>>> >>>>>>>>> In NTT, a Japanese telecommunications company. We are >>>>>>>>> providing many >>>>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>>>> implement to >>>>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>>>> desired for many developers and users. >>>>>>>>> >>>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>>>> (ysuenaga). >>>>>>>>> We want to implement it if this proposal accepted. >>>>>>>>> >>>>>>>>> [1]: >>>>>>>>> https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yuji >>>>>>> >>>>>>> >>> >>> From Alan.Bateman at oracle.com Sun Dec 20 16:23:59 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Dec 2015 16:23:59 +0000 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5674025B.9090508@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> Message-ID: <5676D61F.9070408@oracle.com> On 18/12/2015 12:55, Sundararajan Athijegannathan wrote: > > May be, not. But I tried giving only sun.reflect package access -- > didn't work. There are a few doPrivileged blocks in dynalink code as > well. This needs further analysis. > But dynalink code was part of nashorn and so was getting AllPermission > so far - so there is no permission enhancement by adding this missing > permission block. > > That said, we can revisit reduced permission set for dynalink module. > I'd prefer to track that as separate bug. Sure, a separate bug is fine. > >> If test/tools/jjs is new then it would be good to this test directory >> into one of the test groups so that the tests are run, maybe jdk_other. > > okay, I'll find out that. Looks looks core_tools will execute tools/** so I think what you have here is okay. -Alan. From claes.redestad at oracle.com Sun Dec 20 17:29:20 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 20 Dec 2015 18:29:20 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <567556AE.3080301@oracle.com> References: <567556AE.3080301@oracle.com> Message-ID: <5676E570.4080208@oracle.com> Hi, the changes to java.net.URI stood out as a bit too intrusive for a cleanup like this, and there's precious little measurable benefit. I decided to break out those to a separate RFE and simplified this patch: Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 /Claes On 2015-12-19 14:07, Claes Redestad wrote: > Hi, > > initializing volatile fields to their default value has a well-known > performance penalty, and removing these should typically be safe. This > patch addresses java.base. > > There are however some corner cases that we need to check for, see > examples and discussion in > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html > > When meticulously going through and checking each usage for odd > pattern like this I accidentally did a bit of extra cleanup, mostly > addressing a number of cases where the volatile field was being read > twice. Sorry! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 > From joel.borggren.franck at gmail.com Sun Dec 20 19:33:06 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Sun, 20 Dec 2015 20:33:06 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5676E570.4080208@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> Message-ID: Hi Claes, src/java.base/share/classes/java/lang/reflect/Parameter.java src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java looks fine to me. src/java.base/share/classes/java/lang/Class.java is fine to but isn't enumConstants = constants = temporatyConstants; slightly more idiomatic than - enumConstants = temporaryConstants; + constants = temporaryConstants; + enumConstants = constants; cheers /Joel On Sun, Dec 20, 2015 at 6:29 PM, Claes Redestad wrote: > Hi, > > the changes to java.net.URI stood out as a bit too intrusive for a cleanup > like this, and there's precious little measurable benefit. I decided to > break out those to a separate RFE and simplified this patch: > > Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 > > /Claes > > > On 2015-12-19 14:07, Claes Redestad wrote: >> >> Hi, >> >> initializing volatile fields to their default value has a well-known >> performance penalty, and removing these should typically be safe. This patch >> addresses java.base. >> >> There are however some corner cases that we need to check for, see >> examples and discussion in >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >> >> When meticulously going through and checking each usage for odd pattern >> like this I accidentally did a bit of extra cleanup, mostly addressing a >> number of cases where the volatile field was being read twice. Sorry! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 >> > From Ulf.Zibis at CoSoCo.de Sun Dec 20 19:43:43 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Sun, 20 Dec 2015 20:43:43 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5676E570.4080208@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> Message-ID: <567704EF.7040803@CoSoCo.de> Hi Claes, I had a very short look and found in j.l.Thread: 211 * Java thread status for tools, 0 indicate thread 'not yet started' I guess you meant: 211 * Java thread status for tools; 0 indicates: thread 'not yet started'. -Ulf Am 20.12.2015 um 18:29 schrieb Claes Redestad: > Hi, > > the changes to java.net.URI stood out as a bit too intrusive for a cleanup like this, and there's > precious little measurable benefit. I decided to break out those to a separate RFE and simplified > this patch: > > Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 > > /Claes > > On 2015-12-19 14:07, Claes Redestad wrote: >> Hi, >> >> initializing volatile fields to their default value has a well-known performance penalty, and >> removing these should typically be safe. This patch addresses java.base. >> >> There are however some corner cases that we need to check for, see examples and discussion in >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >> >> When meticulously going through and checking each usage for odd pattern like this I accidentally >> did a bit of extra cleanup, mostly addressing a number of cases where the volatile field was >> being read twice. Sorry! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 >> > > From joel.borggren.franck at gmail.com Sun Dec 20 19:46:46 2015 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Sun, 20 Dec 2015 20:46:46 +0100 Subject: General question: sun package -> jdk package? In-Reply-To: <567157A0.5030908@oracle.com> References: <567157A0.5030908@oracle.com> Message-ID: Do you know if it is only newConstructorForSerialization? Is it worth keeping a minimal ReflectionFactory in sun.reflect that only exposes that? On Wed, Dec 16, 2015 at 1:22 PM, Chris Hegarty wrote: > On 15/12/15 18:56, Joel Borggr?n-Franck wrote: >> >> Hi Chris, >> >> I'm somewhat surprised to see ReflectionFactory on that list. Can you >> share more details around its external use? > > > ReflectionFactory.newConstructorForSerialization is used by several > popular third party serialization, mocking, proxying, libraries to > construct objects in a non-standard way. > > -Chris. > >> cheers >> /Joel >> >> On Tue, 15 Dec 2015 at 16:15 Chris Hegarty > > wrote: >> >> Paul, >> >> I cannot address your general question, but I guess it might be >> motivated >> by some of my recent preparatory work for JEP 260 [1]. This JEP >> proposes >> to expose a small number of critical API?s that are in the sun.misc >> and >> sun.reflect namespace. Anything not deemed critical should be removed >> from these packages, since it should not be exposed. There is also a >> significant amount of technical debt in these packages. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8132928 >> >> On 15 Dec 2015, at 15:09, Paul Benedict > > wrote: >> >> > I have a general question prompted by the many classes moved from >> sun.* to >> > jdk.*. Once JDK 9 delivers on the Module System and internals are >> no longer >> > exposed, is it planned to eventually migrate away from the sun.* >> legacy >> > namespace in later JDK versions? >> > >> > Cheers, >> > Paul >> > From jason_mehrens at hotmail.com Sun Dec 20 20:02:50 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sun, 20 Dec 2015 20:02:50 +0000 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5676E570.4080208@oracle.com> References: <567556AE.3080301@oracle.com>,<5676E570.4080208@oracle.com> Message-ID: Claes, For the cases where boolean was being assigned to 'true' (ASSCI and FileLockImpl) does it hurt performance since the accessor methods will now include a branch at the bytecode level? See: "Speed-kings of inverting booleans" at http://www.javaspecialists.eu/archive/Issue042.html Jason ________________________________________ From: core-libs-dev on behalf of Claes Redestad Sent: Sunday, December 20, 2015 11:29 AM To: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base Hi, the changes to java.net.URI stood out as a bit too intrusive for a cleanup like this, and there's precious little measurable benefit. I decided to break out those to a separate RFE and simplified this patch: Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 /Claes On 2015-12-19 14:07, Claes Redestad wrote: > Hi, > > initializing volatile fields to their default value has a well-known > performance penalty, and removing these should typically be safe. This > patch addresses java.base. > > There are however some corner cases that we need to check for, see > examples and discussion in > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html > > When meticulously going through and checking each usage for odd > pattern like this I accidentally did a bit of extra cleanup, mostly > addressing a number of cases where the volatile field was being read > twice. Sorry! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 > From chris.hegarty at oracle.com Sun Dec 20 20:54:32 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 20 Dec 2015 20:54:32 +0000 Subject: General question: sun package -> jdk package? In-Reply-To: References: <567157A0.5030908@oracle.com> Message-ID: <36EF4869-7EEC-4C63-A375-2C3A902D3BB6@oracle.com> > On 20 Dec 2015, at 19:46, Joel Borggr?n-Franck wrote: > > Do you know if it is only newConstructorForSerialization? That is our understanding. > Is it worth > keeping a minimal ReflectionFactory in sun.reflect that only exposes > that? That is the current plan. -Chris. > On Wed, Dec 16, 2015 at 1:22 PM, Chris Hegarty wrote: >> On 15/12/15 18:56, Joel Borggr?n-Franck wrote: >>> >>> Hi Chris, >>> >>> I'm somewhat surprised to see ReflectionFactory on that list. Can you >>> share more details around its external use? >> >> >> ReflectionFactory.newConstructorForSerialization is used by several >> popular third party serialization, mocking, proxying, libraries to >> construct objects in a non-standard way. >> >> -Chris. >> >>> cheers >>> /Joel >>> >>> On Tue, 15 Dec 2015 at 16:15 Chris Hegarty >> > wrote: >>> >>> Paul, >>> >>> I cannot address your general question, but I guess it might be >>> motivated >>> by some of my recent preparatory work for JEP 260 [1]. This JEP >>> proposes >>> to expose a small number of critical API?s that are in the sun.misc >>> and >>> sun.reflect namespace. Anything not deemed critical should be removed >>> from these packages, since it should not be exposed. There is also a >>> significant amount of technical debt in these packages. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8132928 >>> >>> On 15 Dec 2015, at 15:09, Paul Benedict >> > wrote: >>> >>>> I have a general question prompted by the many classes moved from >>> sun.* to >>>> jdk.*. Once JDK 9 delivers on the Module System and internals are >>> no longer >>>> exposed, is it planned to eventually migrate away from the sun.* >>> legacy >>>> namespace in later JDK versions? >>>> >>>> Cheers, >>>> Paul >>> >> From claes.redestad at oracle.com Sun Dec 20 23:06:06 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 00:06:06 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> Message-ID: <5677345E.50503@oracle.com> Hi all, On 2015-12-20 20:43, Ulf wrote: > Hi Claes, > > I had a very short look and found in j.l.Thread: > 211 * Java thread status for tools, 0 indicate thread 'not yet > started' > I guess you meant: > 211 * Java thread status for tools; 0 indicates: thread 'not yet > started'. > > -Ulf /* * Java thread status for tools, default indicates thread 'not yet started' */ OK? On 2015-12-20 21:02, Jason Mehrens wrote: > Claes, > > For the cases where boolean was being assigned to 'true' (ASSCI and FileLockImpl) does it hurt performance since the accessor methods will now include a branch at the bytecode level? See: "Speed-kings of inverting booleans" at http://www.javaspecialists.eu/archive/Issue042.html > > Jason I don't think this is an issue any more: public volatile boolean trueValue = true; public volatile boolean falseValue = false; @Benchmark @CompilerControl(CompilerControl.Mode.DONT_INLINE) public boolean trueWithFalseValue() throws Exception { return !falseValue; } @Benchmark @CompilerControl(CompilerControl.Mode.DONT_INLINE) public boolean trueWithTrueValue() throws Exception { return trueValue; } DefaultInitBench.trueWithFalseValue avgt 25 4.538 ? 0.353 ns/op DefaultInitBench.trueWithTrueValue avgt 25 4.726 ? 0.466 ns/op On 2015-12-20 20:33, Joel Borggr?n-Franck wrote: > Hi Claes, > > src/java.base/share/classes/java/lang/reflect/Parameter.java > src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java > src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java > > looks fine to me. > > src/java.base/share/classes/java/lang/Class.java > > is fine to but isn't > > enumConstants = constants = temporatyConstants; > > slightly more idiomatic than > > - enumConstants = temporaryConstants; > + constants = temporaryConstants; > + enumConstants = constants; I'm fine either way; updated in-place in this and a few other places. Thanks! /Claes > On Sun, Dec 20, 2015 at 6:29 PM, Claes Redestad > wrote: >> Hi, >> >> the changes to java.net.URI stood out as a bit too intrusive for a cleanup >> like this, and there's precious little measurable benefit. I decided to >> break out those to a separate RFE and simplified this patch: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 >> >> /Claes >> >> >> On 2015-12-19 14:07, Claes Redestad wrote: >>> Hi, >>> >>> initializing volatile fields to their default value has a well-known >>> performance penalty, and removing these should typically be safe. This patch >>> addresses java.base. >>> >>> There are however some corner cases that we need to check for, see >>> examples and discussion in >>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >>> >>> When meticulously going through and checking each usage for odd pattern >>> like this I accidentally did a bit of extra cleanup, mostly addressing a >>> number of cases where the volatile field was being read twice. Sorry! >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 >>> From sundararajan.athijegannathan at oracle.com Mon Dec 21 04:11:34 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Dec 2015 09:41:34 +0530 Subject: RFR 8145750: jjs fails to run simple scripts with security manager turned on In-Reply-To: <5676D61F.9070408@oracle.com> References: <5673FADF.1040504@oracle.com> <5674018A.1040001@oracle.com> <5674025B.9090508@oracle.com> <5676D61F.9070408@oracle.com> Message-ID: <56777BF6.6010708@oracle.com> File a separate to track jdk.dynalink permissions: https://bugs.openjdk.java.net/browse/JDK-8145868 Adjusted test comments that Hannes mentioned and pushing changes in webrev @ http://cr.openjdk.java.net/~sundar/8145750/webrev.01/ Thanks -Sundar On 12/20/2015 9:53 PM, Alan Bateman wrote: > On 18/12/2015 12:55, Sundararajan Athijegannathan wrote: >> >> May be, not. But I tried giving only sun.reflect package access -- >> didn't work. There are a few doPrivileged blocks in dynalink code as >> well. This needs further analysis. >> But dynalink code was part of nashorn and so was getting >> AllPermission so far - so there is no permission enhancement by >> adding this missing permission block. >> >> That said, we can revisit reduced permission set for dynalink module. >> I'd prefer to track that as separate bug. > Sure, a separate bug is fine. > > >> >>> If test/tools/jjs is new then it would be good to this test >>> directory into one of the test groups so that the tests are run, >>> maybe jdk_other. >> >> okay, I'll find out that. > Looks looks core_tools will execute tools/** so I think what you have > here is okay. > > -Alan. From amy.lu at oracle.com Mon Dec 21 04:53:00 2015 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 21 Dec 2015 12:53:00 +0800 Subject: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing Message-ID: <567785AC.1010808@oracle.com> sun/management/jmxremote/startstop/JMXStartStopTest.java sun/tools/jstatd/TestJstatdServer.java Above tests are known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8145869 webrev: http://cr.openjdk.java.net/~amlu/8145869/webrev.00/ Thanks, Amy --- old/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 +++ new/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 @@ -58,7 +58,7 @@ * @run main/othervm/timeout=600 -XX:+UsePerfData JMXStartStopTest * @summary Makes sure that enabling/disabling the management agent through JCMD * achieves the desired results - * @key randomness + * @key randomness intermittent */ public class JMXStartStopTest { private static final String TEST_APP_NAME = "TestApp"; --- old/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 +++ new/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 @@ -24,6 +24,7 @@ /* * @test * @bug 4990825 + * @key intermittent * @library /lib/testlibrary * @modules java.management * @build jdk.testlibrary.* JstatdTest JstatGCUtilParser From aph at redhat.com Mon Dec 21 09:46:37 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Dec 2015 09:46:37 +0000 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> Message-ID: <5677CA7D.5050101@redhat.com> On 20/12/15 20:02, Jason Mehrens wrote: > For the cases where boolean was being assigned to 'true' (ASSCI and > FileLockImpl) does it hurt performance since the accessor methods > will now include a branch at the bytecode level? That depends on the caller. A trivial accessor method will usually be inlined: if the caller uses ! foo.isOpen(), say, the two uses of ! will cancel. > See: "Speed-kings of inverting booleans" at > http://www.javaspecialists.eu/archive/Issue042.html That's from 2002, and not valid any more. Maybe not valid even back then. Andrew. From aleksey.shipilev at oracle.com Mon Dec 21 10:02:11 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 21 Dec 2015 13:02:11 +0300 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677CA7D.5050101@redhat.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677CA7D.5050101@redhat.com> Message-ID: <5677CE23.9010509@oracle.com> On 12/21/2015 12:46 PM, Andrew Haley wrote: >> See: "Speed-kings of inverting booleans" at >> http://www.javaspecialists.eu/archive/Issue042.html > > That's from 2002, and not valid any more. Maybe not valid even back > then. It is not valid today, I've checked a while ago: http://cr.openjdk.java.net/~shade/scratch/BooleanNegate.java -Aleksey From chris.hegarty at oracle.com Mon Dec 21 10:06:35 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Dec 2015 10:06:35 +0000 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677345E.50503@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677345E.50503@oracle.com> Message-ID: <5677CF2B.6010607@oracle.com> Thanks for doing this Claes. The changes look good to me. -Chris. On 20/12/15 23:06, Claes Redestad wrote: > Hi all, > > On 2015-12-20 20:43, Ulf wrote: >> Hi Claes, >> >> I had a very short look and found in j.l.Thread: >> 211 * Java thread status for tools, 0 indicate thread 'not yet >> started' >> I guess you meant: >> 211 * Java thread status for tools; 0 indicates: thread 'not yet >> started'. >> >> -Ulf > > /* > * Java thread status for tools, default indicates thread 'not yet > started' > */ > > OK? > > On 2015-12-20 21:02, Jason Mehrens wrote: >> Claes, >> >> For the cases where boolean was being assigned to 'true' (ASSCI and >> FileLockImpl) does it hurt performance since the accessor methods will >> now include a branch at the bytecode level? See: "Speed-kings of >> inverting booleans" at >> http://www.javaspecialists.eu/archive/Issue042.html >> >> Jason > > I don't think this is an issue any more: > > public volatile boolean trueValue = true; > public volatile boolean falseValue = false; > > @Benchmark > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > public boolean trueWithFalseValue() throws Exception { > return !falseValue; > } > > @Benchmark > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > public boolean trueWithTrueValue() throws Exception { > return trueValue; > } > > DefaultInitBench.trueWithFalseValue avgt 25 4.538 ? 0.353 ns/op > DefaultInitBench.trueWithTrueValue avgt 25 4.726 ? 0.466 ns/op > > On 2015-12-20 20:33, Joel Borggr?n-Franck wrote: >> Hi Claes, >> >> src/java.base/share/classes/java/lang/reflect/Parameter.java >> src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java >> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java >> >> >> looks fine to me. >> >> src/java.base/share/classes/java/lang/Class.java >> >> is fine to but isn't >> >> enumConstants = constants = temporatyConstants; >> >> slightly more idiomatic than >> >> - enumConstants = temporaryConstants; >> + constants = temporaryConstants; >> + enumConstants = constants; > > I'm fine either way; updated in-place in this and a few other places. > > Thanks! > > /Claes > >> On Sun, Dec 20, 2015 at 6:29 PM, Claes Redestad >> wrote: >>> Hi, >>> >>> the changes to java.net.URI stood out as a bit too intrusive for a >>> cleanup >>> like this, and there's precious little measurable benefit. I decided to >>> break out those to a separate RFE and simplified this patch: >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 >>> >>> /Claes >>> >>> >>> On 2015-12-19 14:07, Claes Redestad wrote: >>>> Hi, >>>> >>>> initializing volatile fields to their default value has a well-known >>>> performance penalty, and removing these should typically be safe. >>>> This patch >>>> addresses java.base. >>>> >>>> There are however some corner cases that we need to check for, see >>>> examples and discussion in >>>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >>>> >>>> >>>> When meticulously going through and checking each usage for odd pattern >>>> like this I accidentally did a bit of extra cleanup, mostly >>>> addressing a >>>> number of cases where the volatile field was being read twice. Sorry! >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 >>>> > From Ulf.Zibis at CoSoCo.de Mon Dec 21 10:31:34 2015 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Mon, 21 Dec 2015 11:31:34 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677345E.50503@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677345E.50503@oracle.com> Message-ID: <5677D506.2020006@CoSoCo.de> Am 21.12.2015 um 00:06 schrieb Claes Redestad: > Hi all, > > On 2015-12-20 20:43, Ulf wrote: >> Hi Claes, >> >> I had a very short look and found in j.l.Thread: >> 211 * Java thread status for tools, 0 indicate thread 'not yet started' >> I guess you meant: >> 211 * Java thread status for tools; 0 indicates: thread 'not yet started'. >> >> -Ulf > > /* > * Java thread status for tools, default indicates thread 'not yet started' > */ > > OK? To my feeling, 0 is more clear than default. Often enough the default for a value is other than 0, so the user ends up to search for "What is the default of this value?". Also I think, the expression "thread 'not yet started'" should be separated in some way from the rest of the phrase, maybe just shift the "'" one word before. -Ulf From Ulf.Zibis at CoSoCo.de Mon Dec 21 11:32:44 2015 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 21 Dec 2015 12:32:44 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677D506.2020006@CoSoCo.de> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677345E.50503@oracle.com> <5677D506.2020006@CoSoCo.de> Message-ID: <5677E35C.5000103@CoSoCo.de> Am 21.12.2015 um 11:31 schrieb Ulf: > Am 21.12.2015 um 00:06 schrieb Claes Redestad: >> Hi all, >> >> On 2015-12-20 20:43, Ulf wrote: >>> Hi Claes, >>> >>> I had a very short look and found in j.l.Thread: >>> 211 * Java thread status for tools, 0 indicate thread 'not yet started' >>> I guess you meant: >>> 211 * Java thread status for tools; 0 indicates: thread 'not yet started'. >>> >>> -Ulf >> >> /* >> * Java thread status for tools, default indicates thread 'not yet started' >> */ >> >> OK? > > To my feeling, 0 is more clear than default. > Often enough the default for a value is other than 0, so the user ends up to search for "What is > the default of this value?". > Also I think, the expression "thread 'not yet started'" should be separated in some way from the > rest of the phrase, maybe just shift the "'" one word before. Using both seems a good compromise, and remember punctuation please: * Java thread status for tools(,|;) default 0 indicates: thread 'not yet started'. -Ulf From Alan.Bateman at oracle.com Mon Dec 21 12:01:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Dec 2015 12:01:09 +0000 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <567556AE.3080301@oracle.com> References: <567556AE.3080301@oracle.com> Message-ID: <5677EA05.4060508@oracle.com> On 19/12/2015 13:07, Claes Redestad wrote: > Hi, > > initializing volatile fields to their default value has a well-known > performance penalty, and removing these should typically be safe. This > patch addresses java.base. > > There are however some corner cases that we need to check for, see > examples and discussion in > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html > > When meticulously going through and checking each usage for odd > pattern like this I accidentally did a bit of extra cleanup, mostly > addressing a number of cases where the volatile field was being read > twice. Sorry! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 > > Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.01/ I skimmed through the webrev and it looks okay. A few classes are arguably less-readable now due to the double negatives (!invalid). I see the changes to URI have been split out to a separate issue because it does other clean-ups. In this case it might be better to keep defineString and it return the String rather than calling toString and needing to explain the side effect in several places. -Alan. From aleksey.shipilev at oracle.com Mon Dec 21 13:33:01 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 21 Dec 2015 16:33:01 +0300 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <567556AE.3080301@oracle.com> References: <567556AE.3080301@oracle.com> Message-ID: <5677FF8D.6030309@oracle.com> On 12/19/2015 04:07 PM, Claes Redestad wrote: > When meticulously going through and checking each usage for odd pattern > like this I accidentally did a bit of extra cleanup, mostly addressing a > number of cases where the volatile field was being read twice. Sorry! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 > > Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.01/ Looks good. > Note: when the parent bug was filed back in 2008 there was some > internal discussion about improving javac and/or the compiler to > elide these stores. That apparently led nowhere due to difficulty in > detecting various corner cases, and then the actual cleanup was > forgotten. Let's not go there this time, shall we? I agree with this sentiment; but we should also try to not to penalize assigning default values, if done for code clarity reasons. I'll submit a few HotSpot compiler RFEs for that. Thanks, -Aleksey From kubota.yuji at gmail.com Mon Dec 21 13:38:54 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 21 Dec 2015 22:38:54 +0900 Subject: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <56765A42.3060307@oracle.com> References: <565FB732.4090401@oracle.com> <566C11A7.1070309@gmail.com> <56716147.20100@gmail.com> <567164D8.8040201@oracle.com> <5671796C.1030406@gmail.com> <5672BC96.3080301@gmail.com> <56765A42.3060307@oracle.com> Message-ID: Hi Sherman, 2015-12-20 16:35 GMT+09:00 Xueming Shen : > It is no longer necessary to touch the native code (zip_util.c/h) after the > native ZipFile implementation has been moved up to the java level. Those > native code are for vm access only now, which I dont think care about the > password support at all. Thanks for your information. We do not take care the native. I discussed with Yasumasa, and our thought is as below. > (1) what's the benefit of exposing the public interface ZipCryption? the real > question is whether or not this interface is good enough for other encryption > implementation to plugin their implementation to support the ZipFile/Input/ > OutputStream to their encryption spec. We aimed that the public interface ZipCryption supports the extensibillity for other encrypt engine. The JDK core libs developers have to implementation ZipyCryption only. If not provide, the JDK developers must implement ZipStream/Entry by JDK API to design the data structure of entry. If you want to use binary key data such as PKI, you can implement new encrypt/decrypt engine by ZipCryption interface. So we think we should provide this interface to be clearly how to implement a new engine, e.g., cipher algorithm, cipher strength and converting the header, etc. > (2) it seems like it might be possible to hide most of the implementation > and only expose the "String password" (instead of the ZipCryption) as the > public interface to support the "traditional" encryption. This depends on the > result of (1) though. Thanks for your clues. We think the string password at first. However, we should also create a new binary interface given we support PKI in the future. > (3) I'm concerned of pushing ZipCryption into InflaterInputStream/DeflaterOutputStream. > It might be worth considering to replace the ZipCryption implementation with > a pair of FilterOutput/InputStream. It would be easy and reasonable to use > the FilterOutputStream for the ZipOutputStream and the FilterInputStream for the > ZipFile. The PushbackInputStream in ZipInputStream might be an issue ... Thanks for your clues, too. Honestly speaking, we think the current zip implementation may break the data when used PushbackInputStream for the following reasons. * PushbackInputStream uses an unique internal buffer for re-read operation. * But, InflaterInputStream provide date to Inflater per reads and buffer by JNI (zlib). * So we think PushbackInputStream is poor compatibility with InflaterInputStream. We generally use InputStream through ZipEntry#getInputStream(). We do not touch FileInputStream for reading ZIP data. If we call unread() when we use PushbackInputStream as reading ZIP archive, we guess that it will break the reading data. So, our approach do not affect the PushbackInputStream. What do you think about this? > (4) It seems the ZipOutputStream only supports the "stream based" password, while > the ZipInputStream supports the "entry based" password. Do we really need > "entry based" support here? As your suggestion, we should support "entry based". We will start to implement "entry based" after this discussion is closed. Thanks, Yuji > On 12/17/15, 9:45 PM, Yasumasa Suenaga wrote: >> >> Hi Jason, >> >> Thank you for your comment. >> I've fixed it in new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/17 0:33, Jason Mehrens wrote: >>> >>> The null check of 'entry' at line 351 of ZipFile.getInputStream is in >>> conflict with line 350 and 348. >>> >>> ________________________________________ >>> From: core-libs-dev on behalf of >>> Yasumasa Suenaga >>> Sent: Wednesday, December 16, 2015 8:47 AM >>> To: Sergey Bylokhov; Xueming Shen >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: [PING] PoC for JDK-4347142: Need method to set Password >>> protection to Zip entries >>> >>> Hi Sergey, >>> >>> Thank you for your comment. >>> >>> I added that description in new webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/12/16 22:19, Sergey Bylokhov wrote: >>>> >>>> Should the new methods describe how they will work in case of null >>>> params? >>>> >>>> On 16/12/15 16:04, Yasumasa Suenaga wrote: >>>>> >>>>> I adapted this enhancement after JDK-8145260: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ >>>>> >>>>> Could you review it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/12/12 21:23, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi Sherman, >>>>>> >>>>>> Our proposal is affected by JDK-8142508. >>>>>> We have to change ZipFile.java and and ZipFile.c . >>>>>> Thus we will create a new webrev for current (after 8142508) jdk9/dev >>>>>> repos. >>>>>> >>>>>> Do you have any comments about current webrev? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>> >>>>>> If you have comments, we will fix them in new webrev. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2015/12/03 16:51, KUBOTA Yuji wrote: >>>>>>> >>>>>>> Hi Sherman, >>>>>>> >>>>>>> Thanks for your quick response :) >>>>>>> >>>>>>> I aimed to implement the "traditional" at this proposal by the below >>>>>>> reasons. >>>>>>> >>>>>>> * We want to prepare API for encrypted zip files at first. >>>>>>> * Many people use the "traditional" in problem-free scope like a >>>>>>> temporary file. >>>>>>> * We do not know which implementation of the "stronger" is best >>>>>>> for >>>>>>> openjdk. >>>>>>> * PKWare claims that they have patents about the "stronger" on >>>>>>> Zip[1]. >>>>>>> * OTOH, WinZip have the alternative implementation of the >>>>>>> "stronger" [2][3]. >>>>>>> * Instead, we prepared the extensibility by ZipCryption interface >>>>>>> to >>>>>>> implement other encrypt engine, such as the AES based. >>>>>>> >>>>>>> Thus, I think this PoC should support the "traditional" only. >>>>>>> In the future, anyone who want to implement the "stronger" can easily >>>>>>> add their code by virtue of this proposal. >>>>>>> >>>>>>> [1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>> (1.4 Permitted Use & 7.0 Strong Encryption Specification) >>>>>>> [2] >>>>>>> >>>>>>> https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy >>>>>>> >>>>>>> [3] http://www.winzip.com/aes_info.htm >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>>>> >>>>>>> 2015-12-03 12:29 GMT+09:00 Xueming Shen : >>>>>>>> >>>>>>>> >>>>>>>> Hi Yuji, >>>>>>>> >>>>>>>> I will take a look at your PoC. Might need some time and even bring >>>>>>>> in the >>>>>>>> security guy >>>>>>>> to evaluate the proposal. It seems like you are only interested in >>>>>>>> the >>>>>>>> "traditional PKWare >>>>>>>> decryption", which is, based on the wiki, "known to be seriously >>>>>>>> flawed, and >>>>>>>> in particular >>>>>>>> is vulnerable to known-plaintext attacks":-) Any request to support >>>>>>>> "stronger" encryption >>>>>>>> mechanism, such as the AES based? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Sherman >>>>>>>> >>>>>>>> >>>>>>>> On 12/2/15 6:48 PM, KUBOTA Yuji wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> We need reviewer(s) for this PoC. >>>>>>>>> Could you please review this proposal and PoC ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yuji >>>>>>>>> >>>>>>>>> 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> * Sorry for my mistake. I re-post this mail because I sent before >>>>>>>>>> get >>>>>>>>>> a response of subscription confirmation of core-libs-dev. >>>>>>>>>> >>>>>>>>>> Our customers have to handle password-protected zip files. >>>>>>>>>> However, >>>>>>>>>> Java SE does not provide the APIs to handle it yet, so we must use >>>>>>>>>> third party library so far. >>>>>>>>>> >>>>>>>>>> Recently, we found JDK-4347142: "Need method to set Password >>>>>>>>>> protection to Zip entries", and we tried to implement it. >>>>>>>>>> >>>>>>>>>> The current zlib in JDK is completely unaffected by this proposal. >>>>>>>>>> The >>>>>>>>>> traditional zip encryption encrypts a data after it is has been >>>>>>>>>> compressed by zlib.[1] So we do NOT need to change existing zlib >>>>>>>>>> implementation. >>>>>>>>>> >>>>>>>>>> We've created PoC and uploaded it as webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ >>>>>>>>>> >>>>>>>>>> Test code is as below. This code will let you know how this >>>>>>>>>> PoC >>>>>>>>>> works. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java >>>>>>>>>> >>>>>>>>>> In NTT, a Japanese telecommunications company. We are providing >>>>>>>>>> many >>>>>>>>>> enterprise systems to customers. Some of them, we need to >>>>>>>>>> implement to >>>>>>>>>> handle password-protected zip file. I guess that this proposal is >>>>>>>>>> desired for many developers and users. >>>>>>>>>> >>>>>>>>>> I'm working together with Yasumasa Suenaga, jdk9 committer >>>>>>>>>> (ysuenaga). >>>>>>>>>> We want to implement it if this proposal accepted. >>>>>>>>>> >>>>>>>>>> [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT >>>>>>>>>> (6.0 Traditional PKWARE Encryption) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Yuji >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>> > From Roger.Riggs at Oracle.com Mon Dec 21 15:40:49 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 10:40:49 -0500 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' Message-ID: <56781D81.2080705@Oracle.com> Please review this test fix to allow the test to pass even if the OS provided commandline information is truncated and does not include the full command. It appears on Solaris when the path to the java command is longer than 80 chars. webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ Issue: https://bugs.openjdk.java.net/browse/JDK-8136597 Thanks, Roger From jason_mehrens at hotmail.com Mon Dec 21 15:48:58 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 21 Dec 2015 15:48:58 +0000 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677CE23.9010509@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677CA7D.5050101@redhat.com>,<5677CE23.9010509@oracle.com> Message-ID: So for C2 it doesn't matter. From what I can tell using javap, the xor generates the fewest number of bytecode operations. Not that this breaks the bank but, one would think that fewer bytecodes would help C1. Jason ________________________________________ From: core-libs-dev on behalf of Aleksey Shipilev Sent: Monday, December 21, 2015 4:02 AM To: Andrew Haley; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base On 12/21/2015 12:46 PM, Andrew Haley wrote: >> See: "Speed-kings of inverting booleans" at >> http://www.javaspecialists.eu/archive/Issue042.html > > That's from 2002, and not valid any more. Maybe not valid even back > then. It is not valid today, I've checked a while ago: http://cr.openjdk.java.net/~shade/scratch/BooleanNegate.java -Aleksey From joe.darcy at oracle.com Mon Dec 21 15:58:11 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Dec 2015 07:58:11 -0800 Subject: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing In-Reply-To: <567785AC.1010808@oracle.com> References: <567785AC.1010808@oracle.com> Message-ID: <56782193.5000400@oracle.com> Looks fine Amy; thanks, -Joe On 12/20/2015 8:53 PM, Amy Lu wrote: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/tools/jstatd/TestJstatdServer.java > > Above tests are known to fail intermittently, this patch is to mark > the test accordingly with keyword 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8145869 > webrev: http://cr.openjdk.java.net/~amlu/8145869/webrev.00/ > > Thanks, > Amy > > --- old/test/sun/management/jmxremote/startstop/JMXStartStopTest.java > 2015-12-21 12:41:00.000000000 +0800 > +++ new/test/sun/management/jmxremote/startstop/JMXStartStopTest.java > 2015-12-21 12:41:00.000000000 +0800 > @@ -58,7 +58,7 @@ > * @run main/othervm/timeout=600 -XX:+UsePerfData JMXStartStopTest > * @summary Makes sure that enabling/disabling the management agent > through JCMD > * achieves the desired results > - * @key randomness > + * @key randomness intermittent > */ > public class JMXStartStopTest { > private static final String TEST_APP_NAME = "TestApp"; > --- old/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 > 12:41:01.000000000 +0800 > +++ new/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 > 12:41:01.000000000 +0800 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 4990825 > + * @key intermittent > * @library /lib/testlibrary > * @modules java.management > * @build jdk.testlibrary.* JstatdTest JstatGCUtilParser > > From chris.hegarty at oracle.com Mon Dec 21 16:09:21 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Dec 2015 16:09:21 +0000 Subject: RFR [9] Move sun.misc math support classes to jdk.internal.math Message-ID: <56782431.7070504@oracle.com> There are 5 "math" related classes in the sun.misc package, DoubleConsts, FDBigInteger, FloatConsts, FloatingDecimal, and FormattedFloatingDecimal. They provide support for various standard constants, and conversation/formatting utilities, etc. They are used by the JDK in a few public packages, java.lang, java.math, java.text, and java.util, as well as in some 2d code. No usages have been found outside the JDK. Rather than move these classes to a public namespace, and access them through a shared secret ( or other such mechanism ), I think it makes sense for them to be co-located in their own internal package, jdk.internal.math ( open to other suggestions on the name ), rather than jdk.internal.misc. Webrev: http://cr.openjdk.java.net/~chegar/sun.misc_Math/ -Chris. P.S. this change has been prompted by preparatory cleanup work for JEP 260, JDK-8132928. From claes.redestad at oracle.com Mon Dec 21 16:10:46 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 17:10:46 +0100 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' In-Reply-To: <56781D81.2080705@Oracle.com> References: <56781D81.2080705@Oracle.com> Message-ID: <56782486.3040209@oracle.com> Hi, On 2015-12-21 16:40, Roger Riggs wrote: > Please review this test fix to allow the test to pass even if the OS > provided commandline information is truncated and does not include the > full command. It appears on Solaris when the path to the java command > is longer than 80 chars. > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ this looks OK as a fix to the Solaris issue, but it seems fragile since it'd likely break if you ran the test from a directory containing spaces. If we only do the space-check if we first fail to find java/java.exe in the commandLine we avoid this fragility: // calculate position of java int pos = commandLine.indexOf(javaExe); if (pos == -1) { pos = commandLine.indexOf(' '); if (pos != -1) { pos = pos - javaExe.length(); } } if (pos != 0) { Assert... Thanks! /Claes > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8136597 > > Thanks, Roger > From brian.burkhalter at oracle.com Mon Dec 21 16:13:53 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 21 Dec 2015 08:13:53 -0800 Subject: RFR [9] Move sun.misc math support classes to jdk.internal.math In-Reply-To: <56782431.7070504@oracle.com> References: <56782431.7070504@oracle.com> Message-ID: <607A247C-7E4A-4519-BE1D-93E9E856D75B@oracle.com> Sounds reasonable. Either jdk.internal.math or com.sun.math. Brian On Dec 21, 2015, at 8:09 AM, Chris Hegarty wrote: > I think it makes > sense for them to be co-located in their own internal package, > jdk.internal.math ( open to other suggestions on the name ), rather > than jdk.internal.misc. From joe.darcy at oracle.com Mon Dec 21 16:18:56 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Dec 2015 08:18:56 -0800 Subject: RFR [9] Move sun.misc math support classes to jdk.internal.math In-Reply-To: <56782431.7070504@oracle.com> References: <56782431.7070504@oracle.com> Message-ID: <56782670.4010804@oracle.com> Looks fine; thanks, -Joe On 12/21/2015 8:09 AM, Chris Hegarty wrote: > There are 5 "math" related classes in the sun.misc package, > DoubleConsts, FDBigInteger, FloatConsts, FloatingDecimal, and > FormattedFloatingDecimal. They provide support for various standard > constants, and conversation/formatting utilities, etc. They are used > by the JDK in a few public packages, java.lang, java.math, java.text, > and java.util, as well as in some 2d code. No usages have been found > outside the JDK. > > Rather than move these classes to a public namespace, and access them > through a shared secret ( or other such mechanism ), I think it makes > sense for them to be co-located in their own internal package, > jdk.internal.math ( open to other suggestions on the name ), rather > than jdk.internal.misc. > > Webrev: > http://cr.openjdk.java.net/~chegar/sun.misc_Math/ > > -Chris. > > P.S. this change has been prompted by preparatory cleanup work for > JEP 260, JDK-8132928. From Roger.Riggs at Oracle.com Mon Dec 21 16:21:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 11:21:26 -0500 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' In-Reply-To: <56782486.3040209@oracle.com> References: <56781D81.2080705@Oracle.com> <56782486.3040209@oracle.com> Message-ID: <56782706.6050506@Oracle.com> Hi Claes, I considered that, but it might be that the command line contained 'java' in the path name (not at the end) or that the truncation occurred just after 'java' in the pathname. With the possibility of truncation, there may be no reliable test at all and it should be removed. Roger On 12/21/2015 11:10 AM, Claes Redestad wrote: > Hi, > > On 2015-12-21 16:40, Roger Riggs wrote: >> Please review this test fix to allow the test to pass even if the OS >> provided commandline information is truncated and does not include >> the full command. It appears on Solaris when the path to the java >> command is longer than 80 chars. >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ > > this looks OK as a fix to the Solaris issue, but it seems fragile > since it'd likely break if you ran the test from a directory > containing spaces. If we only do the space-check if we first fail to > find java/java.exe in the commandLine we avoid this fragility: > > // calculate position of java > int pos = commandLine.indexOf(javaExe); > if (pos == -1) { > pos = commandLine.indexOf(' '); > if (pos != -1) { > pos = pos - javaExe.length(); > } > } > > if (pos != 0) { > Assert... > > Thanks! > > /Claes > > >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8136597 >> >> Thanks, Roger >> > From claes.redestad at oracle.com Mon Dec 21 16:25:59 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 17:25:59 +0100 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' In-Reply-To: <56782706.6050506@Oracle.com> References: <56781D81.2080705@Oracle.com> <56782486.3040209@oracle.com> <56782706.6050506@Oracle.com> Message-ID: <56782817.1090701@oracle.com> On 2015-12-21 17:21, Roger Riggs wrote: > Hi Claes, > > I considered that, but it might be that the command line contained > 'java' in the path name (not at the end) > or that the truncation occurred just after 'java' in the pathname. > > With the possibility of truncation, there may be no reliable test at > all and it should be removed. Perhaps better then to simply exclude platforms where truncation is a known problem from the test? if (!Platform.isSolaris() && !Platform.isAix() && ... /Claes > > Roger From claes.redestad at oracle.com Mon Dec 21 17:13:34 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 18:13:34 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677CA7D.5050101@redhat.com>, <5677CE23.9010509@oracle.com> Message-ID: <5678333E.2090805@oracle.com> Sure, rerunning with -XX:TieredStopAtLevel=1 there's evidently a very small overhead of return !falseValue over return trueValue: DefaultInitBench.trueWithFalseValue avgt 15 5.482 ? 0.077 ns/op DefaultInitBench.trueWithTrueValue avgt 15 5.147 ? 0.037 ns/op I prefer to keep the patch as-is. /Claes On 2015-12-21 16:48, Jason Mehrens wrote: > So for C2 it doesn't matter. From what I can tell using javap, the xor generates the fewest number of bytecode operations. Not that this breaks the bank but, one would think that fewer bytecodes would help C1. > > Jason From sundararajan.athijegannathan at oracle.com Mon Dec 21 17:44:05 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 21 Dec 2015 23:14:05 +0530 Subject: RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows Message-ID: <56783A65.60405@oracle.com> Line termination issue in an "expected output" file. Ran dos2unix on the expected output file on Windows. Verified by jtreg run is fine on Windows and Ubuntu Linux. Please review. You won't see anything on webrev as it ignores whitespaces. The following is the patch file: http://cr.openjdk.java.net/~sundar/8145909/webrev.00/jdk.patch Thanks, -Sundar From Roger.Riggs at Oracle.com Mon Dec 21 17:46:04 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 12:46:04 -0500 Subject: RFR:JDK-8145166 : Duration.toString violates specification In-Reply-To: <56755F8F.8020406@oracle.com> References: <56755F8F.8020406@oracle.com> Message-ID: <56783ADC.7070307@Oracle.com> Hi Nadeesh, Looks fine. I can integrate it tomorrow. Thanks, Roger On 12/19/2015 8:45 AM, nadeesh tv wrote: > Hi all, > > Please review > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8145166 > > > Issue - Duration.toString violates specification for Durations which > have value in the range -59 to -60, -119 to -120 seconds etc. > > webrev - http://cr.openjdk.java.net/~ntv/8145166/webrev.00/ > > -- > Thanks and Regards, > Nadeesh TV > From joe.darcy at oracle.com Mon Dec 21 18:14:04 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Dec 2015 10:14:04 -0800 Subject: RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows In-Reply-To: <56783A65.60405@oracle.com> References: <56783A65.60405@oracle.com> Message-ID: <5678416C.2080202@oracle.com> Looks fine Sundar; thanks, -Joe On 12/21/2015 9:44 AM, Sundararajan Athijegannathan wrote: > Line termination issue in an "expected output" file. Ran dos2unix on > the expected output file on Windows. Verified by jtreg run is fine on > Windows and Ubuntu Linux. Please review. > > You won't see anything on webrev as it ignores whitespaces. The > following is the patch file: > > http://cr.openjdk.java.net/~sundar/8145909/webrev.00/jdk.patch > > Thanks, > -Sundar From Roger.Riggs at Oracle.com Mon Dec 21 18:52:45 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 13:52:45 -0500 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' In-Reply-To: <56782817.1090701@oracle.com> References: <56781D81.2080705@Oracle.com> <56782486.3040209@oracle.com> <56782706.6050506@Oracle.com> <56782817.1090701@oracle.com> Message-ID: <56784A7D.1080308@Oracle.com> Hi Claes, The commandline() should be longer than the command(); if not then it has been truncated and the test should be skipped. Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ Roger On 12/21/2015 11:25 AM, Claes Redestad wrote: > > On 2015-12-21 17:21, Roger Riggs wrote: >> Hi Claes, >> >> I considered that, but it might be that the command line contained >> 'java' in the path name (not at the end) >> or that the truncation occurred just after 'java' in the pathname. >> >> With the possibility of truncation, there may be no reliable test at >> all and it should be removed. > > Perhaps better then to simply exclude platforms where truncation is a > known problem from the test? if (!Platform.isSolaris() && > !Platform.isAix() && ... > > /Claes > >> >> Roger > From scolebourne at joda.org Mon Dec 21 18:53:24 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 21 Dec 2015 18:53:24 +0000 Subject: RFR:JDK-8145166 : Duration.toString violates specification In-Reply-To: <56755F8F.8020406@oracle.com> References: <56755F8F.8020406@oracle.com> Message-ID: Looks good to me. thanks Stephen On 19 December 2015 at 13:45, nadeesh tv wrote: > Hi all, > > Please review > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8145166 > > Issue - Duration.toString violates specification for Durations which have > value in the range -59 to -60, -119 to -120 seconds etc. > > webrev - http://cr.openjdk.java.net/~ntv/8145166/webrev.00/ > > -- > Thanks and Regards, > Nadeesh TV > From claes.redestad at oracle.com Mon Dec 21 18:57:08 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 19:57:08 +0100 Subject: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java' In-Reply-To: <56784A7D.1080308@Oracle.com> References: <56781D81.2080705@Oracle.com> <56782486.3040209@oracle.com> <56782706.6050506@Oracle.com> <56782817.1090701@oracle.com> <56784A7D.1080308@Oracle.com> Message-ID: <56784B84.7000406@oracle.com> On 2015-12-21 19:52, Roger Riggs wrote: > Hi Claes, > > The commandline() should be longer than the command(); if not then it > has been truncated > and the test should be skipped. > > Updated the webrev in place. > http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ +1 /Claes From scolebourne at joda.org Mon Dec 21 19:00:20 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 21 Dec 2015 19:00:20 +0000 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <5672FB62.9090608@oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> <5672FB62.9090608@oracle.com> Message-ID: The comment for the new LocalDate.EPOCH field should use 1970-01-01, not 1970-1-1. However, the code should omit the zeroes: Replace: LocalDate.of(1970, 01, 01) with LocalDate.of(1970, 1, 1) The new method should follow the documentation of the similar method on ChronoLocalDateTime: * This combines this local date with the specified time and offset to calculate the * epoch-second value, which is the number of elapsed seconds from 1970-01-01T00:00:00Z. * Instants on the time-line after the epoch are positive, earlier are negative. The same applies to the new method on LocalTime: * This combines this local time with the specified date and offset to calculate the * epoch-second value, which is the number of elapsed seconds from 1970-01-01T00:00:00Z. * Instants on the time-line after the epoch are positive, earlier are negative. The same applies to the new method on OffsetTime: * This combines this offset time with the specified date to calculate the * epoch-second value, which is the number of elapsed seconds from 1970-01-01T00:00:00Z. * Instants on the time-line after the epoch are positive, earlier are negative. The test cases look good. thanks Stephen On 17 December 2015 at 18:13, nadeesh tv wrote: > > Hi all, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ > > Thanks and Regards, > Nadeesh > > On 12/4/2015 3:56 AM, Stephen Colebourne wrote: >> >> In the interests of harmony and getting something in, I'll accept that. >> >> I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY >> >> Stephen >> >> >> >> On 3 December 2015 at 22:09, Roger Riggs wrote: >>> >>> Hi Sherman, >>> >>> It makes sense to me to provide the missing time/date as an explicit >>> parameter >>> for toEpochSeconds instead of assuming some constant. >>> >>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); >>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); >>> offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); >>> >>> We'll have to add the LocalDate.EPOCHDAY constant. >>> >>> It makes it a bit heavier weight to use but can still be optimized and >>> won't >>> create garbage. >>> >>> Roger >>> >>> >>> >>> On 12/01/2015 12:33 PM, Xueming Shen wrote: >>>> >>>> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>>>> >>>>> As Roger says, these new methods are about performance as well as >>>>> conversion. >>>>> >>>>> While I fully acknowledge the time methods make an assumption, it is >>>>> not a crazy one, after all 1970-01-01 is just zero. >>>>> >>>>> Key I think is it allows: >>>>> long epochSecs = date.toEpochSeconds(offset) + >>>>> time.toEpochSeconds(offset); >>>>> to efficiently merge two objects without garbage. >>>> >>>> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >>>> approach >>>> >>>> LocalDate date = ... >>>> LocalDate time = ... >>>> ZoneOffset offset = ... >>>> >>>> ==> long spochSecs = LocalDateTime.of(date, >>>> time).toEpochSeconds(offset); >>>> >>>> we are adding APIs to provide a "fastpath" with the special assumption >>>> that the LocalDate "date" >>>> here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) >>>> and the LocalTime "time" >>>> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to >>>> let >>>> the third party "libraries" >>>> to fool the basic date/time abstract in java.time package, simply to >>>> avoid creating the garbage >>>> middle man, localDateTime? it really does not sound right to me. >>>> >>>> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >>>> epoch seconds in their >>>> libraries, they really SHOULD think hard about the conversion and make >>>> it >>>> right (it should not >>>> be encouraged to use these classes LocalDate, LocalTime and Offset >>>> without >>>> even understand >>>> what these classes are). But if we really have to provide such fastpath, >>>> personally I think it might >>>> be better either to provide these "utility/convenient" methods in a >>>> "utilities" class, or with an >>>> explicit date/time parameters (instead of the false assumption) for the >>>> missing date/time piece, >>>> such as >>>> >>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >>>> >>>> Sherman >>>> >>>> >>>>> It also means that no-one has to think hard about the conversion, as >>>>> it is just there. It tends to be when people try to work this stuff >>>>> out for themselves that they get it wrong. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 1 December 2015 at 14:21, Roger Riggs >>>>> wrote: >>>>>> >>>>>> Hi Sherman, >>>>>> >>>>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>>>> >>>>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>>>> >>>>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>>>> largest number of votes on SO: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>>>> The proposed method is designed to make the conversion easier. It >>>>>>>> also >>>>>>>> plugs an obvious gap in the API. >>>>>>>> >>>>>>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>>>>>> having them would result in inconsistency between the various >>>>>>>> classes. >>>>>>>> We've already added factory methods to LocalTime for Java 9, these >>>>>>>> are >>>>>>>> just the other half of the picture. >>>>>>>> >>>>>>> I'm not sure I understand the idea of "the proposed method is >>>>>>> designed >>>>>>> to >>>>>>> make the conversion easier", as the SO is mainly about >>>>>>> j.u.Date->LocalDate, >>>>>>> not the other way around, from LocalDate -> j.u.Date. >>>>>> >>>>>> I think the issue is about *other* libraries that manipulate time via >>>>>> epochSeconds >>>>>> not about j.u.Date conversions. The concern was about performance and >>>>>> creating garbage along the way. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>>> As I said in the previous email, it might be "common" to use the >>>>>>> j.u.Date >>>>>>> to >>>>>>> abstract a "local date" and/or a "local time" (no other choice) >>>>>>> before >>>>>>> java.time, >>>>>>> and now there is the need to provide a migration path from those >>>>>>> "local >>>>>>> date/ >>>>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>>>> date/time >>>>>>> type to the "old" j.u.Date should not be encouraged (guess this is >>>>>>> also >>>>>>> the >>>>>>> consensus we agreed on back to jsr203). >>>>>>> >>>>>>> What are the "factory methods" you are referring to here? >>>>>>> JDK-8133079, >>>>>>> The >>>>>>> LocalDate/LocalTime.ofInstant()? >>>>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>>>> >>>>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>>>> "super-set" >>>>>>> of >>>>>>> date/time to a "sub-set", without any assumption of "default value", >>>>>>> it >>>>>>> is >>>>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>>>> "small" >>>>>>> improvement >>>>>>> >>>>>>> from| >>>>>>> Date input = new Date(); >>>>>>> LocalDatedate >>>>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>>>> >>>>>>> to >>>>>>> >>>>>>> |LocalDatedate >>>>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>>>> >>>>>>> The proposed pair toEpochSecond() however is doing the other way >>>>>>> around >>>>>>> and >>>>>>> with an unusual assumption of the missing date/time piece to a >>>>>>> "default >>>>>>> value" >>>>>>> (midnight, the epoch day). >>>>>>> >>>>>>> personally I think >>>>>>> >>>>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>>>> >>>>>>> is clean and good enough to help this backward conversion (with the >>>>>>> addition >>>>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>>>>>> remove that LocalDateTime middle man, with some arrangement. >>>>>>> >>>>>>> -Sherman >>>>>>> >>>>>>>> Note that these methods are specifically not referencing >>>>>>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>>>>>> form here, and still widely used. >>>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 30 November 2015 at 19:36, Xueming Shen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>>>> >>>>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>>>> These >>>>>>>>>> methods aim to provide a simpler and faster approach, particularly >>>>>>>>>> for >>>>>>>>>> cases converting to/from java.util.Date. >>>>>>>>> >>>>>>>>> Can you be a little more specific on this one? We now have >>>>>>>>> Instance<=> >>>>>>>>> Date, >>>>>>>>> and considerably we might add LocalDateTime<=> Date with an offset, >>>>>>>>> if >>>>>>>>> really >>>>>>>>> really desired (for performance? to save a Instant object as the >>>>>>>>> bridge?). >>>>>>>>> But I'm >>>>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>>>> epoch >>>>>>>>> seconds >>>>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>>>> >>>>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>>>> >>>>>>>>> and uses the converted j.u.Date to represent a local date (date >>>>>>>>> with >>>>>>>>> time >>>>>>>>> part to >>>>>>>>> be 0) and/or the local time (with year/month/day to be epoch time) >>>>>>>>> in >>>>>>>>> the >>>>>>>>> "old" >>>>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>>>> abstract >>>>>>>>> the >>>>>>>>> "local >>>>>>>>> date" and "local time"? >>>>>>>>> >>>>>>>>> I think we agreed back to JSR310 that we don't try to add such kind >>>>>>>>> of >>>>>>>>> "bridge/ >>>>>>>>> convenient/utility" methods into the new java.time package, but >>>>>>>>> only >>>>>>>>> in >>>>>>>>> the >>>>>>>>> old date/calendar classes, if really needed. So if these methods >>>>>>>>> are >>>>>>>>> only to >>>>>>>>> help >>>>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>>>> java.time >>>>>>>>> might not be the best place for them? >>>>>>>>> >>>>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>>>> commonly used in many codebases. >>>>>>>>>> >>>>>>>>> I'm not sure about that, especially the "natural" part. It might be >>>>>>>>> "common" >>>>>>>>> in >>>>>>>>> the old days if you only have j.u.Date", and might be forced to use >>>>>>>>> 1970-01-01 >>>>>>>>> to fill in the "date" part even when you are really only interested >>>>>>>>> in >>>>>>>>> "time" part >>>>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>>>>>>>> now >>>>>>>>> we >>>>>>>>> have >>>>>>>>> separate abstract for these different need, I don't see the common >>>>>>>>> need >>>>>>>>> of >>>>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>>>> misunderstood >>>>>>>>> something here. >>>>>>>>> >>>>>>>>> -Sherman >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Stephen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 30 November 2015 at 18:15, Xueming >>>>>>>>>> Shen >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> While it is kinda understandable to have >>>>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of >>>>>>>>>>> the >>>>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>>>> Local/OffsetTime >>>>>>>>>>> to have two public methods with the assumption of the "date" is >>>>>>>>>>> at >>>>>>>>>>> epoch >>>>>>>>>>> year/month/day. What's the use case/scenario for these two >>>>>>>>>>> proposed >>>>>>>>>>> methods? >>>>>>>>>>> >>>>>>>>>>> -Sherman >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>>>> >>>>>>>>>>>> The method Javadoc (specs) for each of the three new methods >>>>>>>>>>>> needs >>>>>>>>>>>> to >>>>>>>>>>>> be enhanced. >>>>>>>>>>>> >>>>>>>>>>>> For the date ones it needs to say >>>>>>>>>>>> "The resulting date will have a time component of midnight at >>>>>>>>>>>> the >>>>>>>>>>>> start of the day." >>>>>>>>>>>> >>>>>>>>>>>> For the time ones it needs to say >>>>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>>>> >>>>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>>>> indented >>>>>>>>>>>> correctly. >>>>>>>>>>>> >>>>>>>>>>>> Otherwise looks fine, >>>>>>>>>>>> thanks >>>>>>>>>>>> Stephen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>> >>>>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>>>> >>>>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>>>> >>>>>>>>>>>>> webrev -http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>>>> Nadeesh TV >>>>>>>>>> >>>>>>>>>> > > > -- > Thanks and Regards, > Nadeesh TV > From scolebourne at joda.org Mon Dec 21 19:05:53 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 21 Dec 2015 19:05:53 +0000 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: <566B2CFE.3030802@Oracle.com> References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> Message-ID: On 11 December 2015 at 20:07, Roger Riggs wrote: > Stephen, can you confirm that the added text and test in DateTimeFormatter > is not a specification change? I thought I replied to this earlier, but maybe not. This is not a change to the spec, but a clarification to add a clear spec in an area where clarity was missed. One could argue that some aspects of this behaviour is implicit from other parts of the API however it would probably be tricky to tie it up completely. I have no problem with not porting the spec addition to JDK 8, the but fix really needs to go back. Not being able to round trip a ZonedDateTime is really serious, and I remain amazed that this issue managed to slip through. Stephen > Our processes have a bit more to do if it is a spec change and it would > limit the backport to JDK 8. > > This bug fix will cause an existing TCK/JCK test to fail but that is > considered also a bug and is fixed. > test/java/time/tck/java/time/TCKZonedDateTime.java > > Ramanand, some comments on the new test: > - The 'private' qualifier on the tests and data providers is not used in > the current tests and > is not consistently present in the new one. > Since it has little/no function, the tests would be a bit cleaner > without it. > > - Typically, test that have data dependencies (such as the timezone data) > cannot be used for > compatibility to the specification, but the data is stable and it seems > unavoidable in this case. > > - Are all of the data cases necessary to validate the specification? > Redundant cases extend the testing time without adding more confidence to > the quality. > > Thanks, Roger > > > On 12/10/2015 11:00 AM, Stephen Colebourne wrote: >> >> I believe this is suitable for committing, thanks, other reviews welcome! >> Stephen >> >> >> >> On 10 December 2015 at 15:36, Ramanand Patil >> wrote: >>> >>> Hi all, >>> >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >>> >>> I have modified the fix and test cases as per inputs given by Stephen. >>> Also, I have added the javadocs changes in this patch which were proposed in >>> the bug. >>> >>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >>> >>> >>> Regards, >>> Ramanand. >>> >>> >>> -----Original Message----- >>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>> Sent: Wednesday, December 09, 2015 4:46 PM >>> To: core-libs-dev >>> Cc: i18n-dev >>> Subject: Re: Review request for JDK-8066982: >>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition >>> >>> The logic looks fine. >>> >>> In the main code, this part >>> .getLong(INSTANT_SECONDS); >>> can be replaced with >>> .toEpochSecond(); >>> which will be slightly faster. >>> >>> In the test case, this part >>> .plus(15, ChronoUnit.MINUTES); >>> can be replaced with >>> .plusMinutes(15) >>> >>> And >>> .with(ChronoField.OFFSET_SECONDS, >>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >>> can be replaced with >>> .with(ZoneOffset.of(offsetSamples[j])) >>> >>> In addition to the looping tests, I'd like to see the examples from the >>> bug report as test cases. Those tests would be simple to follow and explain, >>> whereas the looping tests are a little hard to follow. >>> >>> thanks for fixing this >>> Stephen >>> >>> >>> >>> On 9 December 2015 at 07:44, Ramanand Patil >>> wrote: >>>> >>>> HI all, >>>> >>>> >>>> >>>> Please review a fix for Bug - HYPERLINK >>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>>> >>>> >>>> >>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone >>>> offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime >>>> (different offset). This error starts exactly at the transition time >>>> (included) and ends one hour later (excluded). >>>> >>>> >>>> >>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>>> >>>> >>>> >>>> One existing test case in TCKZonedDateTime.java is also modified, >>>> because - when offset is invalid the local time is changed to make the >>>> result valid. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ramanand. > > From jonathan.gibbons at oracle.com Mon Dec 21 19:16:26 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 21 Dec 2015 11:16:26 -0800 Subject: RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows Message-ID: <5678500A.6010001@oracle.com> Hi Sundar, Yes, we talked about this offline. The fix looks good. -- Jon > Line termination issue in an "expected output" file. Ran dos2unix on the > expected output file on Windows. Verified by jtreg run is fine on > Windows and Ubuntu Linux. Please review. > > You won't see anything on webrev as it ignores whitespaces. The > following is the patch file: > > http://cr.openjdk.java.net/~sundar/8145909/webrev.00/jdk.patch > > Thanks, > -Sundar From claes.redestad at oracle.com Mon Dec 21 19:58:19 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Dec 2015 20:58:19 +0100 Subject: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base In-Reply-To: <5677CF2B.6010607@oracle.com> References: <567556AE.3080301@oracle.com> <5676E570.4080208@oracle.com> <5677345E.50503@oracle.com> <5677CF2B.6010607@oracle.com> Message-ID: <567859DB.4060206@oracle.com> Thanks for all the reviews! Pushed. /Claes On 2015-12-21 11:06, Chris Hegarty wrote: > Thanks for doing this Claes. The changes look good to me. > > -Chris. > > On 20/12/15 23:06, Claes Redestad wrote: >> Hi all, >> >> On 2015-12-20 20:43, Ulf wrote: >>> Hi Claes, >>> >>> I had a very short look and found in j.l.Thread: >>> 211 * Java thread status for tools, 0 indicate thread 'not yet >>> started' >>> I guess you meant: >>> 211 * Java thread status for tools; 0 indicates: thread 'not yet >>> started'. >>> >>> -Ulf >> >> /* >> * Java thread status for tools, default indicates thread 'not yet >> started' >> */ >> >> OK? >> >> On 2015-12-20 21:02, Jason Mehrens wrote: >>> Claes, >>> >>> For the cases where boolean was being assigned to 'true' (ASSCI and >>> FileLockImpl) does it hurt performance since the accessor methods will >>> now include a branch at the bytecode level? See: "Speed-kings of >>> inverting booleans" at >>> http://www.javaspecialists.eu/archive/Issue042.html >>> >>> Jason >> >> I don't think this is an issue any more: >> >> public volatile boolean trueValue = true; >> public volatile boolean falseValue = false; >> >> @Benchmark >> @CompilerControl(CompilerControl.Mode.DONT_INLINE) >> public boolean trueWithFalseValue() throws Exception { >> return !falseValue; >> } >> >> @Benchmark >> @CompilerControl(CompilerControl.Mode.DONT_INLINE) >> public boolean trueWithTrueValue() throws Exception { >> return trueValue; >> } >> >> DefaultInitBench.trueWithFalseValue avgt 25 4.538 ? 0.353 ns/op >> DefaultInitBench.trueWithTrueValue avgt 25 4.726 ? 0.466 ns/op >> >> On 2015-12-20 20:33, Joel Borggr?n-Franck wrote: >>> Hi Claes, >>> >>> src/java.base/share/classes/java/lang/reflect/Parameter.java >>> src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java >>> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java >>> >>> >>> >>> looks fine to me. >>> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> is fine to but isn't >>> >>> enumConstants = constants = temporatyConstants; >>> >>> slightly more idiomatic than >>> >>> - enumConstants = temporaryConstants; >>> + constants = temporaryConstants; >>> + enumConstants = constants; >> >> I'm fine either way; updated in-place in this and a few other places. >> >> Thanks! >> >> /Claes >> >>> On Sun, Dec 20, 2015 at 6:29 PM, Claes Redestad >>> wrote: >>>> Hi, >>>> >>>> the changes to java.net.URI stood out as a bit too intrusive for a >>>> cleanup >>>> like this, and there's precious little measurable benefit. I >>>> decided to >>>> break out those to a separate RFE and simplified this patch: >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8145680/webrev.02 >>>> >>>> /Claes >>>> >>>> >>>> On 2015-12-19 14:07, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> initializing volatile fields to their default value has a well-known >>>>> performance penalty, and removing these should typically be safe. >>>>> This patch >>>>> addresses java.base. >>>>> >>>>> There are however some corner cases that we need to check for, see >>>>> examples and discussion in >>>>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >>>>> >>>>> >>>>> >>>>> When meticulously going through and checking each usage for odd >>>>> pattern >>>>> like this I accidentally did a bit of extra cleanup, mostly >>>>> addressing a >>>>> number of cases where the volatile field was being read twice. Sorry! >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145680 >>>>> >> From bob.vandette at oracle.com Mon Dec 21 20:18:54 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 21 Dec 2015 15:18:54 -0500 Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE Message-ID: http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ Please review the following fixes that were required to complete the initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family and not specific architecture version. This is the way x86/x86_x64 is also handled. 2. Add the SocketOption and UnixConstant template files into the JDK repo. These are required for cross compilation builds since the genSocketOption and genUnixConstants programs cannot be run on the build system. 3. Add a macosx directory for iOS build in the NIO makefile. Exclude the UTIFileTypeDetector.c file from the iOS build since it is dependent on a Framework that is not available in iOS. We probably should remove the entire MacOSXFileSystemProvider set of classes. Currently the default provider for iOS is Bsd. Bob Vandette From Roger.Riggs at Oracle.com Mon Dec 21 20:53:08 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 15:53:08 -0500 Subject: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition In-Reply-To: References: <75b86334-1d29-4889-b9ae-e2815462d711@default> <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default> <566B2CFE.3030802@Oracle.com> Message-ID: <567866B4.5090200@Oracle.com> Hi Stephen, Confirmed, the reviews are in progress to update the spec for 9 and fix the implementation in 8. Thanks, Roger On 12/21/2015 2:05 PM, Stephen Colebourne wrote: > On 11 December 2015 at 20:07, Roger Riggs wrote: >> Stephen, can you confirm that the added text and test in DateTimeFormatter >> is not a specification change? > I thought I replied to this earlier, but maybe not. > > This is not a change to the spec, but a clarification to add a clear > spec in an area where clarity was missed. One could argue that some > aspects of this behaviour is implicit from other parts of the API > however it would probably be tricky to tie it up completely. > > I have no problem with not porting the spec addition to JDK 8, the but > fix really needs to go back. Not being able to round trip a > ZonedDateTime is really serious, and I remain amazed that this issue > managed to slip through. > > Stephen > > >> Our processes have a bit more to do if it is a spec change and it would >> limit the backport to JDK 8. >> >> This bug fix will cause an existing TCK/JCK test to fail but that is >> considered also a bug and is fixed. >> test/java/time/tck/java/time/TCKZonedDateTime.java >> >> Ramanand, some comments on the new test: >> - The 'private' qualifier on the tests and data providers is not used in >> the current tests and >> is not consistently present in the new one. >> Since it has little/no function, the tests would be a bit cleaner >> without it. >> >> - Typically, test that have data dependencies (such as the timezone data) >> cannot be used for >> compatibility to the specification, but the data is stable and it seems >> unavoidable in this case. >> >> - Are all of the data cases necessary to validate the specification? >> Redundant cases extend the testing time without adding more confidence to >> the quality. >> >> Thanks, Roger >> >> >> On 12/10/2015 11:00 AM, Stephen Colebourne wrote: >>> I believe this is suitable for committing, thanks, other reviews welcome! >>> Stephen >>> >>> >>> >>> On 10 December 2015 at 15:36, Ramanand Patil >>> wrote: >>>> Hi all, >>>> >>>> Please review the updated webrev: >>>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ >>>> >>>> I have modified the fix and test cases as per inputs given by Stephen. >>>> Also, I have added the javadocs changes in this patch which were proposed in >>>> the bug. >>>> >>>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982 >>>> >>>> >>>> Regards, >>>> Ramanand. >>>> >>>> >>>> -----Original Message----- >>>> From: Stephen Colebourne [mailto:scolebourne at joda.org] >>>> Sent: Wednesday, December 09, 2015 4:46 PM >>>> To: core-libs-dev >>>> Cc: i18n-dev >>>> Subject: Re: Review request for JDK-8066982: >>>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition >>>> >>>> The logic looks fine. >>>> >>>> In the main code, this part >>>> .getLong(INSTANT_SECONDS); >>>> can be replaced with >>>> .toEpochSecond(); >>>> which will be slightly faster. >>>> >>>> In the test case, this part >>>> .plus(15, ChronoUnit.MINUTES); >>>> can be replaced with >>>> .plusMinutes(15) >>>> >>>> And >>>> .with(ChronoField.OFFSET_SECONDS, >>>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds()) >>>> can be replaced with >>>> .with(ZoneOffset.of(offsetSamples[j])) >>>> >>>> In addition to the looping tests, I'd like to see the examples from the >>>> bug report as test cases. Those tests would be simple to follow and explain, >>>> whereas the looping tests are a little hard to follow. >>>> >>>> thanks for fixing this >>>> Stephen >>>> >>>> >>>> >>>> On 9 December 2015 at 07:44, Ramanand Patil >>>> wrote: >>>>> HI all, >>>>> >>>>> >>>>> >>>>> Please review a fix for Bug - HYPERLINK >>>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982 >>>>> >>>>> >>>>> >>>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone >>>>> offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime >>>>> (different offset). This error starts exactly at the transition time >>>>> (included) and ends one hour later (excluded). >>>>> >>>>> >>>>> >>>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ >>>>> >>>>> >>>>> >>>>> One existing test case in TCKZonedDateTime.java is also modified, >>>>> because - when offset is invalid the local time is changed to make the >>>>> result valid. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Ramanand. >> From Roger.Riggs at Oracle.com Mon Dec 21 21:35:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 21 Dec 2015 16:35:26 -0500 Subject: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty In-Reply-To: <56735284.6060203@oracle.com> References: <56735284.6060203@oracle.com> Message-ID: <5678709E.9040609@Oracle.com> Hi Joe, A few comments: InputSource: - Should the default method return true? The default method is only present to allow source compatibility with unknown subtypes. I would expect that without any specific implementation knowledge it would need to be false. All of the JDK provided Sources will implement isEmpty appropriately. - Editorial: "Empty means that there is no input available from this Source". - from the definition and implementation it seems that isEmpty will be true when a stream (streamSource) is positioned just before EOF. Is that intended? stream/StreamSource: - Does not need to check both sources; if the first source has any input, return false immediately. - the choice to return false when an IOException occurs seems odd; if reading throws an exception then it seems unlikely that any future read could work; and hence there is no more input. - Note also that you probably need separate try/catch handlers for the stream vs the reader. An exception from reading the inputStream should no preempt the reader. sax/InputSource: - ditto the comments above. In the test: - This test is duplicated: + "{new SAXSource(new InputSource(new StringReader("")))}, + {new SAXSource(new InputSource(new StringReader("")))}, Roger On 12/17/2015 7:25 PM, huizhe wang wrote: > Hi, > > Adding a convenient method isEmpty to javax.xml.transform.Source and > org.xml.sax.InputSource. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ > > Thanks, > Joe > From cushon at google.com Mon Dec 21 22:32:28 2015 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 21 Dec 2015 14:32:28 -0800 Subject: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class is not present Message-ID: If an annotation value is an array of class literals or enum constants, calling Class.getAnnotation() fails with ArrayStoreException if the element type is not found. This patch implements the proposed fix from the bug thread, which allows getAnnotation() to succeed and a TypeNotPresentException to be thrown from Annotation.value(). bug: https://bugs.openjdk.java.net/browse/JDK-7183985 The patch is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 7183985.patch Type: text/x-patch Size: 13219 bytes Desc: not available URL: From huizhe.wang at oracle.com Tue Dec 22 00:11:34 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 21 Dec 2015 16:11:34 -0800 Subject: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty In-Reply-To: <5678709E.9040609@Oracle.com> References: <56735284.6060203@oracle.com> <5678709E.9040609@Oracle.com> Message-ID: <56789536.8050102@oracle.com> Thanks Roger! On 12/21/2015 1:35 PM, Roger Riggs wrote: > Hi Joe, > > A few comments: > > InputSource: I assume you meant javax.xml.transform.Source (there was an error in Source's javadoc where the return statement referred to it as InputSource). > - Should the default method return true? The default method is only > present > to allow source compatibility with unknown subtypes. I would expect > that without > any specific implementation knowledge it would need to be false. > All of the JDK provided Sources will implement isEmpty appropriately. Changed to throw UOE now as Joe recommended. > > - Editorial: "Empty means that there is no input available from this > Source". Fixed. > > - from the definition and implementation it seems that isEmpty will > be true > when a stream (streamSource) is positioned just before EOF. Is > that intended? Yes. In general, a Source object shall be passed to a processor with input positioned at the beginning. If for some reason it's not, the Source object will not handle the situation. > > > stream/StreamSource: > - Does not need to check both sources; if the first source has any > input, return false immediately. Fixed. > > - the choice to return false when an IOException occurs seems odd; > if reading throws an exception then it seems unlikely that any > future read could work; > and hence there is no more input. It's true no future read would work. But since a Source object can be used in various situations where "empty" and failure to read are treated differently by the processor, the isEmpty method needs to abort its process, return false to indicate it's not empty, thus allow the processor to handle the error. I added a statement to the spec. > > - Note also that you probably need separate try/catch handlers for > the stream vs the reader. > An exception from reading the inputStream should no preempt the > reader. As discussed above, in case of error, isEmpty will abort its process and return false. > > sax/InputSource: > - ditto the comments above. > > In the test: > - This test is duplicated: > > + "{new SAXSource(new InputSource(new StringReader("")))}, > + {new SAXSource(new InputSource(new StringReader("")))}, Fixed. http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ Thanks, Joe > > > Roger > > > On 12/17/2015 7:25 PM, huizhe wang wrote: >> Hi, >> >> Adding a convenient method isEmpty to javax.xml.transform.Source and >> org.xml.sax.InputSource. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ >> >> Thanks, >> Joe >> > From erik.joelsson at oracle.com Tue Dec 22 07:38:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Dec 2015 08:38:14 +0100 Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE In-Reply-To: References: Message-ID: <5678FDE6.2030601@oracle.com> Looks good to me. /Erik On 2015-12-21 21:18, Bob Vandette wrote: > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ > > Please review the following fixes that were required to complete the > initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. > > 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to > ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family > and not specific architecture version. This is the way x86/x86_x64 is also handled. > > 2. Add the SocketOption and UnixConstant template files into the JDK repo. > These are required for cross compilation builds since the genSocketOption > and genUnixConstants programs cannot be run on the build system. > > 3. Add a macosx directory for iOS build in the NIO makefile. > Exclude the UTIFileTypeDetector.c file from the iOS build since it > is dependent on a Framework that is not available in iOS. We probably > should remove the entire MacOSXFileSystemProvider set of classes. > Currently the default provider for iOS is Bsd. > > Bob Vandette > From nadeesh.tv at oracle.com Tue Dec 22 07:59:27 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 22 Dec 2015 13:29:27 +0530 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> <5672FB62.9090608@oracle.com> Message-ID: <567902DF.6090501@oracle.com> Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8143413/webrev.04/ Changes : Included the changes suggested by Stephen Thanks and Regards, Nadeesh On 12/22/2015 12:30 AM, Stephen Colebourne wrote: > The comment for the new LocalDate.EPOCH field should use 1970-01-01, > not 1970-1-1. However, the code should omit the zeroes: > Replace: > LocalDate.of(1970, 01, 01) > with > LocalDate.of(1970, 1, 1) > > The new method should follow the documentation of the similar method > on ChronoLocalDateTime: > > * This combines this local date with the specified time and > offset to calculate the > * epoch-second value, which is the number of elapsed seconds from > 1970-01-01T00:00:00Z. > * Instants on the time-line after the epoch are positive, earlier > are negative. > > The same applies to the new method on LocalTime: > > * This combines this local time with the specified date and > offset to calculate the > * epoch-second value, which is the number of elapsed seconds from > 1970-01-01T00:00:00Z. > * Instants on the time-line after the epoch are positive, earlier > are negative. > > The same applies to the new method on OffsetTime: > > * This combines this offset time with the specified date to calculate the > * epoch-second value, which is the number of elapsed seconds from > 1970-01-01T00:00:00Z. > * Instants on the time-line after the epoch are positive, earlier > are negative. > > The test cases look good. > > thanks > Stephen > > > On 17 December 2015 at 18:13, nadeesh tv wrote: >> Hi all, >> >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ >> >> Thanks and Regards, >> Nadeesh >> >> On 12/4/2015 3:56 AM, Stephen Colebourne wrote: >>> In the interests of harmony and getting something in, I'll accept that. >>> >>> I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY >>> >>> Stephen >>> >>> >>> >>> On 3 December 2015 at 22:09, Roger Riggs wrote: >>>> Hi Sherman, >>>> >>>> It makes sense to me to provide the missing time/date as an explicit >>>> parameter >>>> for toEpochSeconds instead of assuming some constant. >>>> >>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); >>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); >>>> offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); >>>> >>>> We'll have to add the LocalDate.EPOCHDAY constant. >>>> >>>> It makes it a bit heavier weight to use but can still be optimized and >>>> won't >>>> create garbage. >>>> >>>> Roger >>>> >>>> >>>> >>>> On 12/01/2015 12:33 PM, Xueming Shen wrote: >>>>> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>>>>> As Roger says, these new methods are about performance as well as >>>>>> conversion. >>>>>> >>>>>> While I fully acknowledge the time methods make an assumption, it is >>>>>> not a crazy one, after all 1970-01-01 is just zero. >>>>>> >>>>>> Key I think is it allows: >>>>>> long epochSecs = date.toEpochSeconds(offset) + >>>>>> time.toEpochSeconds(offset); >>>>>> to efficiently merge two objects without garbage. >>>>> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >>>>> approach >>>>> >>>>> LocalDate date = ... >>>>> LocalDate time = ... >>>>> ZoneOffset offset = ... >>>>> >>>>> ==> long spochSecs = LocalDateTime.of(date, >>>>> time).toEpochSeconds(offset); >>>>> >>>>> we are adding APIs to provide a "fastpath" with the special assumption >>>>> that the LocalDate "date" >>>>> here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) >>>>> and the LocalTime "time" >>>>> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to >>>>> let >>>>> the third party "libraries" >>>>> to fool the basic date/time abstract in java.time package, simply to >>>>> avoid creating the garbage >>>>> middle man, localDateTime? it really does not sound right to me. >>>>> >>>>> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >>>>> epoch seconds in their >>>>> libraries, they really SHOULD think hard about the conversion and make >>>>> it >>>>> right (it should not >>>>> be encouraged to use these classes LocalDate, LocalTime and Offset >>>>> without >>>>> even understand >>>>> what these classes are). But if we really have to provide such fastpath, >>>>> personally I think it might >>>>> be better either to provide these "utility/convenient" methods in a >>>>> "utilities" class, or with an >>>>> explicit date/time parameters (instead of the false assumption) for the >>>>> missing date/time piece, >>>>> such as >>>>> >>>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >>>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >>>>> >>>>> Sherman >>>>> >>>>> >>>>>> It also means that no-one has to think hard about the conversion, as >>>>>> it is just there. It tends to be when people try to work this stuff >>>>>> out for themselves that they get it wrong. >>>>>> >>>>>> Stephen >>>>>> >>>>>> >>>>>> On 1 December 2015 at 14:21, Roger Riggs >>>>>> wrote: >>>>>>> Hi Sherman, >>>>>>> >>>>>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>>>>> largest number of votes on SO: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>>>>> The proposed method is designed to make the conversion easier. It >>>>>>>>> also >>>>>>>>> plugs an obvious gap in the API. >>>>>>>>> >>>>>>>>> While the LocalTime/OffsetTime methods are of lower importance, not >>>>>>>>> having them would result in inconsistency between the various >>>>>>>>> classes. >>>>>>>>> We've already added factory methods to LocalTime for Java 9, these >>>>>>>>> are >>>>>>>>> just the other half of the picture. >>>>>>>>> >>>>>>>> I'm not sure I understand the idea of "the proposed method is >>>>>>>> designed >>>>>>>> to >>>>>>>> make the conversion easier", as the SO is mainly about >>>>>>>> j.u.Date->LocalDate, >>>>>>>> not the other way around, from LocalDate -> j.u.Date. >>>>>>> I think the issue is about *other* libraries that manipulate time via >>>>>>> epochSeconds >>>>>>> not about j.u.Date conversions. The concern was about performance and >>>>>>> creating garbage along the way. >>>>>>> >>>>>>> Roger >>>>>>> >>>>>>> >>>>>>> >>>>>>>> As I said in the previous email, it might be "common" to use the >>>>>>>> j.u.Date >>>>>>>> to >>>>>>>> abstract a "local date" and/or a "local time" (no other choice) >>>>>>>> before >>>>>>>> java.time, >>>>>>>> and now there is the need to provide a migration path from those >>>>>>>> "local >>>>>>>> date/ >>>>>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>>>>> date/time >>>>>>>> type to the "old" j.u.Date should not be encouraged (guess this is >>>>>>>> also >>>>>>>> the >>>>>>>> consensus we agreed on back to jsr203). >>>>>>>> >>>>>>>> What are the "factory methods" you are referring to here? >>>>>>>> JDK-8133079, >>>>>>>> The >>>>>>>> LocalDate/LocalTime.ofInstant()? >>>>>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>>>>> >>>>>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>>>>> "super-set" >>>>>>>> of >>>>>>>> date/time to a "sub-set", without any assumption of "default value", >>>>>>>> it >>>>>>>> is >>>>>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>>>>> "small" >>>>>>>> improvement >>>>>>>> >>>>>>>> from| >>>>>>>> Date input = new Date(); >>>>>>>> LocalDatedate >>>>>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> |LocalDatedate >>>>>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>>>>> >>>>>>>> The proposed pair toEpochSecond() however is doing the other way >>>>>>>> around >>>>>>>> and >>>>>>>> with an unusual assumption of the missing date/time piece to a >>>>>>>> "default >>>>>>>> value" >>>>>>>> (midnight, the epoch day). >>>>>>>> >>>>>>>> personally I think >>>>>>>> >>>>>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>>>>> >>>>>>>> is clean and good enough to help this backward conversion (with the >>>>>>>> addition >>>>>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to >>>>>>>> remove that LocalDateTime middle man, with some arrangement. >>>>>>>> >>>>>>>> -Sherman >>>>>>>> >>>>>>>>> Note that these methods are specifically not referencing >>>>>>>>> java.util.Date itself. Epoch seconds is the appropriate intermediate >>>>>>>>> form here, and still widely used. >>>>>>>>> >>>>>>>>> Stephen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 30 November 2015 at 19:36, Xueming Shen >>>>>>>>> wrote: >>>>>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>>>>> These >>>>>>>>>>> methods aim to provide a simpler and faster approach, particularly >>>>>>>>>>> for >>>>>>>>>>> cases converting to/from java.util.Date. >>>>>>>>>> Can you be a little more specific on this one? We now have >>>>>>>>>> Instance<=> >>>>>>>>>> Date, >>>>>>>>>> and considerably we might add LocalDateTime<=> Date with an offset, >>>>>>>>>> if >>>>>>>>>> really >>>>>>>>>> really desired (for performance? to save a Instant object as the >>>>>>>>>> bridge?). >>>>>>>>>> But I'm >>>>>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>>>>> epoch >>>>>>>>>> seconds >>>>>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>>>>> >>>>>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>>>>> >>>>>>>>>> and uses the converted j.u.Date to represent a local date (date >>>>>>>>>> with >>>>>>>>>> time >>>>>>>>>> part to >>>>>>>>>> be 0) and/or the local time (with year/month/day to be epoch time) >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> "old" >>>>>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>>>>> abstract >>>>>>>>>> the >>>>>>>>>> "local >>>>>>>>>> date" and "local time"? >>>>>>>>>> >>>>>>>>>> I think we agreed back to JSR310 that we don't try to add such kind >>>>>>>>>> of >>>>>>>>>> "bridge/ >>>>>>>>>> convenient/utility" methods into the new java.time package, but >>>>>>>>>> only >>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>> old date/calendar classes, if really needed. So if these methods >>>>>>>>>> are >>>>>>>>>> only to >>>>>>>>>> help >>>>>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>>>>> java.time >>>>>>>>>> might not be the best place for them? >>>>>>>>>> >>>>>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>>>>> commonly used in many codebases. >>>>>>>>>>> >>>>>>>>>> I'm not sure about that, especially the "natural" part. It might be >>>>>>>>>> "common" >>>>>>>>>> in >>>>>>>>>> the old days if you only have j.u.Date", and might be forced to use >>>>>>>>>> 1970-01-01 >>>>>>>>>> to fill in the "date" part even when you are really only interested >>>>>>>>>> in >>>>>>>>>> "time" part >>>>>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>>>>>>>>> now >>>>>>>>>> we >>>>>>>>>> have >>>>>>>>>> separate abstract for these different need, I don't see the common >>>>>>>>>> need >>>>>>>>>> of >>>>>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>>>>> misunderstood >>>>>>>>>> something here. >>>>>>>>>> >>>>>>>>>> -Sherman >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Stephen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 30 November 2015 at 18:15, Xueming >>>>>>>>>>> Shen >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> While it is kinda understandable to have >>>>>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of >>>>>>>>>>>> the >>>>>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>>>>> Local/OffsetTime >>>>>>>>>>>> to have two public methods with the assumption of the "date" is >>>>>>>>>>>> at >>>>>>>>>>>> epoch >>>>>>>>>>>> year/month/day. What's the use case/scenario for these two >>>>>>>>>>>> proposed >>>>>>>>>>>> methods? >>>>>>>>>>>> >>>>>>>>>>>> -Sherman >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>>>>> The method Javadoc (specs) for each of the three new methods >>>>>>>>>>>>> needs >>>>>>>>>>>>> to >>>>>>>>>>>>> be enhanced. >>>>>>>>>>>>> >>>>>>>>>>>>> For the date ones it needs to say >>>>>>>>>>>>> "The resulting date will have a time component of midnight at >>>>>>>>>>>>> the >>>>>>>>>>>>> start of the day." >>>>>>>>>>>>> >>>>>>>>>>>>> For the time ones it needs to say >>>>>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>>>>> >>>>>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>>>>> indented >>>>>>>>>>>>> correctly. >>>>>>>>>>>>> >>>>>>>>>>>>> Otherwise looks fine, >>>>>>>>>>>>> thanks >>>>>>>>>>>>> Stephen >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 November 2015 at 11:50, nadeesh tv >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev -http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>>>>> Nadeesh TV >>>>>>>>>>> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From claes.redestad at oracle.com Tue Dec 22 13:40:20 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 14:40:20 +0100 Subject: RFR(S): 8145988: Use the raw methods of java.net.URI when possible Message-ID: <567952C4.5080509@oracle.com> Hi, there are a number of cases where we check that the authority, query and fragment components of a URI is null. This simple patch changes some cases where we it's possible to instead use the getRawAuthority/-Query/... methods, which avoid some volatile loads and stores, which can reduce memory pressure. Bug: https://bugs.openjdk.java.net/browse/JDK-8145988 Webrev: http://cr.openjdk.java.net/~redestad/8145988/webrev.01 Thanks! /Claes From miroslav.kos at oracle.com Tue Dec 22 13:44:31 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 22 Dec 2015 14:44:31 +0100 Subject: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as expected according to spec Message-ID: <567953BF.5010206@oracle.com> Hi everybody, I'd like to ask for reviewing following patch. It fixes two issues: JBS: https://bugs.openjdk.java.net/browse/JDK-8145104 NPE is thrown when JAXBContextFactory implementation is specified in system property In short, it's a regression of recent changes in JAXB-AP. The old version of API is using static methods to create JAXBContext instance, where as the new configuration facility uses defined interface. The methods are called via core reflection, so when invoking non-static method of spi implemetation, instance of the spi must be created first. This fixes NPE which occured in certain scenarios. JBS: https://bugs.openjdk.java.net/browse/JDK-8145112 newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as expected according to spec There are still some changes in javadoc being discussed, but anyway this double-wrapping exception into JAXBException doesn't make any sense. JAXBException thrown from JAXB spi provider is re-thrown as is. Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/ Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/ Added 2 new jtreg tests, the tests added also to standalone project. Thanks Miran From aleksey.shipilev at oracle.com Tue Dec 22 14:21:25 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 22 Dec 2015 17:21:25 +0300 Subject: RFR(S): 8145988: Use the raw methods of java.net.URI when possible In-Reply-To: <567952C4.5080509@oracle.com> References: <567952C4.5080509@oracle.com> Message-ID: <56795C65.2020401@oracle.com> On 12/22/2015 04:40 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8145988/webrev.01 Looks good. Thanks, -Aleksey From claes.redestad at oracle.com Tue Dec 22 14:30:30 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 15:30:30 +0100 Subject: RFR(S): 8145988: Use the raw methods of java.net.URI when possible In-Reply-To: <56795C65.2020401@oracle.com> References: <567952C4.5080509@oracle.com> <56795C65.2020401@oracle.com> Message-ID: <56795E86.50001@oracle.com> On 2015-12-22 15:21, Aleksey Shipilev wrote: > On 12/22/2015 04:40 PM, Claes Redestad wrote: >> Webrev: http://cr.openjdk.java.net/~redestad/8145988/webrev.01 > Looks good. Thanks, Aleksey! From chris.hegarty at oracle.com Tue Dec 22 14:38:18 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 14:38:18 +0000 Subject: RFR(S): 8145988: Use the raw methods of java.net.URI when possible In-Reply-To: <567952C4.5080509@oracle.com> References: <567952C4.5080509@oracle.com> Message-ID: Thanks for doing this Claes. The changes look good to me. -Chris. On 22 Dec 2015, at 13:40, Claes Redestad wrote: > Hi, > > there are a number of cases where we check that the authority, query and fragment components of a URI is null. This simple patch changes some cases where we it's possible to instead use the getRawAuthority/-Query/... methods, which avoid some volatile loads and stores, which can reduce memory pressure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145988 > Webrev: http://cr.openjdk.java.net/~redestad/8145988/webrev.01 > > Thanks! > > /Claes From chris.hegarty at oracle.com Tue Dec 22 14:41:48 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 14:41:48 +0000 Subject: Remove sun.misc.CompoundEnumeration Message-ID: sun.misc.CompoundEnumeration is a utility class that supports enumerating over an array of enumerations. It is used in just a single place in the JDK, in ClassLoader.getResources(String) to support enumerating over the parent?s resources as well as the current loaders resources. I can find no usages outside of the JDK. This issue proposes to move sun.mics.CompoundEnumeration and its only use-site, in ClassLoader. http://cr.openjdk.java.net/~chegar/8146000/ Thanks, -Chris. P.S. this change has been prompted by preparatory cleanup work for JEP 260, JDK-8132928. From claes.redestad at oracle.com Tue Dec 22 14:41:29 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 15:41:29 +0100 Subject: RFR(S): 8145988: Use the raw methods of java.net.URI when possible In-Reply-To: References: <567952C4.5080509@oracle.com> Message-ID: <56796119.5010105@oracle.com> On 2015-12-22 15:38, Chris Hegarty wrote: > Thanks for doing this Claes. The changes look good to me. > > -Chris. Thanks for reviewing! /Claes From aleksey.shipilev at oracle.com Tue Dec 22 14:53:03 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 22 Dec 2015 17:53:03 +0300 Subject: Remove sun.misc.CompoundEnumeration In-Reply-To: References: Message-ID: <567963CF.3060103@oracle.com> On 12/22/2015 05:41 PM, Chris Hegarty wrote: > sun.misc.CompoundEnumeration is a utility class that supports enumerating > over an array of enumerations. It is used in just a single place in the JDK, in > ClassLoader.getResources(String) to support enumerating over the parent?s > resources as well as the current loaders resources. I can find no usages > outside of the JDK. > > This issue proposes to move sun.mics.CompoundEnumeration and its only > use-site, in ClassLoader. > > http://cr.openjdk.java.net/~chegar/8146000/ Looks good. Let me have my share of bike-shedding: * Class should be final * $enums field should be final * $index initialization can be dropped Thanks, -Aleksey From scolebourne at joda.org Tue Dec 22 14:53:29 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 22 Dec 2015 14:53:29 +0000 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: <567902DF.6090501@oracle.com> References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> <5672FB62.9090608@oracle.com> <567902DF.6090501@oracle.com> Message-ID: Fine by me, thanks Stephen On 22 December 2015 at 07:59, nadeesh tv wrote: > Hi all, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8143413/webrev.04/ > > Changes : Included the changes suggested by Stephen > > Thanks and Regards, > Nadeesh > > > On 12/22/2015 12:30 AM, Stephen Colebourne wrote: >> >> The comment for the new LocalDate.EPOCH field should use 1970-01-01, >> not 1970-1-1. However, the code should omit the zeroes: >> Replace: >> LocalDate.of(1970, 01, 01) >> with >> LocalDate.of(1970, 1, 1) >> >> The new method should follow the documentation of the similar method >> on ChronoLocalDateTime: >> >> * This combines this local date with the specified time and >> offset to calculate the >> * epoch-second value, which is the number of elapsed seconds from >> 1970-01-01T00:00:00Z. >> * Instants on the time-line after the epoch are positive, earlier >> are negative. >> >> The same applies to the new method on LocalTime: >> >> * This combines this local time with the specified date and >> offset to calculate the >> * epoch-second value, which is the number of elapsed seconds from >> 1970-01-01T00:00:00Z. >> * Instants on the time-line after the epoch are positive, earlier >> are negative. >> >> The same applies to the new method on OffsetTime: >> >> * This combines this offset time with the specified date to >> calculate the >> * epoch-second value, which is the number of elapsed seconds from >> 1970-01-01T00:00:00Z. >> * Instants on the time-line after the epoch are positive, earlier >> are negative. >> >> The test cases look good. >> >> thanks >> Stephen >> >> >> On 17 December 2015 at 18:13, nadeesh tv wrote: >>> >>> Hi all, >>> >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ >>> >>> Thanks and Regards, >>> Nadeesh >>> >>> On 12/4/2015 3:56 AM, Stephen Colebourne wrote: >>>> >>>> In the interests of harmony and getting something in, I'll accept that. >>>> >>>> I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY >>>> >>>> Stephen >>>> >>>> >>>> >>>> On 3 December 2015 at 22:09, Roger Riggs wrote: >>>>> >>>>> Hi Sherman, >>>>> >>>>> It makes sense to me to provide the missing time/date as an explicit >>>>> parameter >>>>> for toEpochSeconds instead of assuming some constant. >>>>> >>>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); >>>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); >>>>> offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); >>>>> >>>>> We'll have to add the LocalDate.EPOCHDAY constant. >>>>> >>>>> It makes it a bit heavier weight to use but can still be optimized and >>>>> won't >>>>> create garbage. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> On 12/01/2015 12:33 PM, Xueming Shen wrote: >>>>>> >>>>>> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>>>>>> >>>>>>> As Roger says, these new methods are about performance as well as >>>>>>> conversion. >>>>>>> >>>>>>> While I fully acknowledge the time methods make an assumption, it is >>>>>>> not a crazy one, after all 1970-01-01 is just zero. >>>>>>> >>>>>>> Key I think is it allows: >>>>>>> long epochSecs = date.toEpochSeconds(offset) + >>>>>>> time.toEpochSeconds(offset); >>>>>>> to efficiently merge two objects without garbage. >>>>>> >>>>>> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >>>>>> approach >>>>>> >>>>>> LocalDate date = ... >>>>>> LocalDate time = ... >>>>>> ZoneOffset offset = ... >>>>>> >>>>>> ==> long spochSecs = LocalDateTime.of(date, >>>>>> time).toEpochSeconds(offset); >>>>>> >>>>>> we are adding APIs to provide a "fastpath" with the special assumption >>>>>> that the LocalDate "date" >>>>>> here is actually a "LocalDateTime" object ("date" + >>>>>> LocalTime.MIDNIGHT) >>>>>> and the LocalTime "time" >>>>>> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to >>>>>> let >>>>>> the third party "libraries" >>>>>> to fool the basic date/time abstract in java.time package, simply to >>>>>> avoid creating the garbage >>>>>> middle man, localDateTime? it really does not sound right to me. >>>>>> >>>>>> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >>>>>> epoch seconds in their >>>>>> libraries, they really SHOULD think hard about the conversion and make >>>>>> it >>>>>> right (it should not >>>>>> be encouraged to use these classes LocalDate, LocalTime and Offset >>>>>> without >>>>>> even understand >>>>>> what these classes are). But if we really have to provide such >>>>>> fastpath, >>>>>> personally I think it might >>>>>> be better either to provide these "utility/convenient" methods in a >>>>>> "utilities" class, or with an >>>>>> explicit date/time parameters (instead of the false assumption) for >>>>>> the >>>>>> missing date/time piece, >>>>>> such as >>>>>> >>>>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >>>>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >>>>>> >>>>>> Sherman >>>>>> >>>>>> >>>>>>> It also means that no-one has to think hard about the conversion, as >>>>>>> it is just there. It tends to be when people try to work this stuff >>>>>>> out for themselves that they get it wrong. >>>>>>> >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> On 1 December 2015 at 14:21, Roger Riggs >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Sherman, >>>>>>>> >>>>>>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>>>>>> >>>>>>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>>>>>> >>>>>>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>>>>>> largest number of votes on SO: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>>>>>> The proposed method is designed to make the conversion easier. It >>>>>>>>>> also >>>>>>>>>> plugs an obvious gap in the API. >>>>>>>>>> >>>>>>>>>> While the LocalTime/OffsetTime methods are of lower importance, >>>>>>>>>> not >>>>>>>>>> having them would result in inconsistency between the various >>>>>>>>>> classes. >>>>>>>>>> We've already added factory methods to LocalTime for Java 9, these >>>>>>>>>> are >>>>>>>>>> just the other half of the picture. >>>>>>>>>> >>>>>>>>> I'm not sure I understand the idea of "the proposed method is >>>>>>>>> designed >>>>>>>>> to >>>>>>>>> make the conversion easier", as the SO is mainly about >>>>>>>>> j.u.Date->LocalDate, >>>>>>>>> not the other way around, from LocalDate -> j.u.Date. >>>>>>>> >>>>>>>> I think the issue is about *other* libraries that manipulate time >>>>>>>> via >>>>>>>> epochSeconds >>>>>>>> not about j.u.Date conversions. The concern was about performance >>>>>>>> and >>>>>>>> creating garbage along the way. >>>>>>>> >>>>>>>> Roger >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> As I said in the previous email, it might be "common" to use the >>>>>>>>> j.u.Date >>>>>>>>> to >>>>>>>>> abstract a "local date" and/or a "local time" (no other choice) >>>>>>>>> before >>>>>>>>> java.time, >>>>>>>>> and now there is the need to provide a migration path from those >>>>>>>>> "local >>>>>>>>> date/ >>>>>>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>>>>>> date/time >>>>>>>>> type to the "old" j.u.Date should not be encouraged (guess this is >>>>>>>>> also >>>>>>>>> the >>>>>>>>> consensus we agreed on back to jsr203). >>>>>>>>> >>>>>>>>> What are the "factory methods" you are referring to here? >>>>>>>>> JDK-8133079, >>>>>>>>> The >>>>>>>>> LocalDate/LocalTime.ofInstant()? >>>>>>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>>>>>> >>>>>>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>>>>>> "super-set" >>>>>>>>> of >>>>>>>>> date/time to a "sub-set", without any assumption of "default >>>>>>>>> value", >>>>>>>>> it >>>>>>>>> is >>>>>>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>>>>>> "small" >>>>>>>>> improvement >>>>>>>>> >>>>>>>>> from| >>>>>>>>> Date input = new Date(); >>>>>>>>> LocalDatedate >>>>>>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>>>>>> >>>>>>>>> to >>>>>>>>> >>>>>>>>> |LocalDatedate >>>>>>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>>>>>> >>>>>>>>> The proposed pair toEpochSecond() however is doing the other way >>>>>>>>> around >>>>>>>>> and >>>>>>>>> with an unusual assumption of the missing date/time piece to a >>>>>>>>> "default >>>>>>>>> value" >>>>>>>>> (midnight, the epoch day). >>>>>>>>> >>>>>>>>> personally I think >>>>>>>>> >>>>>>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>>>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>>>>>> >>>>>>>>> is clean and good enough to help this backward conversion (with the >>>>>>>>> addition >>>>>>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help >>>>>>>>> to >>>>>>>>> remove that LocalDateTime middle man, with some arrangement. >>>>>>>>> >>>>>>>>> -Sherman >>>>>>>>> >>>>>>>>>> Note that these methods are specifically not referencing >>>>>>>>>> java.util.Date itself. Epoch seconds is the appropriate >>>>>>>>>> intermediate >>>>>>>>>> form here, and still widely used. >>>>>>>>>> >>>>>>>>>> Stephen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 30 November 2015 at 19:36, Xueming >>>>>>>>>> Shen >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>>>>>> These >>>>>>>>>>>> methods aim to provide a simpler and faster approach, >>>>>>>>>>>> particularly >>>>>>>>>>>> for >>>>>>>>>>>> cases converting to/from java.util.Date. >>>>>>>>>>> >>>>>>>>>>> Can you be a little more specific on this one? We now have >>>>>>>>>>> Instance<=> >>>>>>>>>>> Date, >>>>>>>>>>> and considerably we might add LocalDateTime<=> Date with an >>>>>>>>>>> offset, >>>>>>>>>>> if >>>>>>>>>>> really >>>>>>>>>>> really desired (for performance? to save a Instant object as the >>>>>>>>>>> bridge?). >>>>>>>>>>> But I'm >>>>>>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>>>>>> epoch >>>>>>>>>>> seconds >>>>>>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>>>>>> >>>>>>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>>>>>> >>>>>>>>>>> and uses the converted j.u.Date to represent a local date (date >>>>>>>>>>> with >>>>>>>>>>> time >>>>>>>>>>> part to >>>>>>>>>>> be 0) and/or the local time (with year/month/day to be epoch >>>>>>>>>>> time) >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> "old" >>>>>>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>>>>>> abstract >>>>>>>>>>> the >>>>>>>>>>> "local >>>>>>>>>>> date" and "local time"? >>>>>>>>>>> >>>>>>>>>>> I think we agreed back to JSR310 that we don't try to add such >>>>>>>>>>> kind >>>>>>>>>>> of >>>>>>>>>>> "bridge/ >>>>>>>>>>> convenient/utility" methods into the new java.time package, but >>>>>>>>>>> only >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> old date/calendar classes, if really needed. So if these methods >>>>>>>>>>> are >>>>>>>>>>> only to >>>>>>>>>>> help >>>>>>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>>>>>> java.time >>>>>>>>>>> might not be the best place for them? >>>>>>>>>>> >>>>>>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>>>>>> commonly used in many codebases. >>>>>>>>>>>> >>>>>>>>>>> I'm not sure about that, especially the "natural" part. It might >>>>>>>>>>> be >>>>>>>>>>> "common" >>>>>>>>>>> in >>>>>>>>>>> the old days if you only have j.u.Date", and might be forced to >>>>>>>>>>> use >>>>>>>>>>> 1970-01-01 >>>>>>>>>>> to fill in the "date" part even when you are really only >>>>>>>>>>> interested >>>>>>>>>>> in >>>>>>>>>>> "time" part >>>>>>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>>>>>>>>>> now >>>>>>>>>>> we >>>>>>>>>>> have >>>>>>>>>>> separate abstract for these different need, I don't see the >>>>>>>>>>> common >>>>>>>>>>> need >>>>>>>>>>> of >>>>>>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>>>>>> misunderstood >>>>>>>>>>> something here. >>>>>>>>>>> >>>>>>>>>>> -Sherman >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Stephen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 30 November 2015 at 18:15, Xueming >>>>>>>>>>>> Shen >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> While it is kinda understandable to have >>>>>>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of >>>>>>>>>>>>> the >>>>>>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>>>>>> Local/OffsetTime >>>>>>>>>>>>> to have two public methods with the assumption of the "date" is >>>>>>>>>>>>> at >>>>>>>>>>>>> epoch >>>>>>>>>>>>> year/month/day. What's the use case/scenario for these two >>>>>>>>>>>>> proposed >>>>>>>>>>>>> methods? >>>>>>>>>>>>> >>>>>>>>>>>>> -Sherman >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The method Javadoc (specs) for each of the three new methods >>>>>>>>>>>>>> needs >>>>>>>>>>>>>> to >>>>>>>>>>>>>> be enhanced. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the date ones it needs to say >>>>>>>>>>>>>> "The resulting date will have a time component of midnight at >>>>>>>>>>>>>> the >>>>>>>>>>>>>> start of the day." >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the time ones it needs to say >>>>>>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>>>>>> indented >>>>>>>>>>>>>> correctly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Otherwise looks fine, >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> Stephen >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 30 November 2015 at 11:50, nadeesh >>>>>>>>>>>>>> tv >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev -http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>>>>>> Nadeesh TV >>>>>>>>>>>> >>>>>>>>>>>> >>> >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > > -- > Thanks and Regards, > Nadeesh TV > From chris.hegarty at oracle.com Tue Dec 22 14:57:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 14:57:07 +0000 Subject: Remove sun.misc.CompoundEnumeration In-Reply-To: <567963CF.3060103@oracle.com> References: <567963CF.3060103@oracle.com> Message-ID: <852BC639-19B6-4403-B77B-0578F1234118@oracle.com> On 22 Dec 2015, at 14:53, Aleksey Shipilev wrote: > On 12/22/2015 05:41 PM, Chris Hegarty wrote: >> sun.misc.CompoundEnumeration is a utility class that supports enumerating >> over an array of enumerations. It is used in just a single place in the JDK, in >> ClassLoader.getResources(String) to support enumerating over the parent?s >> resources as well as the current loaders resources. I can find no usages >> outside of the JDK. >> >> This issue proposes to move sun.mics.CompoundEnumeration and its only >> use-site, in ClassLoader. >> >> http://cr.openjdk.java.net/~chegar/8146000/ > > Looks good. Let me have my share of bike-shedding: > > * Class should be final > * $enums field should be final > * $index initialization can be dropped Thanks Aleksey, All comments accepted and done. Updated webrev in-place: http://cr.openjdk.java.net/~chegar/8146000/ -Chris. From aleksey.shipilev at oracle.com Tue Dec 22 14:58:45 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 22 Dec 2015 17:58:45 +0300 Subject: Remove sun.misc.CompoundEnumeration In-Reply-To: <852BC639-19B6-4403-B77B-0578F1234118@oracle.com> References: <567963CF.3060103@oracle.com> <852BC639-19B6-4403-B77B-0578F1234118@oracle.com> Message-ID: <56796525.9020202@oracle.com> On 12/22/2015 05:57 PM, Chris Hegarty wrote: > http://cr.openjdk.java.net/~chegar/8146000/ Looks good. Thanks, -Aleksey P.S. Nice bug ID, pity to waste it on a trivial thing :D From chris.hegarty at oracle.com Tue Dec 22 15:00:12 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 15:00:12 +0000 Subject: Remove sun.misc.CompoundEnumeration In-Reply-To: <56796525.9020202@oracle.com> References: <567963CF.3060103@oracle.com> <852BC639-19B6-4403-B77B-0578F1234118@oracle.com> <56796525.9020202@oracle.com> Message-ID: On 22 Dec 2015, at 14:58, Aleksey Shipilev wrote: > On 12/22/2015 05:57 PM, Chris Hegarty wrote: >> http://cr.openjdk.java.net/~chegar/8146000/ > > Looks good. Thanks. > Thanks, > -Aleksey > > P.S. Nice bug ID, pity to waste it on a trivial thing :D Right. I?m willing to give it up it if you want it? ;-) -Chris. From claes.redestad at oracle.com Tue Dec 22 16:13:04 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 17:13:04 +0100 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI Message-ID: <56797690.3060207@oracle.com> Hi, please review this patch to clean up and remove volatile from a number of lazily initialized fields in java.net.URI. This is safe as long as the fields are always accessed through their accessors and the accessors return the local result of the calculation. Since initialization was done with no synchronization, there was never any guarantee that different Strings couldn't escape from concurrent calls to these getters. So even if this becomes more likely by dropping volatile, this should be of no real consequence. Bug: https://bugs.openjdk.java.net/browse/JDK-8145862 Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 Thanks! /Claes From Roger.Riggs at Oracle.com Tue Dec 22 16:35:00 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Dec 2015 11:35:00 -0500 Subject: RFR 9: 8146012: CleanerTest fails: Cleanable should have been freed Message-ID: <56797BB4.6040803@Oracle.com> Please review improvements to the CleanerTest to improve the reliability of the test. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleanertest-8146012/ Issue: https://bugs.openjdk.java.net/browse/JDK-8146012 Thanks, Roger From magnus.ihse.bursie at oracle.com Tue Dec 22 16:45:22 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Dec 2015 17:45:22 +0100 Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE In-Reply-To: References: Message-ID: <4332DB87-605E-47C3-897A-EF09085337BF@oracle.com> Looks good to me. /Magnus > 21 dec. 2015 kl. 21:18 skrev Bob Vandette : > > http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ > > Please review the following fixes that were required to complete the > initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. > > 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to > ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family > and not specific architecture version. This is the way x86/x86_x64 is also handled. > > 2. Add the SocketOption and UnixConstant template files into the JDK repo. > These are required for cross compilation builds since the genSocketOption > and genUnixConstants programs cannot be run on the build system. > > 3. Add a macosx directory for iOS build in the NIO makefile. > Exclude the UTIFileTypeDetector.c file from the iOS build since it > is dependent on a Framework that is not available in iOS. We probably > should remove the entire MacOSXFileSystemProvider set of classes. > Currently the default provider for iOS is Bsd. > > Bob Vandette > From aleksey.shipilev at oracle.com Tue Dec 22 16:49:03 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 22 Dec 2015 19:49:03 +0300 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: <56797690.3060207@oracle.com> References: <56797690.3060207@oracle.com> Message-ID: <56797EFF.3000709@oracle.com> On 12/22/2015 07:13 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 Looks good. Thanks, -Aleksey From chris.hegarty at oracle.com Tue Dec 22 17:01:08 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:01:08 +0000 Subject: RFR 9: 8146012: CleanerTest fails: Cleanable should have been freed In-Reply-To: <56797BB4.6040803@Oracle.com> References: <56797BB4.6040803@Oracle.com> Message-ID: <54A17493-3142-4006-B41F-92AF9AEE6B78@oracle.com> Hi Roger, On 22 Dec 2015, at 16:35, Roger Riggs wrote: > Please review improvements to the CleanerTest to improve the reliability of the test. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleanertest-8146012/ The use of WhiteBox should make the test more reliable ( rather than relying on generating garbage ). Is @library /lib/testlibrary necessary? I don?t see any usage of types from it. Is '-Xbootclasspath/a:.? necessary? Is this for WhiteBox, or the test itself? I don?t see why it is necessary. Moving from a varargs of Semaphore to just a single Semaphore does simplify the code, since it is always called with a single Semaphore. The new checkCleaned does not enforce availablePermits == 1, just that a permit is available. Should it assert 1 ? -Chris. > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146012 > > Thanks, Roger From chris.hegarty at oracle.com Tue Dec 22 17:14:23 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:14:23 +0000 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: <56797690.3060207@oracle.com> References: <56797690.3060207@oracle.com> Message-ID: <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> On 22 Dec 2015, at 16:13, Claes Redestad wrote: > Hi, > > please review this patch to clean up and remove volatile from a number of lazily initialized fields in java.net.URI. So ?string? is the only remaining volatile field. Is there any specific reason for this? > This is safe as long as the fields are always accessed through their accessors and the accessors return the local result of the calculation. Ok, I see the pattern that you are using. > Since initialization was done with no synchronization, there was never any guarantee that different Strings couldn't escape from concurrent calls to these getters. So even if this becomes more likely by dropping volatile, this should be of no real consequence. Right. This all seems a little fragile, but no worse than before your changes, and I get why some of these fields are ?lazy?. > Bug: https://bugs.openjdk.java.net/browse/JDK-8145862 > Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 I?m ok with these changes. I notice that the public javadoc has "Instances of this class are immutable?. I wonder if the fields, that are no longer volatile, deserve a comment explaining that their initialization is racy? -Chris. > Thanks! > > /Claes From chris.hegarty at oracle.com Tue Dec 22 17:16:57 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:16:57 +0000 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> References: <56797690.3060207@oracle.com> <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> Message-ID: On 22 Dec 2015, at 17:14, Chris Hegarty wrote: > On 22 Dec 2015, at 16:13, Claes Redestad wrote: > >> Hi, >> >> please review this patch to clean up and remove volatile from a number of lazily initialized fields in java.net.URI. > > So ?string? is the only remaining volatile field. Is there any specific reason for this? > >> This is safe as long as the fields are always accessed through their accessors and the accessors return the local result of the calculation. > > Ok, I see the pattern that you are using. > >> Since initialization was done with no synchronization, there was never any guarantee that different Strings couldn't escape from concurrent calls to these getters. So even if this becomes more likely by dropping volatile, this should be of no real consequence. > > Right. This all seems a little fragile, but no worse than before your changes, > and I get why some of these fields are ?lazy?. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145862 >> Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 > > I?m ok with these changes. > > I notice that the public javadoc has "Instances of this class are immutable?. I wonder > if the fields, that are no longer volatile, deserve a comment explaining that their > initialization is racy? Sorry, I mean: ?? is safe in the face of multiple threads racing to initialize them?. -Chris. > -Chris. > >> Thanks! >> >> /Claes > From claes.redestad at oracle.com Tue Dec 22 17:40:09 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 18:40:09 +0100 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: References: <56797690.3060207@oracle.com> <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> Message-ID: <56798AF9.6070900@oracle.com> Hi! On 2015-12-22 18:16, Chris Hegarty wrote: > On 22 Dec 2015, at 17:14, Chris Hegarty wrote: > >> On 22 Dec 2015, at 16:13, Claes Redestad wrote: >> >>> Hi, >>> >>> please review this patch to clean up and remove volatile from a number of lazily initialized fields in java.net.URI. >> So ?string? is the only remaining volatile field. Is there any specific reason for this? writeObject must first ensure the string has been defined, then have it re-read by the ObjectOutputStream, breaking the safe pattern of always operating on the newly generated, local value. I guess we might be able to turn to more explicit serialization using persistentSerializationFields so that we can deal with that benign race properly as well, but I feel that's out of scope for this improvement. >> >>> This is safe as long as the fields are always accessed through their accessors and the accessors return the local result of the calculation. >> Ok, I see the pattern that you are using. >> >>> Since initialization was done with no synchronization, there was never any guarantee that different Strings couldn't escape from concurrent calls to these getters. So even if this becomes more likely by dropping volatile, this should be of no real consequence. >> Right. This all seems a little fragile, but no worse than before your changes, >> and I get why some of these fields are ?lazy?. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145862 >>> Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 >> I?m ok with these changes. >> >> I notice that the public javadoc has "Instances of this class are immutable?. I wonder >> if the fields, that are no longer volatile, deserve a comment explaining that their >> initialization is racy? > Sorry, I mean: ?? is safe in the face of multiple threads racing to initialize them?. How about: // The remaining fields may be computed on demand, which is safe even in // the face of multiple threads racing to initialize them Thanks for reviewing! /Claes From chris.hegarty at oracle.com Tue Dec 22 17:54:21 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:54:21 +0000 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: <56798AF9.6070900@oracle.com> References: <56797690.3060207@oracle.com> <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> <56798AF9.6070900@oracle.com> Message-ID: On 22 Dec 2015, at 17:40, Claes Redestad wrote: > Hi! > > On 2015-12-22 18:16, Chris Hegarty wrote: >> On 22 Dec 2015, at 17:14, Chris Hegarty wrote: >> >>> On 22 Dec 2015, at 16:13, Claes Redestad wrote: >>> >>>> Hi, >>>> >>>> please review this patch to clean up and remove volatile from a number of lazily initialized fields in java.net.URI. >>> So ?string? is the only remaining volatile field. Is there any specific reason for this? > > writeObject must first ensure the string has been defined, then have it re-read by the ObjectOutputStream, breaking the safe pattern of always operating on the newly generated, local value. > > I guess we might be able to turn to more explicit serialization using persistentSerializationFields so that we can deal with that benign race properly as well, but I feel that's out of scope for this improvement. Agreed, and thanks for the explanation. >>> >>>> This is safe as long as the fields are always accessed through their accessors and the accessors return the local result of the calculation. >>> Ok, I see the pattern that you are using. >>> >>>> Since initialization was done with no synchronization, there was never any guarantee that different Strings couldn't escape from concurrent calls to these getters. So even if this becomes more likely by dropping volatile, this should be of no real consequence. >>> Right. This all seems a little fragile, but no worse than before your changes, >>> and I get why some of these fields are ?lazy?. >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145862 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8145862/webrev.01 >>> I?m ok with these changes. >>> >>> I notice that the public javadoc has "Instances of this class are immutable?. I wonder >>> if the fields, that are no longer volatile, deserve a comment explaining that their >>> initialization is racy? >> Sorry, I mean: ?? is safe in the face of multiple threads racing to initialize them?. > > How about: > > // The remaining fields may be computed on demand, which is safe even in > // the face of multiple threads racing to initialize them Perfect. Thanks, -Chris. > Thanks for reviewing! > > /Claes From dmitry.cherepanov at oracle.com Tue Dec 22 18:07:32 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 22 Dec 2015 13:07:32 -0500 Subject: Review request 8145409: Better detect JRE that JLI will be using Message-ID: <56799164.9080903@oracle.com> Hello, Please review the following patch https://bugs.openjdk.java.net/browse/JDK-8145409 http://cr.openjdk.java.net/~dcherepanov/8145409/webrev.v0/ The patch improves GetJREPath() on Windows and implements a fallback for applications with custom native launcher and private JRE. Thanks, Dmitry From Roger.Riggs at Oracle.com Tue Dec 22 18:10:26 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Dec 2015 13:10:26 -0500 Subject: RFR 9: 8146012: CleanerTest fails: Cleanable should have been freed In-Reply-To: <54A17493-3142-4006-B41F-92AF9AEE6B78@oracle.com> References: <56797BB4.6040803@Oracle.com> <54A17493-3142-4006-B41F-92AF9AEE6B78@oracle.com> Message-ID: <56799212.2060204@Oracle.com> Hi Chris, Thanks for the review On 12/22/2015 12:01 PM, Chris Hegarty wrote: > Hi Roger, > > On 22 Dec 2015, at 16:35, Roger Riggs wrote: > >> Please review improvements to the CleanerTest to improve the reliability of the test. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleanertest-8146012/ > > The use of WhiteBox should make the test more reliable ( rather than relying > on generating garbage ). > > Is @library /lib/testlibrary necessary? I don?t see any usage of types from it. yes, the ClassFileInstaller that enables the WhiteBox is there. > > Is '-Xbootclasspath/a:.? necessary? Is this for WhiteBox, or the test itself? I > don?t see why it is necessary. yes, That's how the share library for the whitebox native code is found. > > Moving from a varargs of Semaphore to just a single Semaphore does simplify > the code, since it is always called with a single Semaphore. > > The new checkCleaned does not enforce availablePermits == 1, just that a permit > is available. Should it assert 1 ? The tryAdvance method consumes the expected permit and the method does not wait around to see if it will get incremented again. So checking again would be hit or miss. The check completes when the semaphore is triggered. The running time of the test would increase and I can't see it paying off since the Cleaner implementation is written to call it only once, so it would require some unexpected case to trigger that bug. Roger > > -Chris. > >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8146012 >> >> Thanks, Roger From claes.redestad at oracle.com Tue Dec 22 18:16:09 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Dec 2015 19:16:09 +0100 Subject: RFR: 8145862: Improve lazy initialization of fields in java.net.URI In-Reply-To: References: <56797690.3060207@oracle.com> <78707F6E-3B60-4C8A-A0F5-56CBEDA1F459@oracle.com> <56798AF9.6070900@oracle.com> Message-ID: <56799369.40603@oracle.com> On 2015-12-22 18:54, Chris Hegarty wrote: >> How about: >> >> // The remaining fields may be computed on demand, which is safe even in >> // the face of multiple threads racing to initialize them > Perfect. Thanks, > > -Chris. > Thanks! /Claes From ramanand.patil at oracle.com Tue Dec 22 18:48:57 2015 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 22 Dec 2015 10:48:57 -0800 (PST) Subject: RFR: 8145388: URLConnection.guessContentTypeFromStream returns image/jpg for some JPEG images Message-ID: <2d0ba104-166a-4131-b9a0-208a0785ad41@default> HI all, Please review this small fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145388 Bug Description - For some JPEG images the method java.net.URLConnection#guessContentTypeFromStream will return the MIME type image/jpg, which is not a valid, registered IANA mime type for JPEG images. Webrev - http://cr.openjdk.java.net/~ntv/ramanand/8145388/webrev.00/ Fix - Since "image/jpg" is not a valid Content Type, the method should return "image/jpeg" when APPn marker segment has 'EE' as a marker type. Regards, Ramanand. From brian.burkhalter at oracle.com Tue Dec 22 19:00:02 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 22 Dec 2015 11:00:02 -0800 Subject: RFR: 8145388: URLConnection.guessContentTypeFromStream returns image/jpg for some JPEG images In-Reply-To: <2d0ba104-166a-4131-b9a0-208a0785ad41@default> References: <2d0ba104-166a-4131-b9a0-208a0785ad41@default> Message-ID: Looks OK to me (but I am not a JDK 9 Reviewer). Brian On Dec 22, 2015, at 10:48 AM, Ramanand Patil wrote: > Webrev -http://cr.openjdk.java.net/~ntv/ramanand/8145388/webrev.00/ > > > > Fix - Since "image/jpg" is not a valid Content Type, the method should return "image/jpeg" when APPn marker segment has 'EE' as a marker type. From chris.hegarty at oracle.com Tue Dec 22 19:09:26 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 19:09:26 +0000 Subject: RFR 9: 8146012: CleanerTest fails: Cleanable should have been freed In-Reply-To: <56799212.2060204@Oracle.com> References: <56797BB4.6040803@Oracle.com> <54A17493-3142-4006-B41F-92AF9AEE6B78@oracle.com> <56799212.2060204@Oracle.com> Message-ID: Thanks for your reply Roger. I?m fine with the changes are they are. -Chris. On 22 Dec 2015, at 18:10, Roger Riggs wrote: > Hi Chris, > > Thanks for the review > > On 12/22/2015 12:01 PM, Chris Hegarty wrote: >> Hi Roger, >> >> On 22 Dec 2015, at 16:35, Roger Riggs >> >> wrote: >> >> >>> Please review improvements to the CleanerTest to improve the reliability of the test. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-cleanertest-8146012/ >> >> The use of WhiteBox should make the test more reliable ( rather than relying >> on generating garbage ). >> >> Is @library /lib/testlibrary necessary? I don?t see any usage of types from it. >> > yes, the ClassFileInstaller that enables the WhiteBox is there. >> >> Is '-Xbootclasspath/a:.? necessary? Is this for WhiteBox, or the test itself? I >> don?t see why it is necessary. >> > yes, That's how the share library for the whitebox native code is found. >> >> Moving from a varargs of Semaphore to just a single Semaphore does simplify >> the code, since it is always called with a single Semaphore. >> >> The new checkCleaned does not enforce availablePermits == 1, just that a permit >> is available. Should it assert 1 ? >> > The tryAdvance method consumes the expected permit and the method does not wait around to > see if it will get incremented again. So checking again would be hit or miss. The check completes > when the semaphore is triggered. > The running time of the test would increase and I can't see it paying off since the Cleaner > implementation is written to call it only once, so it would require some unexpected case to trigger that bug. > > Roger > >> >> -Chris. >> >> >>> Issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8146012 >>> >>> >>> Thanks, Roger >>> > From chris.hegarty at oracle.com Tue Dec 22 19:46:43 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 19:46:43 +0000 Subject: RFR [9] CleanerImpl should not depend on ManagedLocalsThread Message-ID: With the addition of a Thread constructor that can suppress the inheriting of inheritable thread-local variable initial values from the constructing thread [1], the usages of ManagedLocalsThread were removed from the base module. ManagedLocalsThread was also removed from the hierarchy of InnocuousThread, to help reduce dependencies. As a result InnocuousThread is no longer a ManagedLocalsThread, and the CleanerImpl should not use it in its instanceof check. This just appears to be a timing issue as both changes were in flight. I did not add an explicit test as this is implementation detail, but adding one would be straight forward. Such a test may be more appropriate when 8146028 "Common Cleaner for finalization replacements in java.base" [2], is added. diff --git a/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java b/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java --- a/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java +++ b/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java @@ -39,7 +39,6 @@ import java.util.function.Function; import sun.misc.InnocuousThread; -import sun.misc.ManagedLocalsThread; /** * CleanerImpl manages a set of object references and corresponding cleaning actions. @@ -130,8 +129,8 @@ */ public void run() { Thread t = Thread.currentThread(); - ManagedLocalsThread mlThread = (t instanceof ManagedLocalsThread) - ? (ManagedLocalsThread) t + InnocuousThread mlThread = (t instanceof InnocuousThread) + ? (InnocuousThread) t : null; while (!phantomCleanableList.isListEmpty() || !weakCleanableList.isListEmpty() || -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8056152 [2] https://bugs.openjdk.java.net/browse/JDK-8146028 From Roger.Riggs at Oracle.com Tue Dec 22 19:49:01 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Dec 2015 14:49:01 -0500 Subject: RFR [9] CleanerImpl should not depend on ManagedLocalsThread In-Reply-To: References: Message-ID: <5679A92D.6040200@Oracle.com> Hi Chris, Looks good, thanks for fixing this. Roger On 12/22/2015 2:46 PM, Chris Hegarty wrote: > With the addition of a Thread constructor that can suppress the inheriting > of inheritable thread-local variable initial values from the constructing > thread [1], the usages of ManagedLocalsThread were removed from > the base module. ManagedLocalsThread was also removed from the > hierarchy of InnocuousThread, to help reduce dependencies. As a > result InnocuousThread is no longer a ManagedLocalsThread, and > the CleanerImpl should not use it in its instanceof check. > > This just appears to be a timing issue as both changes were in flight. > I did not add an explicit test as this is implementation detail, but adding > one would be straight forward. Such a test may be more appropriate > when 8146028 "Common Cleaner for finalization replacements in > java.base" [2], is added. > > > diff --git a/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java b/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > --- a/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > +++ b/src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java > @@ -39,7 +39,6 @@ > import java.util.function.Function; > > import sun.misc.InnocuousThread; > -import sun.misc.ManagedLocalsThread; > > /** > * CleanerImpl manages a set of object references and corresponding cleaning actions. > @@ -130,8 +129,8 @@ > */ > public void run() { > Thread t = Thread.currentThread(); > - ManagedLocalsThread mlThread = (t instanceof ManagedLocalsThread) > - ? (ManagedLocalsThread) t > + InnocuousThread mlThread = (t instanceof InnocuousThread) > + ? (InnocuousThread) t > : null; > while (!phantomCleanableList.isListEmpty() || > !weakCleanableList.isListEmpty() || > > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8056152 > [2] https://bugs.openjdk.java.net/browse/JDK-8146028 From sean.coffey at oracle.com Tue Dec 22 20:01:44 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 22 Dec 2015 20:01:44 +0000 Subject: Remove sun.misc.CompoundEnumeration In-Reply-To: References: <567963CF.3060103@oracle.com> <852BC639-19B6-4403-B77B-0578F1234118@oracle.com> <56796525.9020202@oracle.com> Message-ID: <5679AC28.20205@oracle.com> Looks good! Regards, Sean. On 22/12/2015 15:00, Chris Hegarty wrote: > On 22 Dec 2015, at 14:58, Aleksey Shipilev wrote: > >> On 12/22/2015 05:57 PM, Chris Hegarty wrote: >>> http://cr.openjdk.java.net/~chegar/8146000/ >> Looks good. > Thanks. > >> Thanks, >> -Aleksey >> >> P.S. Nice bug ID, pity to waste it on a trivial thing :D > Right. I?m willing to give it up it if you want it? ;-) > > -Chris. From Roger.Riggs at Oracle.com Tue Dec 22 20:07:01 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 22 Dec 2015 15:07:01 -0500 Subject: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty In-Reply-To: <56789536.8050102@oracle.com> References: <56735284.6060203@oracle.com> <5678709E.9040609@Oracle.com> <56789536.8050102@oracle.com> Message-ID: <5679AD65.6030107@Oracle.com> Hi Joe, Thanks for the updates. Looks fine. Roger On 12/21/2015 7:11 PM, huizhe wang wrote: > Thanks Roger! > > On 12/21/2015 1:35 PM, Roger Riggs wrote: >> Hi Joe, >> >> A few comments: >> >> InputSource: > > I assume you meant javax.xml.transform.Source (there was an error in > Source's javadoc where the return statement referred to it as > InputSource). > >> - Should the default method return true? The default method is only >> present >> to allow source compatibility with unknown subtypes. I would >> expect that without >> any specific implementation knowledge it would need to be false. >> All of the JDK provided Sources will implement isEmpty appropriately. > > Changed to throw UOE now as Joe recommended. > >> >> - Editorial: "Empty means that there is no input available from >> this Source". > > Fixed. >> >> - from the definition and implementation it seems that isEmpty will >> be true >> when a stream (streamSource) is positioned just before EOF. Is >> that intended? > > Yes. In general, a Source object shall be passed to a processor with > input positioned at the beginning. If for some reason it's not, the > Source object will not handle the situation. >> >> >> stream/StreamSource: >> - Does not need to check both sources; if the first source has any >> input, return false immediately. > > Fixed. >> >> - the choice to return false when an IOException occurs seems odd; >> if reading throws an exception then it seems unlikely that any >> future read could work; >> and hence there is no more input. > > It's true no future read would work. But since a Source object can be > used in various situations where "empty" and failure to read are > treated differently by the processor, the isEmpty method needs to > abort its process, return false to indicate it's not empty, thus allow > the processor to handle the error. > > I added a statement to the spec. > >> >> - Note also that you probably need separate try/catch handlers for >> the stream vs the reader. >> An exception from reading the inputStream should no preempt the >> reader. > > As discussed above, in case of error, isEmpty will abort its process > and return false. > >> >> sax/InputSource: >> - ditto the comments above. >> >> In the test: >> - This test is duplicated: >> >> + "{new SAXSource(new InputSource(new StringReader("")))}, >> + {new SAXSource(new InputSource(new StringReader("")))}, > > Fixed. > > http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ > > Thanks, > Joe > >> >> >> Roger >> >> >> On 12/17/2015 7:25 PM, huizhe wang wrote: >>> Hi, >>> >>> Adding a convenient method isEmpty to javax.xml.transform.Source and >>> org.xml.sax.InputSource. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ >>> >>> Thanks, >>> Joe >>> >> > From lance.andersen at oracle.com Tue Dec 22 20:59:23 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Dec 2015 15:59:23 -0500 Subject: RFR: 8144082: Add Statement.enquoteNCharLiteral Message-ID: <04F3530F-B72A-4FD6-BFC4-896DDF28C847@oracle.com> Happy Tuesday, Need a reviewer for 8144082 which adds Statement.enquoteNCharLiteral. The CCC has been approved and the webrev can be found at http://cr.openjdk.java.net/~lancea/8144082/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Tue Dec 22 21:23:41 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 22 Dec 2015 13:23:41 -0800 Subject: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty In-Reply-To: <5679AD65.6030107@Oracle.com> References: <56735284.6060203@oracle.com> <5678709E.9040609@Oracle.com> <56789536.8050102@oracle.com> <5679AD65.6030107@Oracle.com> Message-ID: <5679BF5D.7020006@oracle.com> Thanks Roger! Joe On 12/22/2015 12:07 PM, Roger Riggs wrote: > Hi Joe, > > Thanks for the updates. Looks fine. > > Roger > > > On 12/21/2015 7:11 PM, huizhe wang wrote: >> Thanks Roger! >> >> On 12/21/2015 1:35 PM, Roger Riggs wrote: >>> Hi Joe, >>> >>> A few comments: >>> >>> InputSource: >> >> I assume you meant javax.xml.transform.Source (there was an error in >> Source's javadoc where the return statement referred to it as >> InputSource). >> >>> - Should the default method return true? The default method is only >>> present >>> to allow source compatibility with unknown subtypes. I would >>> expect that without >>> any specific implementation knowledge it would need to be false. >>> All of the JDK provided Sources will implement isEmpty appropriately. >> >> Changed to throw UOE now as Joe recommended. >> >>> >>> - Editorial: "Empty means that there is no input available from >>> this Source". >> >> Fixed. >>> >>> - from the definition and implementation it seems that isEmpty will >>> be true >>> when a stream (streamSource) is positioned just before EOF. Is >>> that intended? >> >> Yes. In general, a Source object shall be passed to a processor with >> input positioned at the beginning. If for some reason it's not, the >> Source object will not handle the situation. >>> >>> >>> stream/StreamSource: >>> - Does not need to check both sources; if the first source has any >>> input, return false immediately. >> >> Fixed. >>> >>> - the choice to return false when an IOException occurs seems odd; >>> if reading throws an exception then it seems unlikely that any >>> future read could work; >>> and hence there is no more input. >> >> It's true no future read would work. But since a Source object can be >> used in various situations where "empty" and failure to read are >> treated differently by the processor, the isEmpty method needs to >> abort its process, return false to indicate it's not empty, thus >> allow the processor to handle the error. >> >> I added a statement to the spec. >> >>> >>> - Note also that you probably need separate try/catch handlers for >>> the stream vs the reader. >>> An exception from reading the inputStream should no preempt the >>> reader. >> >> As discussed above, in case of error, isEmpty will abort its process >> and return false. >> >>> >>> sax/InputSource: >>> - ditto the comments above. >>> >>> In the test: >>> - This test is duplicated: >>> >>> + "{new SAXSource(new InputSource(new StringReader("")))}, >>> + {new SAXSource(new InputSource(new StringReader("")))}, >> >> Fixed. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ >> >> Thanks, >> Joe >> >>> >>> >>> Roger >>> >>> >>> On 12/17/2015 7:25 PM, huizhe wang wrote: >>>> Hi, >>>> >>>> Adding a convenient method isEmpty to javax.xml.transform.Source >>>> and org.xml.sax.InputSource. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8144967 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144967/webrev/ >>>> >>>> Thanks, >>>> Joe >>>> >>> >> > From huizhe.wang at oracle.com Tue Dec 22 21:25:33 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 22 Dec 2015 13:25:33 -0800 Subject: RFR: 8144082: Add Statement.enquoteNCharLiteral In-Reply-To: <04F3530F-B72A-4FD6-BFC4-896DDF28C847@oracle.com> References: <04F3530F-B72A-4FD6-BFC4-896DDF28C847@oracle.com> Message-ID: <5679BFCD.8020101@oracle.com> Looks good. A minor typo in the test: + * Validate a NullPointerException is thrown is the string passed to the 2nd "is" --> "if" Best, Joe On 12/22/2015 12:59 PM, Lance Andersen wrote: > Happy Tuesday, > > Need a reviewer for 8144082 which adds Statement.enquoteNCharLiteral. The CCC has been approved and the webrev can be found at http://cr.openjdk.java.net/~lancea/8144082/webrev.00/ > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Tue Dec 22 21:52:33 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Dec 2015 16:52:33 -0500 Subject: RFR: 8144082: Add Statement.enquoteNCharLiteral In-Reply-To: <5679BFCD.8020101@oracle.com> References: <04F3530F-B72A-4FD6-BFC4-896DDF28C847@oracle.com> <5679BFCD.8020101@oracle.com> Message-ID: <8F867EC0-CB09-422F-9E1C-59638D540168@oracle.com> Thank you for catching the typo Joe?. I will fix that before pushing Best Lance On Dec 22, 2015, at 4:25 PM, huizhe wang wrote: > Looks good. A minor typo in the test: > > + * Validate a NullPointerException is thrown is the string passed to > > the 2nd "is" --> "if" > > > Best, > Joe > > > On 12/22/2015 12:59 PM, Lance Andersen wrote: >> Happy Tuesday, >> >> Need a reviewer for 8144082 which adds Statement.enquoteNCharLiteral. The CCC has been approved and the webrev can be found at http://cr.openjdk.java.net/~lancea/8144082/webrev.00/ >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From miroslav.kos at oracle.com Wed Dec 23 14:14:32 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Wed, 23 Dec 2015 15:14:32 +0100 Subject: RFR [9]: 8146086 Publishing two webservices on same port fails with "java.net.BindException: Address already in use" Message-ID: <567AAC48.6010008@oracle.com> Hi everybody, I'd like to ask for review of . This simple patch allows publishing more webeservices on same port. The fix has been submitted by Kubota Yuji, it is already integrated in standalone JAX-WS repo, regression test added. JBS: https://bugs.openjdk.java.net/browse/JDK-8146086 jaxws patch: http://cr.openjdk.java.net/~mkos/8146086/jaxws.00/ test: http://cr.openjdk.java.net/~mkos/8146086/jdk.00/ Thanks Miran From scolebourne at joda.org Wed Dec 23 15:20:06 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Dec 2015 15:20:06 +0000 Subject: Producing streams in java.time? In-Reply-To: <851620702.20151210223156@gmail.com> References: <851620702.20151210223156@gmail.com> Message-ID: JSR-310 was developed in parallel with the Stream API. While we briefly considered adding some stream methods, it wasn't obvious what would be of value. A key question is whether the methods are either specific to a narrow use case or more general. Specific methods like months() on Year are very limited. You'd need: Year::months() Year::dates() YearMonth::dates() Only three methods, so not too bad. There would be some use cases, but enough to include them? Not sure. A method that provides all days between two dates: Stream datesUntil(LocalDate endExclusive); would have some value as it is more common and trickier to write. A method that provides Period addition looping might make more sense: Stream datesUntil(LocalDate endExclusive, Period step); This is actually quite hard to write correctly, as it requires multiplying the period by the loop index, not adding the period each time (to handle end-of-month effects). But where to stop? Stream instantsUntil(Instant endExclusive, Duration step); Stream instantsUntil(Instant endExclusive, Duration step); Stream instantsUntil(Instant endExclusive, Duration step); ... I think the place to start is the two methods on LocalDate which are tricky enough to be justified. Then perhaps the methods on Year/YearMonth. Stephen On 10 December 2015 at 16:31, Tagir F. Valeev wrote: > - in class Year: > > // Returns sequential ordered stream of all months within this Year: > Stream months(); > // Returns sequential ordered stream of all days within this Year: > Stream days(); > // Returns sequential ordered stream of all years starting from this > // Year until the supplied year, exclusive > Stream yearsUntil(Temporal endExclusive); > > - in class YearMonth: > > // Returns sequential ordered stream of all days within this YearMonth: > Stream days(); > // Returns sequential ordered stream of all months starting from this > // YearMonth until the supplied YearMonth, exclusive > Stream monthsUntil(Temporal endExclusive); > > - in class LocalDate: > > // Returns sequential ordered stream of all months starting from this > // LocalDate until the supplied LocalDate, exclusive > Stream daysUntil(Temporal endExclusive); > > The implementation of these methods could be quite simple. For example: > > class Year { > public Stream days() { > return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); > } > } > > What do you think? > > With best regards, > Tagir Valeev. > From Roger.Riggs at Oracle.com Wed Dec 23 18:19:19 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 23 Dec 2015 13:19:19 -0500 Subject: RFR:8143413:add toEpochSecond methods for efficient access In-Reply-To: References: <565C37F5.9040401@oracle.com> <565C923A.5020803@oracle.com> <565CA527.8010401@oracle.com> <565CD731.5050706@oracle.com> <565DACFE.10801@Oracle.com> <565DDA04.7040802@oracle.com> <5660BD9A.2030705@oracle.com> <5672FB62.9090608@oracle.com> <567902DF.6090501@oracle.com> Message-ID: <567AE5A7.3040709@Oracle.com> +1 Roger On 12/22/2015 9:53 AM, Stephen Colebourne wrote: > Fine by me, thanks > Stephen > > > On 22 December 2015 at 07:59, nadeesh tv wrote: >> Hi all, >> >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8143413/webrev.04/ >> >> Changes : Included the changes suggested by Stephen >> >> Thanks and Regards, >> Nadeesh >> >> >> On 12/22/2015 12:30 AM, Stephen Colebourne wrote: >>> The comment for the new LocalDate.EPOCH field should use 1970-01-01, >>> not 1970-1-1. However, the code should omit the zeroes: >>> Replace: >>> LocalDate.of(1970, 01, 01) >>> with >>> LocalDate.of(1970, 1, 1) >>> >>> The new method should follow the documentation of the similar method >>> on ChronoLocalDateTime: >>> >>> * This combines this local date with the specified time and >>> offset to calculate the >>> * epoch-second value, which is the number of elapsed seconds from >>> 1970-01-01T00:00:00Z. >>> * Instants on the time-line after the epoch are positive, earlier >>> are negative. >>> >>> The same applies to the new method on LocalTime: >>> >>> * This combines this local time with the specified date and >>> offset to calculate the >>> * epoch-second value, which is the number of elapsed seconds from >>> 1970-01-01T00:00:00Z. >>> * Instants on the time-line after the epoch are positive, earlier >>> are negative. >>> >>> The same applies to the new method on OffsetTime: >>> >>> * This combines this offset time with the specified date to >>> calculate the >>> * epoch-second value, which is the number of elapsed seconds from >>> 1970-01-01T00:00:00Z. >>> * Instants on the time-line after the epoch are positive, earlier >>> are negative. >>> >>> The test cases look good. >>> >>> thanks >>> Stephen >>> >>> >>> On 17 December 2015 at 18:13, nadeesh tv wrote: >>>> Hi all, >>>> >>>> Please see the updated webrev >>>> http://cr.openjdk.java.net/~ntv/8143413/webrev.03/ >>>> >>>> Thanks and Regards, >>>> Nadeesh >>>> >>>> On 12/4/2015 3:56 AM, Stephen Colebourne wrote: >>>>> In the interests of harmony and getting something in, I'll accept that. >>>>> >>>>> I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY >>>>> >>>>> Stephen >>>>> >>>>> >>>>> >>>>> On 3 December 2015 at 22:09, Roger Riggs wrote: >>>>>> Hi Sherman, >>>>>> >>>>>> It makes sense to me to provide the missing time/date as an explicit >>>>>> parameter >>>>>> for toEpochSeconds instead of assuming some constant. >>>>>> >>>>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); >>>>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC); >>>>>> offsetTime.toEpochSeconds(LocalDate.EPOCHDAY); >>>>>> >>>>>> We'll have to add the LocalDate.EPOCHDAY constant. >>>>>> >>>>>> It makes it a bit heavier weight to use but can still be optimized and >>>>>> won't >>>>>> create garbage. >>>>>> >>>>>> Roger >>>>>> >>>>>> >>>>>> >>>>>> On 12/01/2015 12:33 PM, Xueming Shen wrote: >>>>>>> On 12/1/15 6:36 AM, Stephen Colebourne wrote: >>>>>>>> As Roger says, these new methods are about performance as well as >>>>>>>> conversion. >>>>>>>> >>>>>>>> While I fully acknowledge the time methods make an assumption, it is >>>>>>>> not a crazy one, after all 1970-01-01 is just zero. >>>>>>>> >>>>>>>> Key I think is it allows: >>>>>>>> long epochSecs = date.toEpochSeconds(offset) + >>>>>>>> time.toEpochSeconds(offset); >>>>>>>> to efficiently merge two objects without garbage. >>>>>>> So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean >>>>>>> approach >>>>>>> >>>>>>> LocalDate date = ... >>>>>>> LocalDate time = ... >>>>>>> ZoneOffset offset = ... >>>>>>> >>>>>>> ==> long spochSecs = LocalDateTime.of(date, >>>>>>> time).toEpochSeconds(offset); >>>>>>> >>>>>>> we are adding APIs to provide a "fastpath" with the special assumption >>>>>>> that the LocalDate "date" >>>>>>> here is actually a "LocalDateTime" object ("date" + >>>>>>> LocalTime.MIDNIGHT) >>>>>>> and the LocalTime "time" >>>>>>> again actually means a "LocalDateTime" (the "time" of 1970-01-01), to >>>>>>> let >>>>>>> the third party "libraries" >>>>>>> to fool the basic date/time abstract in java.time package, simply to >>>>>>> avoid creating the garbage >>>>>>> middle man, localDateTime? it really does not sound right to me. >>>>>>> >>>>>>> First, if someone needs to mix/link LocalDate, LocalTime and Offset to >>>>>>> epoch seconds in their >>>>>>> libraries, they really SHOULD think hard about the conversion and make >>>>>>> it >>>>>>> right (it should not >>>>>>> be encouraged to use these classes LocalDate, LocalTime and Offset >>>>>>> without >>>>>>> even understand >>>>>>> what these classes are). But if we really have to provide such >>>>>>> fastpath, >>>>>>> personally I think it might >>>>>>> be better either to provide these "utility/convenient" methods in a >>>>>>> "utilities" class, or with an >>>>>>> explicit date/time parameters (instead of the false assumption) for >>>>>>> the >>>>>>> missing date/time piece, >>>>>>> such as >>>>>>> >>>>>>> localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset); >>>>>>> localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset); >>>>>>> >>>>>>> Sherman >>>>>>> >>>>>>> >>>>>>>> It also means that no-one has to think hard about the conversion, as >>>>>>>> it is just there. It tends to be when people try to work this stuff >>>>>>>> out for themselves that they get it wrong. >>>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> On 1 December 2015 at 14:21, Roger Riggs >>>>>>>> wrote: >>>>>>>>> Hi Sherman, >>>>>>>>> >>>>>>>>> On 11/30/2015 6:09 PM, Xueming Shen wrote: >>>>>>>>>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote: >>>>>>>>>>> Converting LocalDate<-> java.util.Date is the question with the >>>>>>>>>>> largest number of votes on SO: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 >>>>>>>>>>> The proposed method is designed to make the conversion easier. It >>>>>>>>>>> also >>>>>>>>>>> plugs an obvious gap in the API. >>>>>>>>>>> >>>>>>>>>>> While the LocalTime/OffsetTime methods are of lower importance, >>>>>>>>>>> not >>>>>>>>>>> having them would result in inconsistency between the various >>>>>>>>>>> classes. >>>>>>>>>>> We've already added factory methods to LocalTime for Java 9, these >>>>>>>>>>> are >>>>>>>>>>> just the other half of the picture. >>>>>>>>>>> >>>>>>>>>> I'm not sure I understand the idea of "the proposed method is >>>>>>>>>> designed >>>>>>>>>> to >>>>>>>>>> make the conversion easier", as the SO is mainly about >>>>>>>>>> j.u.Date->LocalDate, >>>>>>>>>> not the other way around, from LocalDate -> j.u.Date. >>>>>>>>> I think the issue is about *other* libraries that manipulate time >>>>>>>>> via >>>>>>>>> epochSeconds >>>>>>>>> not about j.u.Date conversions. The concern was about performance >>>>>>>>> and >>>>>>>>> creating garbage along the way. >>>>>>>>> >>>>>>>>> Roger >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> As I said in the previous email, it might be "common" to use the >>>>>>>>>> j.u.Date >>>>>>>>>> to >>>>>>>>>> abstract a "local date" and/or a "local time" (no other choice) >>>>>>>>>> before >>>>>>>>>> java.time, >>>>>>>>>> and now there is the need to provide a migration path from those >>>>>>>>>> "local >>>>>>>>>> date/ >>>>>>>>>> time" to the j.t.LocalDate/Time. But convert backward from the new >>>>>>>>>> date/time >>>>>>>>>> type to the "old" j.u.Date should not be encouraged (guess this is >>>>>>>>>> also >>>>>>>>>> the >>>>>>>>>> consensus we agreed on back to jsr203). >>>>>>>>>> >>>>>>>>>> What are the "factory methods" you are referring to here? >>>>>>>>>> JDK-8133079, >>>>>>>>>> The >>>>>>>>>> LocalDate/LocalTime.ofInstant()? >>>>>>>>>> (btw, these two methods see missing the "since 1.9/9" tag) >>>>>>>>>> >>>>>>>>>> It seems to me that the ofInstant(Instant, ZondId) is from a >>>>>>>>>> "super-set" >>>>>>>>>> of >>>>>>>>>> date/time to a "sub-set", without any assumption of "default >>>>>>>>>> value", >>>>>>>>>> it >>>>>>>>>> is >>>>>>>>>> similar to the conversion from zdt->ldt->ld/lt, and I can see the >>>>>>>>>> "small" >>>>>>>>>> improvement >>>>>>>>>> >>>>>>>>>> from| >>>>>>>>>> Date input = new Date(); >>>>>>>>>> LocalDatedate >>>>>>>>>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();| >>>>>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> |LocalDatedate >>>>>>>>>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));| >>>>>>>>>> >>>>>>>>>> The proposed pair toEpochSecond() however is doing the other way >>>>>>>>>> around >>>>>>>>>> and >>>>>>>>>> with an unusual assumption of the missing date/time piece to a >>>>>>>>>> "default >>>>>>>>>> value" >>>>>>>>>> (midnight, the epoch day). >>>>>>>>>> >>>>>>>>>> personally I think >>>>>>>>>> >>>>>>>>>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset); >>>>>>>>>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset); >>>>>>>>>> >>>>>>>>>> is clean and good enough to help this backward conversion (with the >>>>>>>>>> addition >>>>>>>>>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help >>>>>>>>>> to >>>>>>>>>> remove that LocalDateTime middle man, with some arrangement. >>>>>>>>>> >>>>>>>>>> -Sherman >>>>>>>>>> >>>>>>>>>>> Note that these methods are specifically not referencing >>>>>>>>>>> java.util.Date itself. Epoch seconds is the appropriate >>>>>>>>>>> intermediate >>>>>>>>>>> form here, and still widely used. >>>>>>>>>>> >>>>>>>>>>> Stephen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 30 November 2015 at 19:36, Xueming >>>>>>>>>>> Shen >>>>>>>>>>> wrote: >>>>>>>>>>>> On 11/30/2015 10:37 AM, Stephen Colebourne wrote: >>>>>>>>>>>>> This is based on user difficulties picked up via Stack Overflow. >>>>>>>>>>>>> These >>>>>>>>>>>>> methods aim to provide a simpler and faster approach, >>>>>>>>>>>>> particularly >>>>>>>>>>>>> for >>>>>>>>>>>>> cases converting to/from java.util.Date. >>>>>>>>>>>> Can you be a little more specific on this one? We now have >>>>>>>>>>>> Instance<=> >>>>>>>>>>>> Date, >>>>>>>>>>>> and considerably we might add LocalDateTime<=> Date with an >>>>>>>>>>>> offset, >>>>>>>>>>>> if >>>>>>>>>>>> really >>>>>>>>>>>> really desired (for performance? to save a Instant object as the >>>>>>>>>>>> bridge?). >>>>>>>>>>>> But I'm >>>>>>>>>>>> a little confused about the connection among LocalDate/LocalTime, >>>>>>>>>>>> epoch >>>>>>>>>>>> seconds >>>>>>>>>>>> and j.u.Date here. Are you saying someone wants to convert >>>>>>>>>>>> >>>>>>>>>>>> j.t.LocalDate -> epoch seconds -> j.u.Date >>>>>>>>>>>> j.t.LocalTime -> epoch seconds -> j.u.Date >>>>>>>>>>>> >>>>>>>>>>>> and uses the converted j.u.Date to represent a local date (date >>>>>>>>>>>> with >>>>>>>>>>>> time >>>>>>>>>>>> part to >>>>>>>>>>>> be 0) and/or the local time (with year/month/day to be epoch >>>>>>>>>>>> time) >>>>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> "old" >>>>>>>>>>>> system which only has j.u.Date, and has to use the j.u.Date to >>>>>>>>>>>> abstract >>>>>>>>>>>> the >>>>>>>>>>>> "local >>>>>>>>>>>> date" and "local time"? >>>>>>>>>>>> >>>>>>>>>>>> I think we agreed back to JSR310 that we don't try to add such >>>>>>>>>>>> kind >>>>>>>>>>>> of >>>>>>>>>>>> "bridge/ >>>>>>>>>>>> convenient/utility" methods into the new java.time package, but >>>>>>>>>>>> only >>>>>>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> old date/calendar classes, if really needed. So if these methods >>>>>>>>>>>> are >>>>>>>>>>>> only to >>>>>>>>>>>> help >>>>>>>>>>>> migrate/bridge between the "old" and "new" calendar systems, the >>>>>>>>>>>> java.time >>>>>>>>>>>> might not be the best place for them? >>>>>>>>>>>> >>>>>>>>>>>>> For the time cases, the convention of 1970-01-01 is natural and >>>>>>>>>>>>> commonly used in many codebases. >>>>>>>>>>>>> >>>>>>>>>>>> I'm not sure about that, especially the "natural" part. It might >>>>>>>>>>>> be >>>>>>>>>>>> "common" >>>>>>>>>>>> in >>>>>>>>>>>> the old days if you only have j.u.Date", and might be forced to >>>>>>>>>>>> use >>>>>>>>>>>> 1970-01-01 >>>>>>>>>>>> to fill in the "date" part even when you are really only >>>>>>>>>>>> interested >>>>>>>>>>>> in >>>>>>>>>>>> "time" part >>>>>>>>>>>> of it in your app. One of the advantage of java.time.LDT/LD/LT is >>>>>>>>>>>> now >>>>>>>>>>>> we >>>>>>>>>>>> have >>>>>>>>>>>> separate abstract for these different need, I don't see the >>>>>>>>>>>> common >>>>>>>>>>>> need >>>>>>>>>>>> of >>>>>>>>>>>> having a LocalTime only meas the "local time" of 1970-01-01, or I >>>>>>>>>>>> misunderstood >>>>>>>>>>>> something here. >>>>>>>>>>>> >>>>>>>>>>>> -Sherman >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Stephen >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 November 2015 at 18:15, Xueming >>>>>>>>>>>>> Shen >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> While it is kinda understandable to have >>>>>>>>>>>>>> LocalDate.toEpochSecond(...) >>>>>>>>>>>>>> to get the epoch seconds since 1970.1.1, with the assumption of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> time is at the midnight of that day. It is strange to have the >>>>>>>>>>>>>> Local/OffsetTime >>>>>>>>>>>>>> to have two public methods with the assumption of the "date" is >>>>>>>>>>>>>> at >>>>>>>>>>>>>> epoch >>>>>>>>>>>>>> year/month/day. What's the use case/scenario for these two >>>>>>>>>>>>>> proposed >>>>>>>>>>>>>> methods? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Sherman >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote: >>>>>>>>>>>>>>> The method Javadoc (specs) for each of the three new methods >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> be enhanced. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the date ones it needs to say >>>>>>>>>>>>>>> "The resulting date will have a time component of midnight at >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> start of the day." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the time ones it needs to say >>>>>>>>>>>>>>> "The resulting time will be on 1970-01-01." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some of the line wrapping in the tests looks like it is not >>>>>>>>>>>>>>> indented >>>>>>>>>>>>>>> correctly. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise looks fine, >>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>> Stephen >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30 November 2015 at 11:50, nadeesh >>>>>>>>>>>>>>> tv >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Issue - add toEpochSecond methods for efficient access >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> webrev -http://cr.openjdk.java.net/~ntv/8143413/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Thanks and Regards, >>>>>>>>>>>>>>>> Nadeesh TV >>>>>>>>>>>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> -- >> Thanks and Regards, >> Nadeesh TV >> From philip.race at oracle.com Wed Dec 23 19:36:42 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 Dec 2015 11:36:42 -0800 Subject: RFR: 8145388: URLConnection.guessContentTypeFromStream returns image/jpg for some JPEG images In-Reply-To: <2d0ba104-166a-4131-b9a0-208a0785ad41@default> References: <2d0ba104-166a-4131-b9a0-208a0785ad41@default> Message-ID: <567AF7CA.3090007@oracle.com> Looks OK to me. I don't know why the difference but it goes back to JDK 1.1 -phil. On 12/22/2015 10:48 AM, Ramanand Patil wrote: > HI all, > > > > Please review this small fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145388 > > > > Bug Description - For some JPEG images the method java.net.URLConnection#guessContentTypeFromStream will return the MIME type image/jpg, which is not a valid, registered IANA mime type for JPEG images. > > > > Webrev - http://cr.openjdk.java.net/~ntv/ramanand/8145388/webrev.00/ > > > > Fix - Since "image/jpg" is not a valid Content Type, the method should return "image/jpeg" when APPn marker segment has 'EE' as a marker type. > > > > > > Regards, > > Ramanand. > > From brian.burkhalter at oracle.com Wed Dec 23 19:54:14 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 23 Dec 2015 11:54:14 -0800 Subject: JDK 9 RFR of 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams Message-ID: <777B9A9D-81F2-4B1E-B484-3BA6DC65729B@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8146041 Patch: http://cr.openjdk.java.net/~bpb/8146041/webrev.00/ Summary: Add recognition of TIFF header to guessContentTypeFromStream() and a test to verify that it works. Note that this change will not be integrated until after the one discussed in http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037832.html has been pushed. Thanks, Brian From Roger.Riggs at Oracle.com Wed Dec 23 20:48:25 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 23 Dec 2015 15:48:25 -0500 Subject: JDK 9 RFR of 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams In-Reply-To: <777B9A9D-81F2-4B1E-B484-3BA6DC65729B@oracle.com> References: <777B9A9D-81F2-4B1E-B484-3BA6DC65729B@oracle.com> Message-ID: <567B0899.4000506@Oracle.com> Hi Brian, Without any particular domain knowledge, this looks fine. Roger On 12/23/2015 2:54 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8146041 > Patch: http://cr.openjdk.java.net/~bpb/8146041/webrev.00/ > > Summary: > Add recognition of TIFF header to guessContentTypeFromStream() and a test to verify that it works. > > Note that this change will not be integrated until after the one discussed in http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037832.html has been pushed. > > Thanks, > > Brian From brian.burkhalter at oracle.com Wed Dec 23 20:53:13 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 23 Dec 2015 12:53:13 -0800 Subject: JDK 9 RFR of 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams In-Reply-To: <567B0899.4000506@Oracle.com> References: <777B9A9D-81F2-4B1E-B484-3BA6DC65729B@oracle.com> <567B0899.4000506@Oracle.com> Message-ID: <97CA2763-655C-4D3C-807A-B67FB1758372@oracle.com> Thanks, Roger. It is supposed to detect the first 4 bytes according to this specification: https://en.wikipedia.org/wiki/Tagged_Image_File_Format#Byte_order Brian On Dec 23, 2015, at 12:48 PM, Roger Riggs wrote: > Without any particular domain knowledge, this looks fine. From huizhe.wang at oracle.com Wed Dec 23 22:55:10 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 23 Dec 2015 14:55:10 -0800 Subject: RFR (JAXP): 8144966: Catalog API: Null handling and reference to Reader Message-ID: <567B264E.1020502@oracle.com> Hi, This is an improvement to the new Catalog API on null handling. At the package level, a null argument shall result in NPE. However, an exception was made to the methods in CatalogManager so that they can used conveniently. With this request, we're in favor of consistency over the minor convenience, which means a resolver can no longer be created by: CatalogManager.catalogResolver(null); Instead, the following may be used to achieve the same result: CatalogManager.catalogResolver(CatalogFeatures.defaults()); While path can be empty, it can no longer be null. The following then would also get a NPE: CatalogManager.catalogResolver(CatalogFeatures.defaults(), null); In consistence with ignoring invalid catalogs as required by the Catalog standard, the statements that required CatalogException when no catalog is found are removed. JBS: https://bugs.openjdk.java.net/browse/JDK-8144966 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8144966/webrev/ Please review. Thanks, Joe From peter.levart at gmail.com Thu Dec 24 09:52:13 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Dec 2015 10:52:13 +0100 Subject: Producing streams in java.time? In-Reply-To: <851620702.20151210223156@gmail.com> References: <851620702.20151210223156@gmail.com> Message-ID: <567BC04D.2020503@gmail.com> Hi, What would really be nice to have is a Stream produced from Recurrence Rule specified as a String: http://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html Think of it as a built-in DSL like regex Pattern, but for generating arbitrary recurrences. But this deserves an entire new class I think. Regards, Peter On 12/10/2015 05:31 PM, Tagir F. Valeev wrote: > Hello! > > Currently it seems that java.time package does not use Stream API in > any way. I think it would be nice to add some methods which produce > the streams. For example: > > - in class Year: > > // Returns sequential ordered stream of all months within this Year: > Stream months(); > // Returns sequential ordered stream of all days within this Year: > Stream days(); > // Returns sequential ordered stream of all years starting from this > // Year until the supplied year, exclusive > Stream yearsUntil(Temporal endExclusive); > > - in class YearMonth: > > // Returns sequential ordered stream of all days within this YearMonth: > Stream days(); > // Returns sequential ordered stream of all months starting from this > // YearMonth until the supplied YearMonth, exclusive > Stream monthsUntil(Temporal endExclusive); > > - in class LocalDate: > > // Returns sequential ordered stream of all months starting from this > // LocalDate until the supplied LocalDate, exclusive > Stream daysUntil(Temporal endExclusive); > > The implementation of these methods could be quite simple. For example: > > class Year { > public Stream days() { > return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); > } > } > > What do you think? > > With best regards, > Tagir Valeev. > From amaembo at gmail.com Sat Dec 26 16:29:13 2015 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sat, 26 Dec 2015 22:29:13 +0600 Subject: RFR:8146218: Producing streams in java.time? In-Reply-To: References: <851620702.20151210223156@gmail.com> Message-ID: <1461285505.20151226222913@gmail.com> Hello! Thank you for your comments. I logged an issue: https://bugs.openjdk.java.net/browse/JDK-8146218 And prepared a patch: http://amaembo.github.io/cr/8146218/webrev-1/ (sorry for not using official code-review server, I cannot access it currently, hopefully this problem will be solved soon). Please review, especially the specification: English is not my native language. The patch introduces two methods in LocalDate class: datesUntil(LocalDate endExclusive) and datesUntil(LocalDate endExclusive, Period step). The implementation of the former one is just a one-liner. I decided to produce an empty stream if endExclusive is before than this to stay in sync with IntStream.range/LongStream.range. The latter method is more tricky. It could be implemented using the takeWhile() method, but I wanted to make the sized stream, so it can parallelize perfectly and its count method is guaranteed to work in constant time (see JDK-8067969). Thus it's necessary to precompute exactly the size of the stream. Zero and negative periods are not supported. On the one hand it might be useful in some scenarios (assuming the ending date is before the start date). On the other hand it's possible to define some weird period like Period.of(0,1,-30) which may go in both directions depending on current date. Period like Period.of(400,0,-146097) is equivalent to ZERO, so it would never advance, but isZero would return false (and even normalization will not help). Theoretically it's possible to handle all such cases, but it would make the method and its specification much more complex. Thus I would like to disable negative periods at all. Though I'm open to discussion. Probably I added too many test cases. If it poses the problem I may try to reduce the number of tests. With best regards, Tagir Valeev. SC> JSR-310 was developed in parallel with the Stream API. While we SC> briefly considered adding some stream methods, it wasn't obvious what SC> would be of value. SC> A key question is whether the methods are either specific to a narrow SC> use case or more general. Specific methods like months() on Year are SC> very limited. You'd need: SC> Year::months() SC> Year::dates() SC> YearMonth::dates() SC> Only three methods, so not too bad. There would be some use cases, but SC> enough to include them? Not sure. SC> A method that provides all days between two dates: SC> Stream datesUntil(LocalDate endExclusive); SC> would have some value as it is more common and trickier to write. SC> A method that provides Period addition looping might make more sense: SC> Stream datesUntil(LocalDate endExclusive, Period step); SC> This is actually quite hard to write correctly, as it requires SC> multiplying the period by the loop index, not adding the period each SC> time (to handle end-of-month effects). SC> But where to stop? SC> Stream instantsUntil(Instant endExclusive, Duration step); SC> Stream instantsUntil(Instant endExclusive, Duration step); SC> Stream instantsUntil(Instant endExclusive, Duration step); SC> ... SC> I think the place to start is the two methods on LocalDate which are SC> tricky enough to be justified. Then perhaps the methods on SC> Year/YearMonth. SC> Stephen SC> On 10 December 2015 at 16:31, Tagir F. Valeev wrote: >> - in class Year: >> >> // Returns sequential ordered stream of all months within this Year: >> Stream months(); >> // Returns sequential ordered stream of all days within this Year: >> Stream days(); >> // Returns sequential ordered stream of all years starting from this >> // Year until the supplied year, exclusive >> Stream yearsUntil(Temporal endExclusive); >> >> - in class YearMonth: >> >> // Returns sequential ordered stream of all days within this YearMonth: >> Stream days(); >> // Returns sequential ordered stream of all months starting from this >> // YearMonth until the supplied YearMonth, exclusive >> Stream monthsUntil(Temporal endExclusive); >> >> - in class LocalDate: >> >> // Returns sequential ordered stream of all months starting from this >> // LocalDate until the supplied LocalDate, exclusive >> Stream daysUntil(Temporal endExclusive); >> >> The implementation of these methods could be quite simple. For example: >> >> class Year { >> public Stream days() { >> return IntStream.rangeClosed(1, length()).mapToObj(this::atDay); >> } >> } >> >> What do you think? >> >> With best regards, >> Tagir Valeev. >> From cushon at google.com Mon Dec 21 20:42:09 2015 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 21 Dec 2015 12:42:09 -0800 Subject: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present Message-ID: If an annotation value is an array of class literals or enum constants, calling Class.getAnnotation() fails with ArrayStoreException if the element type is not found. This patch implements the proposed fix from the bug thread, which allows getAnnotation() to succeed and a TypeNotPresentException to be thrown from Annotation.value(). bug: https://bugs.openjdk.java.net/browse/JDK-7183985 The patch is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 7183985.patch Type: text/x-patch Size: 13219 bytes Desc: not available URL: