RFR: 8140325 Incorrect package.html file

A couple of small fixes for duplicate tags in HTML files. Full webrev: http://cr.openjdk.java.net/~jjg/8140325/webrev.00/ Diffs here: diff -r d93844d0cdd5 src/java.base/share/classes/overview-core.html --- a/src/java.base/share/classes/overview-core.htmlThu Oct 22 11:36:17 2015 -0400 +++

Re: RFR: 8140325 Incorrect package.html file

Looks good Jon, -Joe On 10/22/2015 10:23 AM, Jonathan Gibbons wrote: A couple of small fixes for duplicate tags in HTML files. Full webrev: http://cr.openjdk.java.net/~jjg/8140325/webrev.00/ Diffs here: diff -r d93844d0cdd5 src/java.base/share/classes/overview-core.html ---

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

Hi, Thanks for the insight. I'd like to note that I'm not concerned about the reachability of the Reference object itself (program code takes care of that - for example in Cleaner API it hooks Reference objects into a doubly-linked list exactly for them to stay reachable until discovered by

Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

It's unlikely there would be a safepoint between those two statements in compiled code. Polls are typically placed at method exit (modulo polls inserted for some types of loops, but that's irrelevant to this instance). With inlining, the poll distance is likely to increase as well. However,

Re: 8139891: Prepare Unsafe for true encapsulation

> On Oct 22, 2015, at 6:31 AM, Paul Sandoz wrote: > > Hi Chris, > > This looks like a good first step. I am sure hotspot devs will have more > concrete review comments, but i like the way the method aliasing (copying the > same technique StrictMath -> Math) avoids any

Re: 8139891: Prepare Unsafe for true encapsulation

On Oct 22, 2015, at 7:28 AM, Chris Hegarty wrote: > > To this end I've put together a webrev containing the changes required > for step 1. It contains > - the intrinsic aliasing, > - the new internal Unsafe ( copy of sun.misc.Unsafe ), > - reverts sun.misc.Unsafe

Re: 8139891: Prepare Unsafe for true encapsulation

Hey Chris, I don’t like to say it but it sounds very wrong to have another Unsafe like thinggy in the future instead of providing public alternatives right from the start. I agree it might be a faster to just write adapter classes and I really don’t like to repeat what I said in the past but

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

On 22/10/15 14:24, Alan Bateman wrote: On 22/10/2015 14:04, Roger Riggs wrote: Hi Sandhya, The folks on net-...@openjdk.java.net will be interested too. Yes, net-dev is the best list for this. One other thing to mention is the SocketOption interface and the setOption/getOption methods.

8139891: Prepare Unsafe for true encapsulation

As part of the preparation for JEP 260 [1], Unsafe needs to be separable from the base module [2], so it can be exported by a new, yet to be defined, jdk.unsupported module, and have a separate evolution policy that is not exposed. That is, the JDK needs an internal Unsafe that can be evolved and

Re: RFR: JDK-8046565: Platform Logger API and Service

(sorry for the delay. I realized just now that my reply is not sent … sigh) > On Oct 20, 2015, at 2:48 PM, Daniel Fuchs wrote: > > Hi Mandy, > > As we discussed I have also made LogManager.demandLoggerFor > package protected. As a result I also reverted the changes >

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

Hi Sandhya, The folks on net-...@openjdk.java.net will be interested too. Roger On 10/21/2015 9:08 PM, Viswanathan, Sandhya wrote: This is a proposal for adding SO_REUSEPORT support in JDK 9 for socket communication. The feature is supported since Linux Kernel 3.9 in OS. It is also

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

On 22/10/2015 14:04, Roger Riggs wrote: Hi Sandhya, The folks on net-...@openjdk.java.net will be interested too. Yes, net-dev is the best list for this. One other thing to mention is the SocketOption interface and the setOption/getOption methods. This allows for platform or JDK-specific

[RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

Hello, Please review the following fix for 8140189: http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk https://bugs.openjdk.java.net/browse/JDK-8140189 Please also see the following CR, which has much more

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

the following JBS item exists: https://bugs.openjdk.java.net/browse/JDK-6432031 search of windows documentation suggests that SO_REUSEPORT is still not an option man setsockopt on Solaris shows it as an option, but without precise description of semantics regards Mark On 22/10/2015 14:33,

Re: 8139891: Prepare Unsafe for true encapsulation

Hi Chris, This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. It may be worth

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

e docs? Again, go to nashorn/make and issue "ant dynalinkapi". You'll get the docs in nashorn/dist/javadoc directory. They should be quite comprehensive. For your convenience I also uploaded the docs to <http://cr.openjdk.java.net/~attila/jep276/javadoc.20151022/>