From hboehm at google.com Fri Apr 1 00:06:19 2016 From: hboehm at google.com (Hans Boehm) Date: Thu, 31 Mar 2016 17:06:19 -0700 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56FDB09A.7050108@cs.oswego.edu> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FDB09A.7050108@cs.oswego.edu> Message-ID: The expectation would be that such memory would still be mapped with the same caching behavior as normal memory, e.g. writeback-cacheable, so that it would follow normal Java memory model rules when accessed as normal memory? AFAICT, mapping any kind of memory with different caching behavior is likely to be highly problematic on most architectures. Hans On Thu, Mar 31, 2016 at 4:19 PM, Doug Lea

wrote: > On 03/31/2016 05:14 PM, Dohrmann, Steve wrote: > >> This is a JDK 9 proposal to support allocation of direct >> java.nio.ByteBuffer >> instances backed by memory other than off-heap RAM. >> > > I like it. Various kinds of heterogeneous memories are becoming more > common, and this seems like the simplest accommodation that at least > gets ByteBuffer functionality. > > With such a simple API, it is hard to imagine fundamental problems > fitting to other heterogeneous systems, but it would still be great > if anyone dealing with non-Intel systems (TI/KeyStone?) could > sanity-check this. > > I suspect some people would prefer a more elaborate SPI scheme, > but this seems fine to me: > > > package java.nio; >> >> interface Memory { public ByteBuffer allocateByteBuffer(int size); } >> >> Developers would obtain instances of these Memory objects by calling >> public >> constructors on specific memory classes. We propose having developers >> call >> constructors directly because it is a simple way to accommodate varying >> initialization requirements (e.g. partitioning) that specific memory >> instances may have. >> >> For uniformity, we propose mirroring the existing off-heap >> java.nio.ByteBuffer allocation through an off-heap RAM class that >> implements >> the Memory interface: >> >> package java.nio; >> >> public class OffHeapRAM implements Memory { @Override public ByteBuffer >> allocateByteBuffer(int size) { return ByteBuffer.allocateDirect(size); } } >> >> Uniform access could be extended to on-heap ByteBuffers with a class that >> wraps the non-direct allocation method in ByteBuffer: >> >> package java.nio; >> >> public class HeapRAM implements Memory { @Override public ByteBuffer >> allocateByteBuffer(int size) { return ByteBuffer.allocate(size); } } >> >> The 3 additions above are the only changes proposed. Links to a bug >> report >> and to a JDK 9 patch containing these additions are shown below. For >> sample >> code, we are also creating a class that implements the Memory interface >> for >> java.nio.ByteBuffers backed by Intel's 3D XPoint memory. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8153111 >> >> patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ >> >> While other useful capabilities in this space (e.g. persistent memory, >> process-shared memory) are being explored, they are specifically not >> addressed or proposed here. We believe that supporting >> java.nio.ByteBuffer >> allocation on other memory spaces is sufficiently useful to propose it now >> for JDK 9. >> >> Please let us know if there is interest in this proposal and if you would >> like to sponsor a patch. >> >> Best regards, Steve Dohrmann >> >> >> > From ecki at zusammenkunft.net Fri Apr 1 02:30:01 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 1 Apr 2016 04:30:01 +0200 Subject: AW: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> Message-ID: <56fddd2b.034cc20a.40b40.fffffef8@mx.google.com> Hello, I like the proposal. I wonder if minimal support for requesting ?keyed? memory locations should already be present. The absolute minimum here would be a long (representing any key scheme but of course most natural would be a slot counter or base address) Memory { ByteBuffer allocate(int size); ByteBuffer request(long slot, int size);} (by Definition each request will produce independent ByteBuffer instances but sharing the backing) This would work for shared memory segments and persistent ram. There might be a need to interrogate the buffers (to get base address or slot number when allocate was used). So it might be a good idea to introduce generic signatures: interface Memory { T allocate(int size); T request(long slot, int size); } ShmMemory implements Memory { ... } ShmByteBuffer b = new ShmMemory().allocate(1*MB); I have the feeling the concept is only a bit more complex but covers much more cases with less wild casting and non standard factories. I like the Memory name, an alternative would be BufferSupplier (with the idea it could also be used for logical buffer pools). Gruss Bernd -- http://bernd.eckenfels.net Von: Dohrmann, Steve Gesendet: Donnerstag, 31. M?rz 2016 23:25 An: core-libs-dev at openjdk.java.net Cc: Fan, Lei t; Deshpande, Vivek R; Kaczmarek, Eric Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory This is a JDK 9 proposal to support allocation of direct java.nio.ByteBuffer instances backed by memory other than off-heap RAM. The current allocateDirect() static method in java.nio.ByteBuffer is being used by some applications to meet special memory needs -- in particular, allocating large amounts of memory without contributing significantly to GC pause times. Other kinds of memory could offer advantages to such applications. For example, Intel's 3D XPoint memory offers large memory capacities that are more affordable than RAM and speeds that are much faster than NAND storage. Currently, there is no well-defined interface that can be used to offer a Java developer access to these other kinds of memory. Specifically, we propose adding a common memory interface that can be implemented by an open-ended set of memory classes. The interface would provide one method that allocates a java.nio.ByteBuffer on the memory associated with the specific memory instance. package java.nio; interface Memory { public ByteBuffer allocateByteBuffer(int size); } These ByteBuffers will have the same behavior as those allocated by the allocateDirect method in java.nio.ByteBuffer: 1) the ByteBuffer instance is managed on the Java heap, 2) the buffer's backing memory resides on whatever space the memory instance represents, and 3) the backing memory is automatically freed when the ByteBuffer object is garbage collected. Developers would obtain instances of these Memory objects by calling public constructors on specific memory classes. We propose having developers call constructors directly because it is a simple way to accommodate varying initialization requirements (e.g. partitioning) that specific memory instances may have. For uniformity, we propose mirroring the existing off-heap java.nio.ByteBuffer allocation through an off-heap RAM class that implements the Memory interface: package java.nio; public class OffHeapRAM implements Memory { @Override public ByteBuffer allocateByteBuffer(int size) { return ByteBuffer.allocateDirect(size); } } Uniform access could be extended to on-heap ByteBuffers with a class that wraps the non-direct allocation method in ByteBuffer: package java.nio; public class HeapRAM implements Memory { @Override public ByteBuffer allocateByteBuffer(int size) { return ByteBuffer.allocate(size); } } The 3 additions above are the only changes proposed. Links to a bug report and to a JDK 9 patch containing these additions are shown below. For sample code, we are also creating a class that implements the Memory interface for java.nio.ByteBuffers backed by Intel's 3D XPoint memory. bug: https://bugs.openjdk.java.net/browse/JDK-8153111 patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ While other useful capabilities in this space (e.g. persistent memory, process-shared memory) are being explored, they are specifically not addressed or proposed here. We believe that supporting java.nio.ByteBuffer allocation on other memory spaces is sufficiently useful to propose it now for JDK 9. Please let us know if there is interest in this proposal and if you would like to sponsor a patch. Best regards, Steve Dohrmann From mandy.chung at oracle.com Fri Apr 1 04:07:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Mar 2016 21:07:33 -0700 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <56F96778.5020202@gmail.com> References: <56B72242.7050102@gmail.com> <56B874DA.80001@gmail.com> <56B9EB17.7020303@oracle.com> <56C1E765.7080603@oracle.com> <56C1FE37.9010507@oracle.com> <015201d16813$333650c0$99a2f240$@apache.org>

<56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> Message-ID: Hi Peter, I found this thread has grown to discuss several relevant issues that can be separated. 1. Assist cleaner to deallocate direct byte buffer (JDK-6857566) 2. Replace direct byte buffer with java.lang.ref.Cleaner 3. java.lang.ref.Cleaner be an interface vs final class 4. Pending reference list lock (JDK-8055232) Roger has to speak for #3 which I don?t think he comments on that. For #4, working out the VM and library new interface to transfer the pending references definitely has to take more time and prototype. I?m interested in #4 but not sure if this can target in JDK 9 (given that FC in May). I?d like to address #1 to have the allocating thread to invoke cleaning actions to free native memory rather than any cleaning action. #2 is not as critical in my opinion while it?d be nice to get to. One possible option to move forward is to keep Cleaner as is and keep java.nio.Bits to invoke cleaning actions, i.e. webrev.08.part2 except that CleanerFactory will have two special cleaners - one for native memory cleaning and the other for anything else (there isn?t any client in JDK yet). We will see what Panama would provide for timely deallocation and we could replace the fix in Bits with that when?s available. My comments inlined below that are related #1 and #2. > On Mar 28, 2016, at 10:18 AM, Peter Levart wrote: > > > But first, let me reply to Mandy's comments... > > >> My uncomfort was the fix for JDK-6857566 - both enqueuing pending ref and invoking the cleaning code in an arbitrary thread. >> >> Looking at it again - enqueuing the pending reference is not so much of a concern (simply updating the link) but the common cleaner could be used by other code that may only expect to be invoked in system thread that?s still my concern (thinking of thread locals). >> > > As you'll see in the webrev below, enqueueing is performed solely be ReferenceHandler thread. Allocating thread(s) just wait for it to do its job. There's a little synchronization action performed at the end of enqueueing a chunk of pending references that notifies waiters (allocating threads) so that they can continue. This actually improves throughput (compared to helping enqueue Reference(s) one by one) because there's not much actual work to be done (just swapping pointers) so synchronization dominates. The goal here is to minimize synchronization among threads and by executing enqueuing of the whole bunch of pending references in private by a single thread achieves a reduction in synchronization when lots of Reference(s) are discovered at once - precisely the situation when it matters. > I understand this and have no issue with this. > OTOH helping the Cleaner thread is beneficial as cleanup actions take time to execute and this is the easiest way to retry allocation while there's still chance it will succeed. As the common Cleaner is using InnocuousThread, cleanup actions can't rely on any thread locals to be preserved from invocation to invocation anyway - they are cleared after each cleanup action so each action gets empty thread locals. We could simulate this in threads that help execute cleanup actions by saving thread-locals to local variables, clearing thread-locals, executing cleanup action and then restoring thread-locals from local variables. Mandy, if you think this is important I'll add such save/clear/restore code to appropriate place. I?m comfortable of running unsafe::freeMemory in allocating thread. That?s why I propose to have a specific cleaner for native memory allocation use that seems to be the simplest approach (but if it turns out changing to Cleaner as as interface - it?s a different question). I can?t speak for NIO if we want to put save/clear/restore logic in java.nio.Bits. Mandy From me at noctarius.com Fri Apr 1 04:57:31 2016 From: me at noctarius.com (Christoph Engelbert) Date: Fri, 1 Apr 2016 06:57:31 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56fddd2b.034cc20a.40b40.fffffef8@mx.google.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56fddd2b.034cc20a.40b40.fffffef8@mx.google.com> Message-ID: Hey guys, I really like the proposal! I also have the strong feeling it should be proposed with an VarHandles in mind. So far VarHandles can only build views on top of ByteBuffers, which stuck with 32bit indexing. Wouldn?t it make sense to also support 64bit addressing when allocating memory? Apart from that I really love Bernd?s comment. Having an option to share memory potions without the need to put another layer on top sounds amazingly useful to me. Also the generic option makes perfect sense (for example if we ever get a 64BitByteBuffer ;-)). Chris > On 01 Apr 2016, at 04:30, Bernd Eckenfels wrote: > > Hello, > > I like the proposal. I wonder if minimal support for requesting ?keyed? memory locations should already be present. The absolute minimum here would be a long (representing any key scheme but of course most natural would be a slot counter or base address) > > Memory { ByteBuffer allocate(int size); ByteBuffer request(long slot, int size);} > > (by Definition each request will produce independent ByteBuffer instances but sharing the backing) > > This would work for shared memory segments and persistent ram. > > There might be a need to interrogate the buffers (to get base address or slot number when allocate was used). So it might be a good idea to introduce generic signatures: > > interface Memory { > T allocate(int size); > T request(long slot, int size); > } > > ShmMemory implements Memory { ... } > > ShmByteBuffer b = new ShmMemory().allocate(1*MB); > > I have the feeling the concept is only a bit more complex but covers much more cases with less wild casting and non standard factories. > > I like the Memory name, an alternative would be BufferSupplier (with the idea it could also be used for logical buffer pools). > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > Von: Dohrmann, Steve > Gesendet: Donnerstag, 31. M?rz 2016 23:25 > An: core-libs-dev at openjdk.java.net > Cc: Fan, Lei t; Deshpande, Vivek R; Kaczmarek, Eric > Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory > > This is a JDK 9 proposal to support allocation of direct java.nio.ByteBuffer instances backed by memory other than off-heap RAM. > > The current allocateDirect() static method in java.nio.ByteBuffer is being used by some applications to meet special memory needs -- in particular, allocating large amounts of memory without contributing significantly to GC pause times. Other kinds of memory could offer advantages to such applications. For example, Intel's 3D XPoint memory offers large memory capacities that are more affordable than RAM and speeds that are much faster than NAND storage. Currently, there is no well-defined interface that can be used to offer a Java developer access to these other kinds of memory. > > Specifically, we propose adding a common memory interface that can be implemented by an open-ended set of memory classes. The interface would provide one method that allocates a java.nio.ByteBuffer on the memory associated with the specific memory instance. > > package java.nio; > > interface Memory { > public ByteBuffer allocateByteBuffer(int size); > } > > These ByteBuffers will have the same behavior as those allocated by the allocateDirect method in java.nio.ByteBuffer: 1) the ByteBuffer instance is managed on the Java heap, 2) the buffer's backing memory resides on whatever space the memory instance represents, and 3) the backing memory is automatically freed when the ByteBuffer object is garbage collected. > > Developers would obtain instances of these Memory objects by calling public constructors on specific memory classes. We propose having developers call constructors directly because it is a simple way to accommodate varying initialization requirements (e.g. partitioning) that specific memory instances may have. > > For uniformity, we propose mirroring the existing off-heap java.nio.ByteBuffer allocation through an off-heap RAM class that implements the Memory interface: > > package java.nio; > > public class OffHeapRAM implements Memory { > @Override > public ByteBuffer allocateByteBuffer(int size) { > return ByteBuffer.allocateDirect(size); > } > } > > Uniform access could be extended to on-heap ByteBuffers with a class that wraps the non-direct allocation method in ByteBuffer: > > package java.nio; > > public class HeapRAM implements Memory { > @Override > public ByteBuffer allocateByteBuffer(int size) { > return ByteBuffer.allocate(size); > } > } > > The 3 additions above are the only changes proposed. Links to a bug report and to a JDK 9 patch containing these additions are shown below. For sample code, we are also creating a class that implements the Memory interface for java.nio.ByteBuffers backed by Intel's 3D XPoint memory. > > bug: https://bugs.openjdk.java.net/browse/JDK-8153111 > > patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ > > While other useful capabilities in this space (e.g. persistent memory, process-shared memory) are being explored, they are specifically not addressed or proposed here. We believe that supporting java.nio.ByteBuffer allocation on other memory spaces is sufficiently useful to propose it now for JDK 9. > > Please let us know if there is interest in this proposal and if you would like to sponsor a patch. > > Best regards, > Steve Dohrmann > > From aph at redhat.com Fri Apr 1 07:49:52 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Apr 2016 08:49:52 +0100 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> Message-ID: <56FE2820.5000906@redhat.com> On 31/03/16 22:14, Dohrmann, Steve wrote: > This is a JDK 9 proposal to support allocation of direct > java.nio.ByteBuffer instances backed by memory other than off-heap > RAM. I must be missing something. How is this different from exposing special memory via the filesystem and mapping a file? Andrew. From szegedia at gmail.com Fri Apr 1 08:54:02 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 1 Apr 2016 10:54:02 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56FE2820.5000906@redhat.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FE2820.5000906@redhat.com> Message-ID: <94F7C5F9-02F7-4D55-A107-12FC19DAFAC7@gmail.com> I can think of several differences. For one, you can?t presume the availability of a filesystem (Java doesn?t require that the host system give it access to a filesystem), nor the ability of the filesystem to expose all desired kinds of memory as files. Next, every such solution is OS specific and we love having OS independent APIs in Java. An aspect of OS-specific functionality would also be access controls to these files, while with a Java API such controls can (if needed) be managed by Java security policy (again, in OS independent fashion). Finally, even if all of this is present in the system, exposing memory as files can be a security issue if an external process can also gain access to them. So a simple in-process, OS-independent API is definitely better suited for the task. Just my opinion, Attila. On 01 Apr 2016, at 09:49, Andrew Haley wrote: > > On 31/03/16 22:14, Dohrmann, Steve wrote: > >> This is a JDK 9 proposal to support allocation of direct >> java.nio.ByteBuffer instances backed by memory other than off-heap >> RAM. > > I must be missing something. How is this different from exposing > special memory via the filesystem and mapping a file? > > Andrew. > From abhijit.r.roy at oracle.com Fri Apr 1 09:04:36 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Fri, 1 Apr 2016 02:04:36 -0700 (PDT) Subject: https://bugs.openjdk.java.net/browse/JI-9032379 Message-ID: <05380a93-5dee-4a06-a1bc-6904e8cbd3c1@default> Hi, Need some suggestion for this issue (2nd part). Thanks Abhijit From mr.chrisvest at gmail.com Fri Apr 1 09:27:28 2016 From: mr.chrisvest at gmail.com (Chris Vest) Date: Fri, 1 Apr 2016 11:27:28 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56fddd2b.034cc20a.40b40.fffffef8@mx.google.com> Message-ID: <98BC8212-52D3-4E34-AA5E-4EFDB7EBF05D@gmail.com> Could ?keyd? memory - the request method Bernd proposed - not be given as constructor parameters to the Memory implementation? For instance, an ShmMemory implementation that allocates out of /dev/shm, could take a filename through its constructor, and allocate by mapping that file in /dev/shm. Unfortunately this would make it implementation defined, if the allocate method returns the same memory every time, or new memory. To solve that, I would add a boolean isShared method to the Memory interface, so you can tell programatically if the buffers allocated from a given memory instance can be expected to be private (only accessible through the returned ByteBuffer) or shared (others might look at or modify this memory even if I keep my ByteBuffer secret). I would also like the allocate method to take a long size, instead of an int. Implementations are free to throw exceptions if clients ask to allocate more memory than is available, or can fit in the given buffer implementation. And with the current ByteBuffer interface, all implementations would have to throw for allocations greater than 2 GiBs, but if that limitation of the ByteBuffer interface were to be removed, then the Memory interface would be ready for it. Cheers, Chris > On 01 Apr 2016, at 06:57, Christoph Engelbert wrote: > > Hey guys, > > I really like the proposal! I also have the strong feeling it should be proposed with an VarHandles in mind. So far VarHandles can only build views on top of ByteBuffers, which stuck with 32bit indexing. Wouldn?t it make sense to also support 64bit addressing when allocating memory? > > Apart from that I really love Bernd?s comment. Having an option to share memory potions without the need to put another layer on top sounds amazingly useful to me. Also the generic option makes perfect sense (for example if we ever get a 64BitByteBuffer ;-)). > > Chris > >> On 01 Apr 2016, at 04:30, Bernd Eckenfels wrote: >> >> Hello, >> >> I like the proposal. I wonder if minimal support for requesting ?keyed? memory locations should already be present. The absolute minimum here would be a long (representing any key scheme but of course most natural would be a slot counter or base address) >> >> Memory { ByteBuffer allocate(int size); ByteBuffer request(long slot, int size);} >> >> (by Definition each request will produce independent ByteBuffer instances but sharing the backing) >> >> This would work for shared memory segments and persistent ram. >> >> There might be a need to interrogate the buffers (to get base address or slot number when allocate was used). So it might be a good idea to introduce generic signatures: >> >> interface Memory { >> T allocate(int size); >> T request(long slot, int size); >> } >> >> ShmMemory implements Memory { ... } >> >> ShmByteBuffer b = new ShmMemory().allocate(1*MB); >> >> I have the feeling the concept is only a bit more complex but covers much more cases with less wild casting and non standard factories. >> >> I like the Memory name, an alternative would be BufferSupplier (with the idea it could also be used for logical buffer pools). >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> >> Von: Dohrmann, Steve >> Gesendet: Donnerstag, 31. M?rz 2016 23:25 >> An: core-libs-dev at openjdk.java.net >> Cc: Fan, Lei t; Deshpande, Vivek R; Kaczmarek, Eric >> Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory >> >> This is a JDK 9 proposal to support allocation of direct java.nio.ByteBuffer instances backed by memory other than off-heap RAM. >> >> The current allocateDirect() static method in java.nio.ByteBuffer is being used by some applications to meet special memory needs -- in particular, allocating large amounts of memory without contributing significantly to GC pause times. Other kinds of memory could offer advantages to such applications. For example, Intel's 3D XPoint memory offers large memory capacities that are more affordable than RAM and speeds that are much faster than NAND storage. Currently, there is no well-defined interface that can be used to offer a Java developer access to these other kinds of memory. >> >> Specifically, we propose adding a common memory interface that can be implemented by an open-ended set of memory classes. The interface would provide one method that allocates a java.nio.ByteBuffer on the memory associated with the specific memory instance. >> >> package java.nio; >> >> interface Memory { >> public ByteBuffer allocateByteBuffer(int size); >> } >> >> These ByteBuffers will have the same behavior as those allocated by the allocateDirect method in java.nio.ByteBuffer: 1) the ByteBuffer instance is managed on the Java heap, 2) the buffer's backing memory resides on whatever space the memory instance represents, and 3) the backing memory is automatically freed when the ByteBuffer object is garbage collected. >> >> Developers would obtain instances of these Memory objects by calling public constructors on specific memory classes. We propose having developers call constructors directly because it is a simple way to accommodate varying initialization requirements (e.g. partitioning) that specific memory instances may have. >> >> For uniformity, we propose mirroring the existing off-heap java.nio.ByteBuffer allocation through an off-heap RAM class that implements the Memory interface: >> >> package java.nio; >> >> public class OffHeapRAM implements Memory { >> @Override >> public ByteBuffer allocateByteBuffer(int size) { >> return ByteBuffer.allocateDirect(size); >> } >> } >> >> Uniform access could be extended to on-heap ByteBuffers with a class that wraps the non-direct allocation method in ByteBuffer: >> >> package java.nio; >> >> public class HeapRAM implements Memory { >> @Override >> public ByteBuffer allocateByteBuffer(int size) { >> return ByteBuffer.allocate(size); >> } >> } >> >> The 3 additions above are the only changes proposed. Links to a bug report and to a JDK 9 patch containing these additions are shown below. For sample code, we are also creating a class that implements the Memory interface for java.nio.ByteBuffers backed by Intel's 3D XPoint memory. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8153111 >> >> patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ >> >> While other useful capabilities in this space (e.g. persistent memory, process-shared memory) are being explored, they are specifically not addressed or proposed here. We believe that supporting java.nio.ByteBuffer allocation on other memory spaces is sufficiently useful to propose it now for JDK 9. >> >> Please let us know if there is interest in this proposal and if you would like to sponsor a patch. >> >> Best regards, >> Steve Dohrmann >> >> > From Ulf.Zibis at CoSoCo.de Fri Apr 1 11:15:07 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 1 Apr 2016 13:15:07 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56FE2820.5000906@redhat.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FE2820.5000906@redhat.com> Message-ID: <56FE583B.9070109@CoSoCo.de> Hi, good point! As a convenience we could have something like: ByteBuffer#allocateDirect(Path path) ByteBuffer#allocateDirect(int size, Path path, Option options) What is the logical difference between a memory and a byte buffer, as both provide the facility to save bytes? Couldn't Intel just provide a com.intel.memory.XPoint3DByteBuffer extends Bytebuffer class with usual constructors? I do not see the point, why introducing a new named interface for a just existing solution. As a convenience we could have: ByteBuffer#allocateDirect(int size, Class bufferType) If one wants to hide the class itself as similar with HeapByteBuffer: ByteBuffer#allocateDirect(int size, BufferProvider provider) -Ulf Am 01.04.2016 um 09:49 schrieb Andrew Haley: > I must be missing something. How is this different from exposing special memory via the filesystem > and mapping a file? Andrew. From claes.redestad at oracle.com Fri Apr 1 12:32:08 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Apr 2016 14:32:08 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> Message-ID: <56FE6A48.4040007@oracle.com> Hi Mandy et al, On 2016-04-01 01:10, Mandy Chung wrote: > GenerateBMHClassesPlugin::configure > The plugin should validate of the input argument and throw an exception if it?s invalid. The plugin API is still being revised and JDK-8152800 is related to the exception case. The existing plugins throw PluginException. GenerateBMHClassesPlugin can do the same. > > Perhaps the expanded signatures should be stored after validation. > > GenerateBMHClassesPlugin::generateConcreteClass > It issues a warning if any exception thrown. If the user specifies the types in the command line, they should specify the valid values (I would expect). I prefer it to be an error and throw PluginException. > > It may be time to rename this plugin to ?-generate-jli-classes plugin, as John suggests. A jlink plugin can define its sub options e.g. ?-generate-jli-classes=bmh[:species=LL,LLL]. > > Can you add a test to sanity test if the classes are generated (both the default species types as well as specified in the input argument)? > > Mandy http://cr.openjdk.java.net/~redestad/8152641/webrev.06/ - Renamed GenerateBMHClassesPlugin to GenerateJLIClassesPlugin, --generate-bmh -> --generate-jli-classes - Implement control of BMH species with sub-parameters --generate-jli-classes=bmh:bmh-species=LL,L3,L5 etc. This will be easy to extend into something like --generate-jli-classes=all:bmh-species=LL,L3,...:invokers=??,...:lambda-forms=??,... as we add other things to this plugin - Expand and validate input in the plugin - Add a test which tests default, explicit, invalid and disabled cases - Add a defaultSpecies() method for testing convenience together with a comment alluding to how it was generated. - Bumped the counter in JLinkTest...[1] To try and answer John's other comments: Yes, I intend to file RFEs and work on adding support to generate other j.l.i classes in the near future as time allows, and also have some na?ve hope that we can add support to generate the default input arguments at build-time. Thanks for all the feedback and reviews! /Claes [1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to improve this test. From aph at redhat.com Fri Apr 1 12:59:30 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Apr 2016 13:59:30 +0100 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <94F7C5F9-02F7-4D55-A107-12FC19DAFAC7@gmail.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FE2820.5000906@redhat.com> <94F7C5F9-02F7-4D55-A107-12FC19DAFAC7@gmail.com> Message-ID: <56FE70B2.4080608@redhat.com> On 04/01/2016 09:54 AM, Attila Szegedi wrote: > I can think of several differences. For one, you can?t presume the > availability of a filesystem (Java doesn?t require that the host > system give it access to a filesystem), nor the ability of the > filesystem to expose all desired kinds of memory as files. OK. I have no sympathy with operating systems that can't do this, but that's just MO. :-) > Next, every such solution is OS specific and we love having OS > independent APIs in Java. I would have thought that by definition memory with odd semantics is OS-dependent and non-portable. > An aspect of OS-specific functionality would also be access controls > to these files, while with a Java API such controls can (if needed) > be managed by Java security policy (again, in OS independent > fashion). Eh? Any OS has access controls on its files. > Finally, even if all of this is present in the system, exposing > memory as files can be a security issue if an external process can > also gain access to them. Exposing memory to an external process in any way can be a security issue. It doesn't matter if it's a file or not. This is irrelevant. Andrew. From aleksej.efimov at oracle.com Fri Apr 1 13:01:27 2016 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 1 Apr 2016 16:01:27 +0300 Subject: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails Message-ID: <56FE7127.9040308@oracle.com> Hi, The push for JDK-8134111 missed one test file. Please, review and approve the addition of missing ObjectFactory.java file. Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 Thanks, Aleksej From amy.lu at oracle.com Fri Apr 1 13:30:48 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 1 Apr 2016 21:30:48 +0800 Subject: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails In-Reply-To: <56FE7127.9040308@oracle.com> References: <56FE7127.9040308@oracle.com> Message-ID: <56FE7808.7040606@oracle.com> Looks fine. Thank you for the quick fix ! ( As I'm not openjdk reviewer, please wait for reviewer's feedback. ) Thanks, Amy On 4/1/16 9:01 PM, Aleksej Efimov wrote: > Hi, > The push for JDK-8134111 missed one test file. Please, review and > approve the addition of missing ObjectFactory.java file. > > Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 > > Thanks, > Aleksej > From sean.coffey at oracle.com Fri Apr 1 13:32:20 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 1 Apr 2016 14:32:20 +0100 Subject: RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails In-Reply-To: <56FE7127.9040308@oracle.com> References: <56FE7127.9040308@oracle.com> Message-ID: <56FE7864.1000408@oracle.com> Looks fine. Regards, Sean. On 01/04/16 14:01, Aleksej Efimov wrote: > Hi, > The push for JDK-8134111 missed one test file. Please, review and > approve the addition of missing ObjectFactory.java file. > > Webrev with added file: http://cr.openjdk.java.net/~aefimov/8153262/00 > > Thanks, > Aleksej > From mandy.chung at oracle.com Fri Apr 1 14:57:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 1 Apr 2016 07:57:07 -0700 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: <56FE6A48.4040007@oracle.com> References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> <56FE6A48.4040007@oracle.com> Message-ID: > On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.06/ > Looks good except the new test with 2015 copyright start year. > > [1] Mandy filed https://bugs.openjdk.java.net/browse/JDK-8153238 to improve this test. Yes the test should be revised to validate a well-known list of plugins rather than hardcoding the number of plugins. Mandy From claes.redestad at oracle.com Fri Apr 1 15:04:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Apr 2016 17:04:58 +0200 Subject: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time In-Reply-To: References: <56F3EEAB.4090600@oracle.com> <1FE3F7A6-1C7B-4DC6-875C-E3FAEDED08F5@oracle.com> <56F50EC5.6020500@gmail.com> <56F5520D.3080205@oracle.com> <56F676CA.5000803@gmail.com> <56FB09D3.4090000@oracle.com> <56FB82FE.5010209@gmail.com> <56FB8607.8030000@gmail.com> <56FBB014.6050002@oracle.com> <56FBC4D8.8010603@gmail.com> <56FBDF98.4090102@oracle.com> <56FBEE08.7010600@gmail.com> <56FBFC23.5090104@oracle.com> <56FE6A48.4040007@oracle.com> Message-ID: <56FE8E1A.1010808@oracle.com> On 2016-04-01 16:57, Mandy Chung wrote: >> On Apr 1, 2016, at 5:32 AM, Claes Redestad wrote: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.06/ >> > Looks good except the new test with 2015 copyright start year. Fixed. Thanks Mandy! /Claes From peter.levart at gmail.com Fri Apr 1 15:18:38 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 1 Apr 2016 17:18:38 +0200 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: References: <56B72242.7050102@gmail.com> <56C1E765.7080603@oracle.com> <56C1FE37.9010507@oracle.com> <015201d16813$333650c0$99a2f240$@apache.org>

wrote: > >> On 03/31/2016 05:14 PM, Dohrmann, Steve wrote: >> >>> This is a JDK 9 proposal to support allocation of direct >>> java.nio.ByteBuffer >>> instances backed by memory other than off-heap RAM. >>> >> >> I like it. Various kinds of heterogeneous memories are becoming more >> common, and this seems like the simplest accommodation that at least >> gets ByteBuffer functionality. >> >> With such a simple API, it is hard to imagine fundamental problems >> fitting to other heterogeneous systems, but it would still be great >> if anyone dealing with non-Intel systems (TI/KeyStone?) could >> sanity-check this. >> >> I suspect some people would prefer a more elaborate SPI scheme, >> but this seems fine to me: >> >> >> package java.nio; >>> >>> interface Memory { public ByteBuffer allocateByteBuffer(int size); } >>> >>> Developers would obtain instances of these Memory objects by calling >>> public >>> constructors on specific memory classes. We propose having developers >>> call >>> constructors directly because it is a simple way to accommodate varying >>> initialization requirements (e.g. partitioning) that specific memory >>> instances may have. >>> >>> For uniformity, we propose mirroring the existing off-heap >>> java.nio.ByteBuffer allocation through an off-heap RAM class that >>> implements >>> the Memory interface: >>> >>> package java.nio; >>> >>> public class OffHeapRAM implements Memory { @Override public ByteBuffer >>> allocateByteBuffer(int size) { return ByteBuffer.allocateDirect(size); } } >>> >>> Uniform access could be extended to on-heap ByteBuffers with a class that >>> wraps the non-direct allocation method in ByteBuffer: >>> >>> package java.nio; >>> >>> public class HeapRAM implements Memory { @Override public ByteBuffer >>> allocateByteBuffer(int size) { return ByteBuffer.allocate(size); } } >>> >>> The 3 additions above are the only changes proposed. Links to a bug >>> report >>> and to a JDK 9 patch containing these additions are shown below. For >>> sample >>> code, we are also creating a class that implements the Memory interface >>> for >>> java.nio.ByteBuffers backed by Intel's 3D XPoint memory. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8153111 >>> >>> patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ >>> >>> While other useful capabilities in this space (e.g. persistent memory, >>> process-shared memory) are being explored, they are specifically not >>> addressed or proposed here. We believe that supporting >>> java.nio.ByteBuffer >>> allocation on other memory spaces is sufficiently useful to propose it now >>> for JDK 9. >>> >>> Please let us know if there is interest in this proposal and if you would >>> like to sponsor a patch. >>> >>> Best regards, Steve Dohrmann >>> >>> >>> >> -- - DML From aph at redhat.com Fri Apr 1 17:40:17 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 1 Apr 2016 18:40:17 +0100 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56FEAA73.8070308@redhat.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FDB09A.7050108@cs.oswego.edu> <56FEAA73.8070308@redhat.com> Message-ID: <56FEB281.5070102@redhat.com> On 04/01/2016 06:05 PM, David M. Lloyd wrote: > Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 > (atomics for buffers) or > https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency > properties of buffers), how meaningful is this? That's on the list of things to get fixed with VarHandles. It's worth discussing in this context. The probelm is that "memory" with odd semantics may not map well onto the JMM. Andrew. From hboehm at google.com Fri Apr 1 20:12:00 2016 From: hboehm at google.com (Hans Boehm) Date: Fri, 1 Apr 2016 13:12:00 -0700 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <56FEB281.5070102@redhat.com> References: <7BA565EA-DB87-4583-93AD-1AF5DA68AA6C@intel.com> <56FDB09A.7050108@cs.oswego.edu> <56FEAA73.8070308@redhat.com> <56FEB281.5070102@redhat.com> Message-ID: It seems like the second one is kind of this issue. Atomics in buffers are not needed to cause problems. If a buffer on x86 were mapped write-through or write-coalescing, for example, I'm not at all sure that signalling completion of a write to the buffer by setting a separate volatile flag (outside the buffer) would work. On x86, there is no fence before the volatile store, and I'm not at all sure what ordering properties there are for a write-through or write-coalescing store followed by a write-back-cacheable store. There has also been a tendency to replace x86 MFENCE instructions following a volatile store, with an atomic read-modify-write instruction. AFAICT, this is usually faster precisely because it only orders write-back-cacheable accesses. So far, the memory model effort has concentrated on the assumption that all relevant memory is mapped write-back-cacheable (or whatever the standard mode is for user-level memory). My impression is that anything else is generally significantly less well specified, at all levels of the stack. On Fri, Apr 1, 2016 at 10:40 AM, Andrew Haley wrote: > On 04/01/2016 06:05 PM, David M. Lloyd wrote: > > Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 > > (atomics for buffers) or > > https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency > > properties of buffers), how meaningful is this? > > That's on the list of things to get fixed with VarHandles. It's worth > discussing in this context. The probelm is that "memory" with odd > semantics may not map well onto the JMM. > > Andrew. > > From claes.redestad at oracle.com Fri Apr 1 20:25:04 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Apr 2016 22:25:04 +0200 Subject: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed Message-ID: <56FED920.3010207@oracle.com> Hi, seems my recent push for JDK-8152641 broke a jimage test or two. While I think these test seem a bit odd, it's apparent that checking that we're not adding the same resource twice is enough to make the tests happy for now: Webrev: http://cr.openjdk.java.net/~redestad/8153317/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153317 Thanks! /Claes From joe.darcy at oracle.com Fri Apr 1 20:32:58 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 1 Apr 2016 13:32:58 -0700 Subject: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed In-Reply-To: <56FED920.3010207@oracle.com> References: <56FED920.3010207@oracle.com> Message-ID: <56FEDAFA.80806@oracle.com> Hello Claes, I'll approve the test change in the interests of getting the tests back to green, but it does sound like some more investigation is warranted into what is going on. In other words, running down the root cause to make sure the same bad effect won't show up elsewhere. Thanks, -Joe On 4/1/2016 1:25 PM, Claes Redestad wrote: > Hi, > > seems my recent push for JDK-8152641 broke a jimage test or two. > > While I think these test seem a bit odd, it's apparent that checking > that we're not adding the same resource twice is enough to make the > tests happy for now: > > Webrev: http://cr.openjdk.java.net/~redestad/8153317/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153317 > > Thanks! > > /Claes From steve.drach at oracle.com Fri Apr 1 20:37:37 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 1 Apr 2016 13:37:37 -0700 Subject: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value Message-ID: Hi, Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of ?true" in order to be effective, i.e. to assert the jar is a multi-release jar. issue: https://bugs.openjdk.java.net/browse/JDK-8153213 webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html Thanks Steve From claes.redestad at oracle.com Fri Apr 1 20:39:46 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Apr 2016 22:39:46 +0200 Subject: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value In-Reply-To: References: Message-ID: <56FEDC92.1010002@oracle.com> Hi Steve, this looks good to me! Thanks! /Claes On 2016-04-01 22:37, Steve Drach wrote: > Hi, > > Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of ?true" in order to be effective, i.e. to assert the jar is a multi-release jar. > > issue: https://bugs.openjdk.java.net/browse/JDK-8153213 > webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html > > Thanks > Steve From claes.redestad at oracle.com Fri Apr 1 20:46:10 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 1 Apr 2016 22:46:10 +0200 Subject: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed In-Reply-To: <56FEDAFA.80806@oracle.com> References: <56FED920.3010207@oracle.com> <56FEDAFA.80806@oracle.com> Message-ID: <56FEDE12.8090506@oracle.com> Hello Joe, and thanks! The change is in the plugin and not the test, though, so might be as good as it gets (I've verified all jlink plugin tests work with this). The surprising thing here to me is why these tests was running the plugin twice on the same (exploded) image since regurgitating an image didn't occur to me to be a valid/supported use-case. /Claes On 2016-04-01 22:32, joe darcy wrote: > Hello Claes, > > I'll approve the test change in the interests of getting the tests > back to green, but it does sound like some more investigation is > warranted into what is going on. In other words, running down the root > cause to make sure the same bad effect won't show up elsewhere. > > Thanks, > > -Joe > > On 4/1/2016 1:25 PM, Claes Redestad wrote: >> Hi, >> >> seems my recent push for JDK-8152641 broke a jimage test or two. >> >> While I think these test seem a bit odd, it's apparent that checking >> that we're not adding the same resource twice is enough to make the >> tests happy for now: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8153317/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153317 >> >> Thanks! >> >> /Claes > From Roger.Riggs at Oracle.com Fri Apr 1 21:51:21 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 1 Apr 2016 17:51:21 -0400 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <56FEA5FF.4060801@gmail.com> References: <56B72242.7050102@gmail.com>

<56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> Message-ID: > On Apr 1, 2016, at 4:31 PM, Roger Riggs wrote: > > Hi Peter, > > I overlooked the introduction of another nested class (Task) to handle the cleanup. > But there are too many changes to see which ones solve a single problem. > > Sorry to make more work, but I think we need to go back to the minimum necessary > change to make progress on this. Omit all of the little cleanups until the end > or do them first and separately. > +1. That?d really help the reviewers. thanks Mandy > Thanks, Roger > > > > > On 4/1/16 5:51 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for the diffs to look at. >> >> Two observations on the changes. >> >> - The Cleaner instance was intentionally and necessarily different than the CleanerImpl to enable >> the CleanerImpl and its thread to terminate if the Cleaner is not longer referenced. >> Folding them into a single object breaks that. >> >> Perhaps it is not too bad for ExtendedCleaner to subclass CleanerImpl with the cleanup helper/supplier behavior >> and expose itself to Bits. There will be fewer moving parts. There is no need for two factory methods for >> ExtendedCleaner unless you are going to use a separate ThreadFactory. >> >> - The Deallocator (and now Allocator) nested classes are identical, and there is a separate copy for each >> type derived from the Direct-X-template. But it may not be worth fixing until the rest of it is settled to avoid >> more moving parts. >> >> I don't have an opinion on the code changes in Reference, that's different kettle of fish. >> >> More next week. >> >> Have a good weekend, Roger >> >> >> On 4/1/2016 12:46 PM, Peter Levart wrote: >>> >>> >>> On 04/01/2016 06:08 PM, Peter Levart wrote: >>>> >>>> >>>> On 04/01/2016 05:18 PM, Peter Levart wrote: >>>>> @Roger: >>>>> >>>>> ... >>>>> >>>>> About entanglement between nio Bits and ExtendedCleaner.retryWhileHelpingClean(). It is the same level of entanglement as between the DirectByteBuffer constructor and Cleaner.register(). In both occasions an action is provided to the Cleaner. Cleaner.register() takes a cleanup action and ExtendedCleaner.retryWhileHelpingClean() takes a retriable "allocating" or "reservation" action. "allocation" or "reservation" is the opposite of cleanup. Both methods are encapsulated in the same object because those two functions must be coordinated. So I think that collocating them together makes sense. What do you think? >>>> >>>> ...to illustrate what I mean, here's a variant that totally untangles Bits from Cleaner and moves the whole Cleaner interaction into the DirectByteBuffer itself: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.13.part2/ >>>> >>>> Notice the symmetry between Cleaner.retryWhileHelpingClean : Cleaner.register and Allocator : Deallocator ? >>>> >>>> >>>> Regards, Peter >>>> >>> >>> And here's also a diff between webrev.12.part2 and webrev.13.part2: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.diff.12to13.part2/ >>> >>> Regards, Peter >>> >> > From steve.dohrmann at intel.com Fri Apr 1 23:57:22 2016 From: steve.dohrmann at intel.com (Dohrmann, Steve) Date: Fri, 1 Apr 2016 23:57:22 +0000 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory Message-ID: Hi everyone, The questions and suggestions regarding this proposal (JDK-8153111) are interesting and useful. We are still digesting the feedback; next week we'll do our best to respond to items raised and add to the discussion. I hope this list captures the main concerns and suggestions seen so far in the discussion: 1. Why not enhance ByteBuffer allocation methods rather that create a new Memory interface 2. Does this proposal buy us anything over exposing special memory as a file mappable via the OS? 3. Possibly more elaborate SPI scheme for memory space creation 4. Provide keyed (e.g. long "slot") allocation of ByteBuffers in a memory space 5. Generic interfaces on Memory (alternate name: BufferSupplier) interface methods 6. Clearer shared / private ByteBuffer semantics within a memory space 7. 64-bit allocation / addressing in Memory interface, at least as prep for a less-restricted ByteBuffer interface 8. Importance of atomics for ByteBuffers (JDK-8008240) and ByteBuffer consistency (JDK-6476827) in the context of this proposal 9. Connection between this proposal and VarHandles Best regards, Steve Dohrmann From Alan.Bateman at oracle.com Sat Apr 2 09:53:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 2 Apr 2016 10:53:02 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> Message-ID: <56FF967E.5090102@oracle.com> (cc'ing serviceability-dev as this is where this code is maintained). On 02/04/2016 00:32, Mandy Chung wrote: > Hi Chris, > > Would jdk.internal.vm be appropriate for this VMSupoprt class? I agree. > > VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. > > src/jdk.jdwp.agent/share/native/libjdwp/util.c > JDWP calls it and needs to be updated. If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. > > VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. It could although I assume this means that introducing a new shared library. -Alan > > Mandy > >> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >> >> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >> >> sun.misc.VMSupport is a utility class supporting two functions: >> 1) the initialization of management Agent properties, and >> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >> >> The initialization of Agent properties is used statically by the java.managment module, >> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >> The location of VM temporary files is a low-level interface between the libraries and VM. >> For these reasons, VMSupport should remain in the base module, but be moved to an >> internal package. >> >> http://cr.openjdk.java.net/~chegar/8153181/00/ >> https://bugs.openjdk.java.net/browse/JDK-8153181 >> >> -Chris. From abhijit.r.roy at oracle.com Sat Apr 2 10:56:33 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Sat, 2 Apr 2016 03:56:33 -0700 (PDT) Subject: https://bugs.openjdk.java.net/browse/JI-9032379 In-Reply-To: <05380a93-5dee-4a06-a1bc-6904e8cbd3c1@default> References: <05380a93-5dee-4a06-a1bc-6904e8cbd3c1@default> Message-ID: Hi All, It was a mistake from my end. Please ignore it. Thanks, Abhijit From: Abhijit Roy Sent: Friday, April 01, 2016 02:35 PM To: core-libs-dev at openjdk.java.net Subject: https://bugs.openjdk.java.net/browse/JI-9032379 Hi, Need some suggestion for this issue (2nd part). Thanks Abhijit From peter.levart at gmail.com Sat Apr 2 11:24:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 2 Apr 2016 13:24:29 +0200 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <56FF04B5.2030507@oracle.com> References: <56B72242.7050102@gmail.com> <56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> Message-ID: <56FFABED.2060708@gmail.com> Hi Roger, Thanks for looking at the patch. On 04/02/2016 01:31 AM, Roger Riggs wrote: > Hi Peter, > > I overlooked the introduction of another nested class (Task) to handle > the cleanup. > But there are too many changes to see which ones solve a single problem. > > Sorry to make more work, but I think we need to go back to the minimum > necessary > change to make progress on this. Omit all of the little cleanups until > the end > or do them first and separately. > > Thanks, Roger No Problem. I understand. So let's proceed in stages. Since part1 is already pushed, I'll call part2 stages with names: part2.1, part2.2, ... and I'll start counting webrev revisions from 01 again, so webrev names will be in the form: webrev.part2.1.rev01. Each part will be an incremental change to the previous one. part2.1: This is preparation work to be able to have an extended java.lang.ref.Cleaner type for internal use. Since java.lang.ref.Cleaner is a final class, I propose to make it an interface instead: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ This is a source-compatible change and it also simplifies implementation (no injection of Cleaner.impl access function into CleanerImpl needed any more). What used to be java.lang.ref.Cleaner is renamed to jdk.internal.ref.CleanerImpl. What used to be jdk.internal.ref.CleanerImpl is now a nested static class jdk.internal.ref.CleanerImpl.Task (because it implements Runnable). Otherwise nothing has changed in the overall architecture of the Cleaner except that public-facing API is now an interface instead of a final class. This allows specifying internal extension interface and internal extension implementation. CleanerTest passes with this change. So what do you think? Regards, Peter > > > > > On 4/1/16 5:51 PM, Roger Riggs wrote: >> Hi Peter, >> >> Thanks for the diffs to look at. >> >> Two observations on the changes. >> >> - The Cleaner instance was intentionally and necessarily different >> than the CleanerImpl to enable >> the CleanerImpl and its thread to terminate if the Cleaner is not >> longer referenced. >> Folding them into a single object breaks that. >> >> Perhaps it is not too bad for ExtendedCleaner to subclass CleanerImpl >> with the cleanup helper/supplier behavior >> and expose itself to Bits. There will be fewer moving parts. There is >> no need for two factory methods for >> ExtendedCleaner unless you are going to use a separate ThreadFactory. >> >> - The Deallocator (and now Allocator) nested classes are identical, >> and there is a separate copy for each >> type derived from the Direct-X-template. But it may not be worth >> fixing until the rest of it is settled to avoid >> more moving parts. >> >> I don't have an opinion on the code changes in Reference, that's >> different kettle of fish. >> >> More next week. >> >> Have a good weekend, Roger >> >> >> On 4/1/2016 12:46 PM, Peter Levart wrote: >>> >>> >>> On 04/01/2016 06:08 PM, Peter Levart wrote: >>>> >>>> >>>> On 04/01/2016 05:18 PM, Peter Levart wrote: >>>>> @Roger: >>>>> >>>>> ... >>>>> >>>>> About entanglement between nio Bits and >>>>> ExtendedCleaner.retryWhileHelpingClean(). It is the same level of >>>>> entanglement as between the DirectByteBuffer constructor and >>>>> Cleaner.register(). In both occasions an action is provided to the >>>>> Cleaner. Cleaner.register() takes a cleanup action and >>>>> ExtendedCleaner.retryWhileHelpingClean() takes a retriable >>>>> "allocating" or "reservation" action. "allocation" or >>>>> "reservation" is the opposite of cleanup. Both methods are >>>>> encapsulated in the same object because those two functions must >>>>> be coordinated. So I think that collocating them together makes >>>>> sense. What do you think? >>>> >>>> ...to illustrate what I mean, here's a variant that totally >>>> untangles Bits from Cleaner and moves the whole Cleaner interaction >>>> into the DirectByteBuffer itself: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.13.part2/ >>>> >>>> >>>> Notice the symmetry between Cleaner.retryWhileHelpingClean : >>>> Cleaner.register and Allocator : Deallocator ? >>>> >>>> >>>> Regards, Peter >>>> >>> >>> And here's also a diff between webrev.12.part2 and webrev.13.part2: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.diff.12to13.part2/ >>> >>> >>> Regards, Peter >>> >> > From amaembo at gmail.com Sat Apr 2 13:52:47 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Sat, 2 Apr 2016 19:52:47 +0600 Subject: RFR: 8153332 - Stream API: Fuse sorted().limit(n) into single operation Message-ID: <963711193.20160402195247@gmail.com> Hello! Please review the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8153332 http://cr.openjdk.java.net/~tvaleev/webrev/8153332/r1/ It was earlier discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039308.html The motivation and algorithm are briefly described in the JIRA issue description. Visible behavior should not change after this patch, so all the existing tests pass. I added some more tests to focus on sorted().limit() chain. Again here's some performance tests which were presented in earlier discussion: http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/jmh/ http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/jmh/summary.txt With best regards, Tagir Valeev. From mandy.chung at oracle.com Sat Apr 2 19:34:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 2 Apr 2016 12:34:09 -0700 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <56FF967E.5090102@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> Message-ID: <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> > On Apr 2, 2016, at 2:53 AM, Alan Bateman wrote: > > > (cc'ing serviceability-dev as this is where this code is maintained). > > >> On 02/04/2016 00:32, Mandy Chung wrote: >> Hi Chris, >> >> Would jdk.internal.vm be appropriate for this VMSupoprt class? > I agree. > >> >> VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. >> >> src/jdk.jdwp.agent/share/native/libjdwp/util.c >> JDWP calls it and needs to be updated. > If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. > >> >> VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. > It could although I assume this means that introducing a new shared library. jdk.internal.perf is in java.base. Another option is to move it to jdk.jvmstat that i considered but may not worth it since perf counter is still in java.base. Mandy > >> >> Mandy >> >>> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >>> >>> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >>> >>> sun.misc.VMSupport is a utility class supporting two functions: >>> 1) the initialization of management Agent properties, and >>> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >>> >>> The initialization of Agent properties is used statically by the java.managment module, >>> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >>> The location of VM temporary files is a low-level interface between the libraries and VM. >>> For these reasons, VMSupport should remain in the base module, but be moved to an >>> internal package. >>> >>> http://cr.openjdk.java.net/~chegar/8153181/00/ >>> https://bugs.openjdk.java.net/browse/JDK-8153181 >>> >>> -Chris. > From claes.redestad at oracle.com Sun Apr 3 00:51:35 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 3 Apr 2016 02:51:35 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe Message-ID: <57006917.4090200@oracle.com> Hi, BufferedInputStream is loaded early, and uses AtomicReferenceFieldUpdater to provide CAS functionality to allow for closing streams asynchronously. Using Unsafe directly instead does the exact same thing in the end, but avoids loading a few (4) classes and thus brings us a small startup improvement. Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ Thanks! /Claes From forax at univ-mlv.fr Sun Apr 3 11:57:00 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 3 Apr 2016 13:57:00 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57006917.4090200@oracle.com> References: <57006917.4090200@oracle.com> Message-ID: <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> Hi Claes, the patch is fine for me with the minor nitpick that the static final containing Unsafe should be called UNSAFE and not just U. do you know why BufferedInputStream is loaded in first place during the startup of the VM ? regards, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev Libs" > Envoy?: Dimanche 3 Avril 2016 02:51:35 > Objet: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe > > Hi, > > BufferedInputStream is loaded early, and uses > AtomicReferenceFieldUpdater to provide > CAS functionality to allow for closing streams asynchronously. Using > Unsafe directly instead > does the exact same thing in the end, but avoids loading a few (4) > classes and thus brings > us a small startup improvement. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 > Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ > > Thanks! > > /Claes > From claes.redestad at oracle.com Sun Apr 3 12:19:52 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 3 Apr 2016 14:19:52 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> Message-ID: <57010A68.9050307@oracle.com> Hi Remi, On 2016-04-03 13:57, Remi Forax wrote: > Hi Claes, > the patch is fine for me with the minor nitpick that the static final containing Unsafe should be called UNSAFE and not just U. sure, I copied the setup/naming convention from ConcurrentHashMap, but UNSAFE does make it stand out better. > > do you know why BufferedInputStream is loaded in first place during the startup of the VM ? given the output of -Xlog:classload I think it's first used by java.lang.System for what becomes System.in. Thanks! /Claes > > regards, > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "core-libs-dev Libs" >> Envoy?: Dimanche 3 Avril 2016 02:51:35 >> Objet: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe >> >> Hi, >> >> BufferedInputStream is loaded early, and uses >> AtomicReferenceFieldUpdater to provide >> CAS functionality to allow for closing streams asynchronously. Using >> Unsafe directly instead >> does the exact same thing in the end, but avoids loading a few (4) >> classes and thus brings >> us a small startup improvement. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 >> Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ >> >> Thanks! >> >> /Claes >> From forax at univ-mlv.fr Sun Apr 3 13:41:43 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 3 Apr 2016 15:41:43 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57010A68.9050307@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> Message-ID: <1378582928.1471463.1459690903288.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev Libs" > Envoy?: Dimanche 3 Avril 2016 14:19:52 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe > > Hi Remi, > > On 2016-04-03 13:57, Remi Forax wrote: > > Hi Claes, > > the patch is fine for me with the minor nitpick that the static final > > containing Unsafe should be called UNSAFE and not just U. > > sure, I copied the setup/naming convention from ConcurrentHashMap, but > UNSAFE does make it stand out better. > > > > > do you know why BufferedInputStream is loaded in first place during the > > startup of the VM ? > > given the output of -Xlog:classload I think it's first used by > java.lang.System for what becomes System.in. oh, i see :) > > Thanks! > > /Claes cheers, R?mi > > > > > regards, > > R?mi > > > > ----- Mail original ----- > >> De: "Claes Redestad" > >> ?: "core-libs-dev Libs" > >> Envoy?: Dimanche 3 Avril 2016 02:51:35 > >> Objet: RFR: 8153334: Replace BufferedInputStreams use of > >> AtomicReferenceFieldUpdater with Unsafe > >> > >> Hi, > >> > >> BufferedInputStream is loaded early, and uses > >> AtomicReferenceFieldUpdater to provide > >> CAS functionality to allow for closing streams asynchronously. Using > >> Unsafe directly instead > >> does the exact same thing in the end, but avoids loading a few (4) > >> classes and thus brings > >> us a small startup improvement. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 > >> Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ > >> > >> Thanks! > >> > >> /Claes > >> > > From Alan.Bateman at oracle.com Sun Apr 3 14:55:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 3 Apr 2016 15:55:54 +0100 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57010A68.9050307@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> Message-ID: <57012EFA.9010201@oracle.com> On 03/04/2016 13:19, Claes Redestad wrote: > Hi Remi, > > On 2016-04-03 13:57, Remi Forax wrote: >> Hi Claes, >> the patch is fine for me with the minor nitpick that the static final >> containing Unsafe should be called UNSAFE and not just U. > > sure, I copied the setup/naming convention from ConcurrentHashMap, but > UNSAFE does make it stand out better. > >> >> do you know why BufferedInputStream is loaded in first place during >> the startup of the VM ? > > given the output of -Xlog:classload I think it's first used by > java.lang.System for what becomes System.in. > Yes, initPhase1 (or what used to be initializeSystemClass) will be the first usage. I skimmed the webrev, looks okay to me. I think I would import jdk.internal.misc.Unsafe rather than using the fully qualified class name twice. That will also avoid the line break. -Alan From chris.hegarty at oracle.com Sun Apr 3 15:47:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 3 Apr 2016 16:47:54 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> Message-ID: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Updated webrev, as per comments: http://cr.openjdk.java.net/~chegar/8153181/01/ getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which would move its native implementation into the VM, perf.cpp, but it doesn?t seem worth it, unless future refactoring wanted to get rid of JVM_GetTemporaryDirectory. -Chris. On 2 Apr 2016, at 20:34, Mandy Chung wrote: >> >> On Apr 2, 2016, at 2:53 AM, Alan Bateman wrote: >> >> >> (cc'ing serviceability-dev as this is where this code is maintained). >> >> >>> On 02/04/2016 00:32, Mandy Chung wrote: >>> Hi Chris, >>> >>> Would jdk.internal.vm be appropriate for this VMSupoprt class? >> I agree. >> >>> >>> VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/util.c >>> JDWP calls it and needs to be updated. >> If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. >> >>> >>> VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. >> It could although I assume this means that introducing a new shared library. > > jdk.internal.perf is in java.base. Another option is to move it to jdk.jvmstat that i considered but may not worth it since perf counter is still in java.base. > > Mandy > >> >>> >>> Mandy >>> >>>> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >>>> >>>> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >>>> >>>> sun.misc.VMSupport is a utility class supporting two functions: >>>> 1) the initialization of management Agent properties, and >>>> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >>>> >>>> The initialization of Agent properties is used statically by the java.managment module, >>>> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >>>> The location of VM temporary files is a low-level interface between the libraries and VM. >>>> For these reasons, VMSupport should remain in the base module, but be moved to an >>>> internal package. >>>> >>>> http://cr.openjdk.java.net/~chegar/8153181/00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8153181 >>>> >>>> -Chris. From martinrb at google.com Sun Apr 3 18:29:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Sun, 3 Apr 2016 11:29:57 -0700 Subject: RFR: jsr166 jdk9 integration wave 6 Message-ID: Easy changes to review, up to April Fools day, in part to make room for later unfinished more exciting changes. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ From Alan.Bateman at oracle.com Sun Apr 3 18:44:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 3 Apr 2016 19:44:27 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Message-ID: <5701648B.8060305@oracle.com> On 03/04/2016 16:47, Chris Hegarty wrote: > Updated webrev, as per comments: > http://cr.openjdk.java.net/~chegar/8153181/01/ > > getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which > would move its native implementation into the VM, perf.cpp, but it doesn?t > seem worth it, unless future refactoring wanted to get rid of > JVM_GetTemporaryDirectory. > This looks okay. -Alan From forax at univ-mlv.fr Sun Apr 3 19:34:33 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 3 Apr 2016 21:34:33 +0200 (CEST) Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: References: Message-ID: <723943099.1620291.1459712073220.JavaMail.zimbra@u-pem.fr> Hi Martin, for http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ aka introducing a new constructor seems to be a regression to me, the less overloads we have the better i understand the code. R?mi ----- Mail original ----- > De: "Martin Buchholz" > ?: "core-libs-dev" , "Doug Lea"

, "Paul Sandoz" > , "Chris Hegarty" , "David Holmes" > Envoy?: Dimanche 3 Avril 2016 20:29:57 > Objet: RFR: jsr166 jdk9 integration wave 6 > > Easy changes to review, up to April Fools day, in part to make room > for later unfinished more exciting changes. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > From claes.redestad at oracle.com Sun Apr 3 20:39:26 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 3 Apr 2016 22:39:26 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57012EFA.9010201@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <57012EFA.9010201@oracle.com> Message-ID: <57017F7E.5000805@oracle.com> On 04/03/2016 04:55 PM, Alan Bateman wrote: > > > On 03/04/2016 13:19, Claes Redestad wrote: >> Hi Remi, >> >> On 2016-04-03 13:57, Remi Forax wrote: >>> Hi Claes, >>> the patch is fine for me with the minor nitpick that the static >>> final containing Unsafe should be called UNSAFE and not just U. >> >> sure, I copied the setup/naming convention from ConcurrentHashMap, >> but UNSAFE does make it stand out better. >> >>> >>> do you know why BufferedInputStream is loaded in first place during >>> the startup of the VM ? >> >> given the output of -Xlog:classload I think it's first used by >> java.lang.System for what becomes System.in. >> > Yes, initPhase1 (or what used to be initializeSystemClass) will be the > first usage. > > I skimmed the webrev, looks okay to me. I think I would import > jdk.internal.misc.Unsafe rather than using the fully qualified class > name twice. That will also avoid the line break. > > -Alan > Thanks for looking at this, Alan! Cleaned things up here: http://cr.openjdk.java.net/~redestad/8153334/webrev.02/ /Claes From martinrb at google.com Sun Apr 3 21:08:50 2016 From: martinrb at google.com (Martin Buchholz) Date: Sun, 3 Apr 2016 14:08:50 -0700 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: <723943099.1620291.1459712073220.JavaMail.zimbra@u-pem.fr> References: <723943099.1620291.1459712073220.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks for the review! On Sun, Apr 3, 2016 at 12:34 PM, Remi Forax wrote: > Hi Martin, > for http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ > > aka introducing a new constructor seems to be a regression to me, > the less overloads we have the better i understand the code. For "telescoping constructors" and a parameter that's almost always null, I disagree. There's also the fear that the VM won't optimize away useless volatile write to next. > ParkLoops test is fine too, i suppose it's related to the recent change in the code of TimeUnit to test with different units. No, it fixes a mistake made when introducing timeout factor scaling. The webrev has a link to the bug report https://bugs.openjdk.java.net/browse/JDK-8151501 From forax at univ-mlv.fr Sun Apr 3 22:17:03 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 4 Apr 2016 00:17:03 +0200 (CEST) Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: References: <723943099.1620291.1459712073220.JavaMail.zimbra@u-pem.fr> Message-ID: <1421264514.48409.1459721823940.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Martin Buchholz" > ?: "Remi Forax" > Cc: "core-libs-dev" , "Doug Lea"

, "Paul Sandoz" > , "Chris Hegarty" , "David Holmes" > Envoy?: Dimanche 3 Avril 2016 23:08:50 > Objet: Re: RFR: jsr166 jdk9 integration wave 6 > > Thanks for the review! > > On Sun, Apr 3, 2016 at 12:34 PM, Remi Forax wrote: > > Hi Martin, > > for > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ > > > > aka introducing a new constructor seems to be a regression to me, > > the less overloads we have the better i understand the code. > > For "telescoping constructors" and a parameter that's almost always > null, I disagree. if the parameter is often null, maybe the constructor with 4 parameters is useless, and next should be set explicitly in the few cases it's needed. > There's also the fear that the VM won't optimize away useless volatile > write to next. I've seen the bug [1] reported by Aleksey about Hotspot not being able to remove volatile writes with null in constructor. Here the code is different because val is also a volatile field, and written just before next, so the VM should be able to coalesce two volatile writes, if the VM is not able to do that, it's another bug. Nevertheless, we should only optimize to for the usual cases, so we should only have one constructor that doesn't set next. [...] [1] https://bugs.openjdk.java.net/browse/JDK-8145948 R?mi From mandy.chung at oracle.com Mon Apr 4 01:06:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 3 Apr 2016 18:06:24 -0700 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Message-ID: <5C64C8CB-F67E-4D2F-ADD8-D67B7664A219@oracle.com> > On Apr 3, 2016, at 8:47 AM, Chris Hegarty wrote: > > Updated webrev, as per comments: > http://cr.openjdk.java.net/~chegar/8153181/01/ > > getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which > would move its native implementation into the VM, perf.cpp, but it doesn?t > seem worth it, unless future refactoring wanted to get rid of > JVM_GetTemporaryDirectory. > It looks okay. We should look into this when we look into future clean up work in this area. Mandy From sundararajan.athijegannathan at oracle.com Mon Apr 4 03:29:53 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 4 Apr 2016 08:59:53 +0530 Subject: RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed In-Reply-To: <56FED920.3010207@oracle.com> References: <56FED920.3010207@oracle.com> Message-ID: <5701DFB1.9070209@oracle.com> +1 On 4/2/2016 1:55 AM, Claes Redestad wrote: > Hi, > > seems my recent push for JDK-8152641 broke a jimage test or two. > > While I think these test seem a bit odd, it's apparent that checking > that we're not adding the same resource twice is enough to make the > tests happy for now: > > Webrev: http://cr.openjdk.java.net/~redestad/8153317/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153317 > > Thanks! > > /Claes From chris.hegarty at oracle.com Mon Apr 4 09:39:31 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Apr 2016 10:39:31 +0100 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57017F7E.5000805@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <57012EFA.9010201@oracle.com> <57017F7E.5000805@oracle.com> Message-ID: <57023653.9020108@oracle.com> On 03/04/16 21:39, Claes Redestad wrote: > .... >> > > Thanks for looking at this, Alan! > > Cleaned things up here: > http://cr.openjdk.java.net/~redestad/8153334/webrev.02/ Looks good Claes. -Chris. From ramanand.patil at oracle.com Mon Apr 4 09:50:22 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 4 Apr 2016 02:50:22 -0700 (PDT) Subject: RFR: 8151876: (tz) Support tzdata2016c Message-ID: Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ All the TimeZone related tests are passed after integration. Please note that this patch includes both tzdata2016b and tzdata2016c integration. The tzdata2016b review was abandoned because tzdata2016c was already released. As suggested by Masayoshi, changes are made such that, "GMT+hh:mm" is used for formatting of the newly added TimeZones in tzdata2016b. [This is done to accommodate the IANA's new trial system where the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] Regards, Ramanand. From aleksey.shipilev at oracle.com Mon Apr 4 10:03:34 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 4 Apr 2016 13:03:34 +0300 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57006917.4090200@oracle.com> References: <57006917.4090200@oracle.com> Message-ID: <57023BF6.4010304@oracle.com> On 04/03/2016 03:51 AM, Claes Redestad wrote: > BufferedInputStream is loaded early, and uses > AtomicReferenceFieldUpdater to provide CAS functionality to allow for > closing streams asynchronously. Using Unsafe directly instead does > the exact same thing in the end, but avoids loading a few (4) classes > and thus brings us a small startup improvement. > Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 > Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ I think this one is going too far. A*FU/VarHandles should are supposed to act like a go-to replacement for Unsafe throughout the class library, and we want to shrink the Unsafe exposure. Also, I don't think removing A*FU in favor of Unsafe here wins us anything: there should be no throughput hit, and we *will* load A*FU down the road anyway, negating the startup wins. -Aleksey From chris.hegarty at oracle.com Mon Apr 4 10:24:22 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Apr 2016 11:24:22 +0100 Subject: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport ) Message-ID: <570240D6.4000303@oracle.com> sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code in java.rmi has, then a new small native library is required. http://cr.openjdk.java.net/~chegar/8153286/ https://bugs.openjdk.java.net/browse/JDK-8153286 -Chris. From chris.hegarty at oracle.com Mon Apr 4 10:26:55 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 4 Apr 2016 11:26:55 +0100 Subject: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport ) In-Reply-To: <570240D6.4000303@oracle.com> References: <570240D6.4000303@oracle.com> Message-ID: <5702416F.3000500@oracle.com> [ including build-dev ] > sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should > be moved out of sun.misc and placed into a more appropriate package, > where it can be encapsulated. > > Since GC is only used by RMI, I proposed to move it to the java.rmi > module. Since it has a native component, and no other code in java.rmi > has, then a new small native library is required. > > http://cr.openjdk.java.net/~chegar/8153286/ > https://bugs.openjdk.java.net/browse/JDK-8153286 > > -Chris. From erik.joelsson at oracle.com Mon Apr 4 11:04:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 4 Apr 2016 13:04:05 +0200 Subject: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport ) In-Reply-To: <5702416F.3000500@oracle.com> References: <570240D6.4000303@oracle.com> <5702416F.3000500@oracle.com> Message-ID: <57024A25.4000202@oracle.com> Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? /Erik On 2016-04-04 12:26, Chris Hegarty wrote: > [ including build-dev ] > >> sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should >> be moved out of sun.misc and placed into a more appropriate package, >> where it can be encapsulated. >> >> Since GC is only used by RMI, I proposed to move it to the java.rmi >> module. Since it has a native component, and no other code in java.rmi >> has, then a new small native library is required. >> >> http://cr.openjdk.java.net/~chegar/8153286/ >> https://bugs.openjdk.java.net/browse/JDK-8153286 >> >> -Chris. From dl at cs.oswego.edu Mon Apr 4 11:14:06 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 4 Apr 2016 07:14:06 -0400 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: <1421264514.48409.1459721823940.JavaMail.zimbra@u-pem.fr> References: <723943099.1620291.1459712073220.JavaMail.zimbra@u-pem.fr> <1421264514.48409.1459721823940.JavaMail.zimbra@u-pem.fr> Message-ID: <57024C7E.7010408@cs.oswego.edu> On 04/03/2016 06:17 PM, forax at univ-mlv.fr wrote: ---- >> De: "Martin Buchholz" >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ >>> >>> aka introducing a new constructor seems to be a regression to me, >>> the less overloads we have the better i understand the code. >> >> For "telescoping constructors" and a parameter that's almost always >> null, I disagree. > > if the parameter is often null, maybe the constructor with 4 parameters is useless, and next should be set explicitly in the few cases it's needed. > >> There's also the fear that the VM won't optimize away useless volatile >> write to next. Right. The issue is whether to be explicit about lack of need of a fence, or to hope that the compiler figures it out. Especially in a component as commonly used as CHM, being explicit seems like the right choice. -Doug From nadeesh.tv at oracle.com Mon Apr 4 11:25:55 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 04 Apr 2016 16:55:55 +0530 Subject: RFR:JDK-8148947:DateTimeFormatter pattern letter 'g' In-Reply-To: <56FC16B9.3000806@oracle.com> References: <56FC16B9.3000806@oracle.com> Message-ID: <57024F43.2010503@oracle.com> Gentle reminder On 3/30/2016 11:41 PM, nadeesh tv wrote: > Hi all, > > BUG ID : https://bugs.openjdk.java.net/browse/JDK-8148947 > > Webrev : http://cr.openjdk.java.net/~ntv/8148947/webrev.00/ > > Added new pattern letter 'g' for Modified Julian day. > > Apart from that made clarification to JulianFields and removed > semicolons from docs of DateTimeFormatterBuilder as suggested by Stephen > -- Thanks and Regards, Nadeesh TV From nadeesh.tv at oracle.com Mon Apr 4 11:28:10 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 04 Apr 2016 16:58:10 +0530 Subject: RFR:JDK-8148849:Truncating Duration In-Reply-To: References: <56FA727C.201@oracle.com> <56FBB7AF.3030409@oracle.com> Message-ID: <57024FCA.2080702@oracle.com> Hi, I need one more review for this change Regards, Nadeesh On 3/30/2016 7:03 PM, Stephen Colebourne wrote: > Yes, that looks OK now. > thanks > Stephen > > > On 30 March 2016 at 12:25, nadeesh tv wrote: >> Hi Stephen, >> >> Thanks for the comments. >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8148849/webrev.01/ >> >> Made a change in unit == ChronoUnit.SECONDS also >> >> >> Regards, >> Nadeesh TV >> >> >> On 3/29/2016 6:10 PM, Stephen Colebourne wrote: >>> We're almost there, but looking at the tests, it looks like the >>> behaviour is wrong: >>> >>> The intended behaviour is that >>> -20.5mins (minus 20 minutes 30 secs) should truncate to -20mins >>> -2.1secs truncate to -2secs >>> >>> Note that the truncation is different to Instant here. >>> An Instant truncates towards the far past - like RoundingMode.FLOOR >>> A Duration truncates towards the zero - like RoundingMode.DOWN >>> >>> Stephen >>> >>> >>> On 29 March 2016 at 13:18, nadeesh tv wrote: >>>> Hi all, >>>> >>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8148849 >>>> >>>> Enhanced Duration by adding public Duration truncatedTo(TemporalUnit >>>> unit) >>>> >>>> Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/ >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From Alan.Bateman at oracle.com Mon Apr 4 11:34:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Apr 2016 12:34:53 +0100 Subject: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport ) In-Reply-To: <57024A25.4000202@oracle.com> References: <570240D6.4000303@oracle.com> <5702416F.3000500@oracle.com> <57024A25.4000202@oracle.com> Message-ID: <5702515D.3040502@oracle.com> On 04/04/2016 12:04, Erik Joelsson wrote: > Makefile looks good. > > If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of > libjava, should you also remove it from the mapfile for libjava? > Yes, libjava/mapfile-vers will need to be updated too. It otherwise looks okay to me, just a pity that it requires introducing another native library. -Alan From martinrb at google.com Mon Apr 4 15:45:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 4 Apr 2016 08:45:46 -0700 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <57010A68.9050307@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> Message-ID: On Sun, Apr 3, 2016 at 5:19 AM, Claes Redestad wrote: >> the patch is fine for me with the minor nitpick that the static final >> containing Unsafe should be called UNSAFE and not just U. > > > sure, I copied the setup/naming convention from ConcurrentHashMap, but > UNSAFE does make it stand out better. We adopted the U convention in java.util.concurrent because it makes that performance-obsessed code read better. > I think this one is going too far. > > A*FU/VarHandles should are supposed to act like a go-to replacement for > Unsafe throughout the class library, and we want to shrink the Unsafe > exposure. Also, I don't think removing A*FU in favor of Unsafe here wins > us anything: there should be no throughput hit, and we *will* load A*FU > down the road anyway, negating the startup wins. > > -Aleksey It is surprising to see new uses of Unsafe when we have an ongoing initiative within openjdk (especially from Paul Sandoz) to remove most uses. Varhandles are coming and are expected to replace uses of Unsafe in the JDK. From volker.simonis at gmail.com Mon Apr 4 16:47:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Apr 2016 18:47:38 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version Message-ID: Hi, can I please have a review for this small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to VERSION_NUMBER which is the same value which is also used for the java.version property. This is a bad idea, because VERSION_NUMBER is a dot separated sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. for every build and/or update version). If we are configuring with "--with-version-patch=1" for example, VERSION_NUMBER and java.version will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and java.specification.version have the same, dotted value. And it breaks a lot of legacy applications which parse java.specification.version as a float number. That code would still work if java.specification.version would be a concrete number (e.g. '9' or '10'). I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in common/autoconf/spec.gmk.in. This should be the "right value" until we get a specification change during a major release which hasn't happened for quite some time now. Regards, Volker From spliterator at gmail.com Mon Apr 4 19:28:25 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Mon, 4 Apr 2016 21:28:25 +0200 Subject: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations In-Reply-To: <755756441.20160401222505@gmail.com> References: <755756441.20160401222505@gmail.com> Message-ID: Hi Tagir, good catch! I like the proposal. > > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > I think IntStream.asDoubleStream() can also preserve DISTINCT as different ints can't be mapped to the same double. Math.ulp((double) Integer.MIN_VALUE) ~ 4.7E-7 in contrast to Math.ulp((double) Long.MIN_VALUE) = 2048.0 So there are more than enough doubles in the vicinity of large int values. It's only when ulp get's >= 1.0 that distinct integral values need to be mapped to the same double (that happens between 1.0E15 and 1.0E16 for longs). Please anyone correct me if I'm wrong. Regards, Stefan 2016-04-01 18:25 GMT+02:00 Tagir F. Valeev : > Hello! > > Please review and sponsor the following patch: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ > > The patch preserves more characteristics on primitive stream > operations: > IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT > IntStream.asLongStream() preserves SORTED and DISTINCT > IntStream.asDoubleStream() and LongStream.asDoubleStream() preserves SORTED > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > > Fixing the boxed() case is especially important as distinct() for > primitive streams is implemented like boxed().distinct().unbox, so the > actual distinct() operation cannot take the advantage of DISTINCT flag > (skip the operation at all) or SORTED flag (switch to more efficient > implementation). > > Here's the small JMH benchmark which measures the performance boost of > quite common operation: sort the input numbers and leave only distinct > ones: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/jmh/ > > new Random(1).ints(size).sorted().distinct().toArray() > > I've got the following results. > > 9ea+111: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,612 ? 0,004 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 92,848 ? 1,039 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 32147,205 ? 3487,422 us/op > > 9ea+111 patched: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,435 ? 0,001 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 40,555 ? 0,772 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 9031,651 ? 73,956 us/op > > With best regards, > Tagir Valeev. > From Roger.Riggs at Oracle.com Mon Apr 4 21:50:05 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 4 Apr 2016 17:50:05 -0400 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <56FFABED.2060708@gmail.com> References: <56B72242.7050102@gmail.com> <56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> Message-ID: <5702E18D.7010807@Oracle.com> Hi Peter, Stepping back just a bit. The old Cleaner running on the Reference processing thread had a few (2) very well controlled functions, reference processing and deallocating DirectByteBuffers. Maybe we can't do too much better than that. The old worst case performance/latency wise was the reference processing thread did the work and the allocating thread did very little synchronizing and just did the retries. In the best case, all the real work was done by the allocating thread, if the interactions with GC work out perfectly. But it was still the case that the buffer alloc/dealloc throughput was met with the division of work separating the reference processing thread and the allocating thread. The function that can only be provided by CleanerImpl / Reference processing thread state is knowledge that the cleaning queue is empty. The helping functions were/are a bit troublesome because of mixing execution environments of the thread allocating direct buffers and the cleanables and it seemed that more than a little complexity was needed to compensate. If the bottleneck in processing is between the reference processing and cleanup then it should be ok (based on previous comments) for the CleanerImpl to help with reference processing (after it has an empty queue and before it blocks waiting or in every loop). Though if you already tried this combination, I don't recall the results. As you pointed out it would be more efficient if the allocating thread could be aware when it was known there was nothing ready to cleanup so it can retry and invoke GC or throw out of memory if appropriate. Adding a method that returned the count of completed cleaning cycles (or similar) to CleanerImpl could exist with a minimal of coupling and still provide the information needed without commingling the execution threads. I don't see the need to change Cleaner to an interface to be able to provide an additional method on CleanerImpl or a subclass and a factory method could provide for a clean and very targeted interface to Bits/Direct buffer. I'm sorry I haven't had time to try out concretely what I have in mind. Please correct or remind me of missing salient considerations. Thanks, Roger On 4/2/2016 7:24 AM, Peter Levart wrote: > Hi Roger, > > Thanks for looking at the patch. > > On 04/02/2016 01:31 AM, Roger Riggs wrote: >> Hi Peter, >> >> I overlooked the introduction of another nested class (Task) to >> handle the cleanup. >> But there are too many changes to see which ones solve a single problem. >> >> Sorry to make more work, but I think we need to go back to the >> minimum necessary >> change to make progress on this. Omit all of the little cleanups >> until the end >> or do them first and separately. >> >> Thanks, Roger > > No Problem. I understand. So let's proceed in stages. Since part1 is > already pushed, I'll call part2 stages with names: part2.1, part2.2, > ... and I'll start counting webrev revisions from 01 again, so webrev > names will be in the form: webrev.part2.1.rev01. Each part will be an > incremental change to the previous one. > > part2.1: This is preparation work to be able to have an extended > java.lang.ref.Cleaner type for internal use. Since > java.lang.ref.Cleaner is a final class, I propose to make it an > interface instead: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ > > This is a source-compatible change and it also simplifies > implementation (no injection of Cleaner.impl access function into > CleanerImpl needed any more). What used to be java.lang.ref.Cleaner is > renamed to jdk.internal.ref.CleanerImpl. What used to be > jdk.internal.ref.CleanerImpl is now a nested static class > jdk.internal.ref.CleanerImpl.Task (because it implements Runnable). > Otherwise nothing has changed in the overall architecture of the > Cleaner except that public-facing API is now an interface instead of a > final class. This allows specifying internal extension interface and > internal extension implementation. > > CleanerTest passes with this change. > > So what do you think? > > Regards, Peter > >> >> >> >> >> On 4/1/16 5:51 PM, Roger Riggs wrote: >>> Hi Peter, >>> >>> Thanks for the diffs to look at. >>> >>> Two observations on the changes. >>> >>> - The Cleaner instance was intentionally and necessarily different >>> than the CleanerImpl to enable >>> the CleanerImpl and its thread to terminate if the Cleaner is not >>> longer referenced. >>> Folding them into a single object breaks that. >>> >>> Perhaps it is not too bad for ExtendedCleaner to subclass >>> CleanerImpl with the cleanup helper/supplier behavior >>> and expose itself to Bits. There will be fewer moving parts. There >>> is no need for two factory methods for >>> ExtendedCleaner unless you are going to use a separate ThreadFactory. >>> >>> - The Deallocator (and now Allocator) nested classes are identical, >>> and there is a separate copy for each >>> type derived from the Direct-X-template. But it may not be worth >>> fixing until the rest of it is settled to avoid >>> more moving parts. >>> >>> I don't have an opinion on the code changes in Reference, that's >>> different kettle of fish. >>> >>> More next week. >>> >>> Have a good weekend, Roger >>> >>> >>> On 4/1/2016 12:46 PM, Peter Levart wrote: >>>> >>>> >>>> On 04/01/2016 06:08 PM, Peter Levart wrote: >>>>> >>>>> >>>>> On 04/01/2016 05:18 PM, Peter Levart wrote: >>>>>> @Roger: >>>>>> >>>>>> ... >>>>>> >>>>>> About entanglement between nio Bits and >>>>>> ExtendedCleaner.retryWhileHelpingClean(). It is the same level of >>>>>> entanglement as between the DirectByteBuffer constructor and >>>>>> Cleaner.register(). In both occasions an action is provided to >>>>>> the Cleaner. Cleaner.register() takes a cleanup action and >>>>>> ExtendedCleaner.retryWhileHelpingClean() takes a retriable >>>>>> "allocating" or "reservation" action. "allocation" or >>>>>> "reservation" is the opposite of cleanup. Both methods are >>>>>> encapsulated in the same object because those two functions must >>>>>> be coordinated. So I think that collocating them together makes >>>>>> sense. What do you think? >>>>> >>>>> ...to illustrate what I mean, here's a variant that totally >>>>> untangles Bits from Cleaner and moves the whole Cleaner >>>>> interaction into the DirectByteBuffer itself: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.13.part2/ >>>>> >>>>> >>>>> Notice the symmetry between Cleaner.retryWhileHelpingClean : >>>>> Cleaner.register and Allocator : Deallocator ? >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>> >>>> And here's also a diff between webrev.12.part2 and webrev.13.part2: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.diff.12to13.part2/ >>>> >>>> >>>> Regards, Peter >>>> >>> >> > From masayoshi.okutsu at oracle.com Mon Apr 4 23:39:04 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 5 Apr 2016 08:39:04 +0900 Subject: RFR: 8151876: (tz) Support tzdata2016c In-Reply-To: References: Message-ID: <5702FB18.1060300@oracle.com> Looks good to me. But I'd like someone from java.time to review the changes to see if it's OK for java.time. Masayoshi On 4/4/2016 6:50 PM, Ramanand Patil wrote: > Hi all, > > Please review the latest TZDATA (tzdata2016c) integration to JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 > > Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ > > All the TimeZone related tests are passed after integration. > > > > Please note that this patch includes both tzdata2016b and tzdata2016c integration. The tzdata2016b review was abandoned because tzdata2016c was already released. > > As suggested by Masayoshi, changes are made such that, "GMT+hh:mm" is used for formatting of the newly added TimeZones in tzdata2016b. > > [This is done to accommodate the IANA's new trial system where the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] > > > > Regards, > > Ramanand. From brent.christian at oracle.com Mon Apr 4 23:45:31 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 04 Apr 2016 16:45:31 -0700 Subject: RFR 8153123 : Streamline StackWalker code Message-ID: <5702FC9B.7020600@oracle.com> Hi, I'd like to check in some footprint and code reduction changes to the java.lang.StackWalker implementation. Webrev: http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153123 A summary of the changes: * remove the "stackwalk.newThrowable" system property and "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking * Streamline StackFrameInfo fields * Refactor/streamline StackStreamFactory (no more separate classes[]/StackFrame[] arrays, remove unneeded (for now) StackStreamFactory.StackTrace class) Given the hotspot changes, I plan to push this through hs-rt. Thanks, -Brent From mandy.chung at oracle.com Tue Apr 5 01:29:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 4 Apr 2016 18:29:53 -0700 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5702FC9B.7020600@oracle.com> References: <5702FC9B.7020600@oracle.com> Message-ID: > On Apr 4, 2016, at 4:45 PM, Brent Christian wrote: > > Hi, > > I'd like to check in some footprint and code reduction changes to the java.lang.StackWalker implementation. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153123 > This looks good to me. One thing to mention is that this patch is a follow-up work from the investigation on what it takes to enable Throwable to use StackWalker (JDK-8141239). The current built-in VM backtrace is very compact and performant. We have identified and prototypes the performance improvements if Throwable backtrace is generated using stack walker. There are some performance gaps that we agree to defer JDK-8141239 to a future release and improve the footprint performance and GC throughput concerns when MemberNames are stored in the throwable backtrace. Mandy From chris.hegarty at oracle.com Tue Apr 5 09:51:46 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 5 Apr 2016 10:51:46 +0100 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module Message-ID: sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. http://cr.openjdk.java.net/~chegar/8153498/ -Chris. From dawid.weiss at gmail.com Tue Apr 5 10:47:05 2016 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 5 Apr 2016 12:47:05 +0200 Subject: toRealPath throws InternalError: Should not get here on Windows (paths with junctions) In-Reply-To: <56E80691.3030607@oracle.com> References: <56E7F1F6.90405@oracle.com>

<56E80691.3030607@oracle.com> Message-ID: I did a bit more digging. I can reproduce this every time on my machine if: 1) I open cmd from total commander (64 bit or 32 bit, doesn't matter); 2) from that cmd run the simple example in Java that attempts to resolve real path; this ends in InternalError. On the other hand, if I run cmd from the start menu, everything works fine. total commander is clean (checked md5 to rule out viruses or whatever). I have no idea what this is -- I think the problem can be marked as "non-reproducible", maybe it's a glitch in my system somewhere. Sorry for the noise. Dawid On Tue, Mar 15, 2016 at 1:56 PM, Rory O'Donnell wrote: > Hi Dawid, > > I will update bug. > > Rgds,Rory > > > On 15/03/2016 12:53, Dawid Weiss wrote: >> >> This must be more complicated than I thought because the same code >> passes with flying colors on another (fairly fresh install) of Windows >> 10... I don't know what the difference is, to be honest (I have >> Windows 10 Pro N). I'll try to dig deeper, time permitting, but >> perhaps a comment on the eventual Jira issue would be sensible (can't >> do it myself, no Jira access). >> >> Dawid >> >> On Tue, Mar 15, 2016 at 1:01 PM, Dawid Weiss >> wrote: >>> >>> I filed an issue (Review ID: JI-9032181). In any case, I checked with >>> Java 7, 8 and the ea: >>> >>> Java(TM) SE Runtime Environment (build >>> 9-ea+109-2016-03-09-181019.javare.4620.nc) >>> >>> The issue only affects Windows 10 (tested on 64-bit only), Windows 7 >>> behaves fine. The following sequence is enough to get the stack trace: >>> >>> mkdir foo >>> mklink /J bar foo >>> java -cp . Test bar >>> >>> The Test.java code is: >>> import java.io.*; >>> import java.nio.file.*; >>> >>> public class Test { >>> public static void main(String[] args) throws Exception { >>> Path p = Paths.get(args[0]); >>> System.out.println("p.toRealPath(): " + p.toRealPath()); >>> } >>> } >>> >>> and the stack trace: >>> >>> Exception in thread "main" java.lang.InternalError: Should not get here >>> at >>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native >>> Method) >>> at >>> sun.nio.fs.WindowsLinkSupport.getFinalPath(WindowsLinkSupport.java:77) >>> at >>> sun.nio.fs.WindowsLinkSupport.getRealPath(WindowsLinkSupport.java:242) >>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:840) >>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:44) >>> at Test.main(Test.java:10) >>> >>> Dawid >>> >>> On Tue, Mar 15, 2016 at 12:28 PM, Alan Bateman >>> wrote: >>>> >>>> On 15/03/2016 11:19, Dawid Weiss wrote: >>>>> >>>>> I couldn't find an appropriate bug in bugzilla, but this fails >>>>> reliably for me with Java 8 and 9 on Windows 10, 64-bit: >>>>> >>>>> mkdir foo >>>>> mklink /J bar foo >>>>> cd bar >>>>> java -cp Test . >>>>> >>>>> where Test.java is as simple as: >>>>> >>>>> import java.io.*; >>>>> import java.nio.file.*; >>>>> >>>>> public class Test { >>>>> public static void main(String[] args) throws Exception { >>>>> System.out.println("p.toRealPath(): " + >>>>> Paths.get(args[0]).toRealPath()); >>>>> } >>>>> } >>>>> >>>>> The thrown error shows: >>>>> >>>>> Exception in thread "main" java.lang.InternalError: Should not get here >>>>> at >>>>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native >>>>> Method) >>>> >>>> There are a number of win32 functions that this code uses GetProcAddress >>>> to >>>> get their address in kernel32. This dates back to when we had to support >>>> Windows XP. This should be cleaned up now. Doesn't explain why you are >>>> seeing though, can you submit a bug? >>>> >>>> -Alan > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > From lois.foltan at oracle.com Tue Apr 5 13:59:47 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 09:59:47 -0400 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module In-Reply-To: References: Message-ID: <5703C4D3.1090108@oracle.com> Hotspot changes look good. Lois On 4/5/2016 5:51 AM, Chris Hegarty wrote: > sun.misc.PostVMInitHook::run is called by the VM once its initialization is > complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. > Since sun.misc will be moved out of the base module, the VM should > look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. > > http://cr.openjdk.java.net/~chegar/8153498/ > > -Chris. From peter.levart at gmail.com Tue Apr 5 14:41:26 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 Apr 2016 16:41:26 +0200 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <5702E18D.7010807@Oracle.com> References: <56B72242.7050102@gmail.com> <56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> Message-ID: <5703CE96.4040001@gmail.com> Hi Roger, On 04/04/2016 11:50 PM, Roger Riggs wrote: > Hi Peter, > > Stepping back just a bit. Right, let's clear up. > > The old Cleaner running on the Reference processing thread had a few > (2) very well controlled > functions, reference processing and deallocating DirectByteBuffers. > Maybe we can't do too much > better than that. ...yes, at the beginning, until it was (re)used for other purposes too, in: java.lang.ProcessImpl, java.lang.invoke.MethodHandleNatives.CallSiteContext, jdk.internal.perf.Perf, sun.nio.ch.IOVecWrapper, sun.nio.fs.NativeBuffer and sun.java2d.marlin.OffHeapArray. But those other usages have been converted to use new java.lang.ref.Cleaner so old cleaner is now back to basics - DirectByteBuffers. And with that, DirectByteBuffers allocating threads only help ReferenceHandler thread enqueue References and execute DirectByteBuffer deallocators, which is an improvement. But should we keep that status quo? It's nothing wrong with it as it is, except I think we can do better. > > The old worst case performance/latency wise was the reference > processing thread > did the work and the allocating thread did very little synchronizing > and just did the retries. The number of retries was exactly the same as the number of References helped to be enqueued or in case of Cleaner(s), executed: // retry while helping enqueue pending Reference objects // which includes executing pending Cleaner(s) which includes // Cleaner(s) that free direct buffer memory while (jlra.tryHandlePendingReference()) { if (tryReserveMemory(size, cap)) { return; } } If the share of pending References that are also Cleaners was high, chances were higher that not much helping was needed as one cleaned DBB.Deallocator could unreserve enough memory for next reservation attempt to succeed. So allocating thread helped only until it succeeded in reserving the native memory leaving the rest of work to another allocating request/thread or to ReferenceHandler. > In the best case, all the real work was done by the allocating thread, > if the interactions with GC > work out perfectly. But it was still the case that the buffer > alloc/dealloc throughput was > met with the division of work separating the reference processing > thread and the allocating thread. Yes, whichever thread was quicker. If ReferenceHandler thread had been waking up from wait() for a long time, allocating thread could have already processed all the References before ReferenceHandler finally started to look around. If there were lots of new pending referenced discovered, ReferenceHandler thread could finally join the party and fight for the same lock... > > The function that can only be provided by CleanerImpl / Reference > processing thread state is > knowledge that the cleaning queue is empty. ...and that the discovered pending references have actually been enqueued before that... > The helping functions were/are a bit troublesome because of mixing > execution > environments of the thread allocating direct buffers and the > cleanables and it seemed that > more than a little complexity was needed to compensate. I totally agree. > > If the bottleneck in processing is between the reference processing > and cleanup > then it should be ok (based on previous comments) for the CleanerImpl > to help with > reference processing (after it has an empty queue and before it blocks > waiting or in every loop). > Though if you already tried this combination, I don't recall the results. I don't thing there is a problem because of any bottleneck. And if there was a bottleneck we would only have a problem with allocation/deallocation throughput and not with OOME(s). The problem is because reference discovery is not triggered as a result of native memory reservation approaching or reaching the limit. There is no heap memory pressure from DirectByteBuffer(s) because they are small objects. So a mechanism must be in place that triggers reference discovery and waits for discovered references to be processed before failing the native memory allocation. A mechanism that tries to simulate what happens with GC when there is heap memory pressure. GC guarantees that full-GC is executed and heap allocation retried after that before finally giving up with OOME. We need a mechanism that attempts to do the same for direct memory. Throughput is a nice property but we are not directly seeking its improvement. We just not want to make things much worse. Helping the Cleaner thread to process cleanup functions is the easiest way to wait for cleanup functions to be processed and for queue to drain. Simply because of ReferenceQueue API. If you poll() next Reference from the queue and get null, you know the queue is empty, but if you get something, you have to execute it and not just ignore it. Maybe we could patch into the ReferenceQueue implementation and extend its API with an internal method that would not return next Reference but just information that ReferenceHandler thread has done so or that the queue is empty. I'll think about it. > > As you pointed out it would be more efficient if the allocating thread > could be aware > when it was known there was nothing ready to cleanup so it can retry > and invoke GC or > throw out of memory if appropriate. > Adding a method that returned the count of completed cleaning cycles > (or similar) > to CleanerImpl could exist with a minimal of coupling and still provide > the information needed without commingling the execution threads. I'll think about how to surface this functionality in the CleanerImpl most elegantly. The functionality of providing only the counter of cleaning cycles as a getter might not be most appropriate. What we also need is some mechanism to wait and be woken up to retry reservation only at appropriate points in time otherwise allocating threads could just spin eating CPU time. So my latest attempt was to encapsulate the entire retry logic inside ExtendedCleaner with ByteBuffer/Bits only providing allocation function to this logic, which in my view of API is pretty decoupled and general. > > I don't see the need to change Cleaner to an interface to be able to > provide > an additional method on CleanerImpl or a subclass and a factory method > could > provide for a clean and very targeted interface to Bits/Direct buffer. I would like this to be an instance method so it would naturally pertain to a particular Cleaner instance. Or it could be a static method that takes a Cleaner instance. One of my previous webrevs did have such method on the CleanerImpl, but I was advised to move it to Cleaner as a package-private method and expose it via SharedSecrets to internal code. I feel such "camouflage" is very awkward now that we have modules and other mechanisms exist. So I thought it would be most elegant to make Cleaner an interface so it can be extended with an internal interface to communicate intent in a type-safe and auto-discoverable way. The change to make it interface: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ ...actually simplifies implementation (33 lines removed in total) and could be seen as an improvement in itself. Are you afraid that if Cleaner was an interface, others would attempt to make implementations of it? Now that we have default methods on interfaces it is easy to compatibly extend the API even if it is an interface so that no 3rd party implementations are immediately broken. Are you thinking of security implications when some code is handed a Cleaner instance that it doesn't trust? I don't think there is a utility for Cleaner instances to be passed from untrusted to trusted code, do you? In the end it doesn't really matter. We can do it one way or the other. I just feel that using an interface is cleaner. > > I'm sorry I haven't had time to try out concretely what I have in mind. > Please correct or remind me of missing salient considerations. The bottom line is that we need a mechanism that: - triggers reference discovery when native memory limit is approached or reached - retires native memory reservation at appropriate time slots until succeeding or until all pending references have been processed and Cleanables executed at which time native memory reservation can fail with OOME. - if possible, doesn't execute cleanup functions by the allocating thread but just waits for system threads to do the job. - when triggered, does not make native memory allocation a bottleneck. I think that what I did in my latest webrevs with ReferenceHandler thread is an improvement in minimizing contended synchronization and interference of allocating thread(s) with Reference enqueue-ing. But interaction of allocating thread(s) with Cleaner background thread could be improved and I have a couple of ideas to explore. > > Thanks, Roger > Regards, Peter > > On 4/2/2016 7:24 AM, Peter Levart wrote: >> Hi Roger, >> >> Thanks for looking at the patch. >> >> On 04/02/2016 01:31 AM, Roger Riggs wrote: >>> Hi Peter, >>> >>> I overlooked the introduction of another nested class (Task) to >>> handle the cleanup. >>> But there are too many changes to see which ones solve a single >>> problem. >>> >>> Sorry to make more work, but I think we need to go back to the >>> minimum necessary >>> change to make progress on this. Omit all of the little cleanups >>> until the end >>> or do them first and separately. >>> >>> Thanks, Roger >> >> No Problem. I understand. So let's proceed in stages. Since part1 is >> already pushed, I'll call part2 stages with names: part2.1, part2.2, >> ... and I'll start counting webrev revisions from 01 again, so webrev >> names will be in the form: webrev.part2.1.rev01. Each part will be an >> incremental change to the previous one. >> >> part2.1: This is preparation work to be able to have an extended >> java.lang.ref.Cleaner type for internal use. Since >> java.lang.ref.Cleaner is a final class, I propose to make it an >> interface instead: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ >> >> This is a source-compatible change and it also simplifies >> implementation (no injection of Cleaner.impl access function into >> CleanerImpl needed any more). What used to be java.lang.ref.Cleaner >> is renamed to jdk.internal.ref.CleanerImpl. What used to be >> jdk.internal.ref.CleanerImpl is now a nested static class >> jdk.internal.ref.CleanerImpl.Task (because it implements Runnable). >> Otherwise nothing has changed in the overall architecture of the >> Cleaner except that public-facing API is now an interface instead of >> a final class. This allows specifying internal extension interface >> and internal extension implementation. >> >> CleanerTest passes with this change. >> >> So what do you think? >> >> Regards, Peter >> >>> >>> >>> >>> >>> On 4/1/16 5:51 PM, Roger Riggs wrote: >>>> Hi Peter, >>>> >>>> Thanks for the diffs to look at. >>>> >>>> Two observations on the changes. >>>> >>>> - The Cleaner instance was intentionally and necessarily different >>>> than the CleanerImpl to enable >>>> the CleanerImpl and its thread to terminate if the Cleaner is not >>>> longer referenced. >>>> Folding them into a single object breaks that. >>>> >>>> Perhaps it is not too bad for ExtendedCleaner to subclass >>>> CleanerImpl with the cleanup helper/supplier behavior >>>> and expose itself to Bits. There will be fewer moving parts. There >>>> is no need for two factory methods for >>>> ExtendedCleaner unless you are going to use a separate ThreadFactory. >>>> >>>> - The Deallocator (and now Allocator) nested classes are identical, >>>> and there is a separate copy for each >>>> type derived from the Direct-X-template. But it may not be worth >>>> fixing until the rest of it is settled to avoid >>>> more moving parts. >>>> >>>> I don't have an opinion on the code changes in Reference, that's >>>> different kettle of fish. >>>> >>>> More next week. >>>> >>>> Have a good weekend, Roger >>>> >>>> >>>> On 4/1/2016 12:46 PM, Peter Levart wrote: >>>>> >>>>> >>>>> On 04/01/2016 06:08 PM, Peter Levart wrote: >>>>>> >>>>>> >>>>>> On 04/01/2016 05:18 PM, Peter Levart wrote: >>>>>>> @Roger: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> About entanglement between nio Bits and >>>>>>> ExtendedCleaner.retryWhileHelpingClean(). It is the same level >>>>>>> of entanglement as between the DirectByteBuffer constructor and >>>>>>> Cleaner.register(). In both occasions an action is provided to >>>>>>> the Cleaner. Cleaner.register() takes a cleanup action and >>>>>>> ExtendedCleaner.retryWhileHelpingClean() takes a retriable >>>>>>> "allocating" or "reservation" action. "allocation" or >>>>>>> "reservation" is the opposite of cleanup. Both methods are >>>>>>> encapsulated in the same object because those two functions must >>>>>>> be coordinated. So I think that collocating them together makes >>>>>>> sense. What do you think? >>>>>> >>>>>> ...to illustrate what I mean, here's a variant that totally >>>>>> untangles Bits from Cleaner and moves the whole Cleaner >>>>>> interaction into the DirectByteBuffer itself: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.13.part2/ >>>>>> >>>>>> >>>>>> Notice the symmetry between Cleaner.retryWhileHelpingClean : >>>>>> Cleaner.register and Allocator : Deallocator ? >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>> >>>>> And here's also a diff between webrev.12.part2 and webrev.13.part2: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.diff.12to13.part2/ >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>> >>> >> > From rory.odonnell at oracle.com Tue Apr 5 14:46:45 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 5 Apr 2016 15:46:45 +0100 Subject: toRealPath throws InternalError: Should not get here on Windows (paths with junctions) In-Reply-To: References: <56E7F1F6.90405@oracle.com>

<56E80691.3030607@oracle.com> Message-ID: <5703CFD5.9040803@oracle.com> Hi Dawid, I updated the bug. Rgds,Rory On 05/04/2016 11:47, Dawid Weiss wrote: > I did a bit more digging. I can reproduce this every time on my machine if: > > 1) I open cmd from total commander (64 bit or 32 bit, doesn't matter); > 2) from that cmd run the simple example in Java that attempts to > resolve real path; this ends in InternalError. > > On the other hand, if I run cmd from the start menu, everything works > fine. total commander is clean > (checked md5 to rule out viruses or whatever). > > I have no idea what this is -- I think the problem can be marked as > "non-reproducible", maybe it's a glitch in my system somewhere. Sorry > for the noise. > > Dawid > > > On Tue, Mar 15, 2016 at 1:56 PM, Rory O'Donnell > wrote: >> Hi Dawid, >> >> I will update bug. >> >> Rgds,Rory >> >> >> On 15/03/2016 12:53, Dawid Weiss wrote: >>> This must be more complicated than I thought because the same code >>> passes with flying colors on another (fairly fresh install) of Windows >>> 10... I don't know what the difference is, to be honest (I have >>> Windows 10 Pro N). I'll try to dig deeper, time permitting, but >>> perhaps a comment on the eventual Jira issue would be sensible (can't >>> do it myself, no Jira access). >>> >>> Dawid >>> >>> On Tue, Mar 15, 2016 at 1:01 PM, Dawid Weiss >>> wrote: >>>> I filed an issue (Review ID: JI-9032181). In any case, I checked with >>>> Java 7, 8 and the ea: >>>> >>>> Java(TM) SE Runtime Environment (build >>>> 9-ea+109-2016-03-09-181019.javare.4620.nc) >>>> >>>> The issue only affects Windows 10 (tested on 64-bit only), Windows 7 >>>> behaves fine. The following sequence is enough to get the stack trace: >>>> >>>> mkdir foo >>>> mklink /J bar foo >>>> java -cp . Test bar >>>> >>>> The Test.java code is: >>>> import java.io.*; >>>> import java.nio.file.*; >>>> >>>> public class Test { >>>> public static void main(String[] args) throws Exception { >>>> Path p = Paths.get(args[0]); >>>> System.out.println("p.toRealPath(): " + p.toRealPath()); >>>> } >>>> } >>>> >>>> and the stack trace: >>>> >>>> Exception in thread "main" java.lang.InternalError: Should not get here >>>> at >>>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native >>>> Method) >>>> at >>>> sun.nio.fs.WindowsLinkSupport.getFinalPath(WindowsLinkSupport.java:77) >>>> at >>>> sun.nio.fs.WindowsLinkSupport.getRealPath(WindowsLinkSupport.java:242) >>>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:840) >>>> at sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:44) >>>> at Test.main(Test.java:10) >>>> >>>> Dawid >>>> >>>> On Tue, Mar 15, 2016 at 12:28 PM, Alan Bateman >>>> wrote: >>>>> On 15/03/2016 11:19, Dawid Weiss wrote: >>>>>> I couldn't find an appropriate bug in bugzilla, but this fails >>>>>> reliably for me with Java 8 and 9 on Windows 10, 64-bit: >>>>>> >>>>>> mkdir foo >>>>>> mklink /J bar foo >>>>>> cd bar >>>>>> java -cp Test . >>>>>> >>>>>> where Test.java is as simple as: >>>>>> >>>>>> import java.io.*; >>>>>> import java.nio.file.*; >>>>>> >>>>>> public class Test { >>>>>> public static void main(String[] args) throws Exception { >>>>>> System.out.println("p.toRealPath(): " + >>>>>> Paths.get(args[0]).toRealPath()); >>>>>> } >>>>>> } >>>>>> >>>>>> The thrown error shows: >>>>>> >>>>>> Exception in thread "main" java.lang.InternalError: Should not get here >>>>>> at >>>>>> sun.nio.fs.WindowsNativeDispatcher.GetFinalPathNameByHandle(Native >>>>>> Method) >>>>> There are a number of win32 functions that this code uses GetProcAddress >>>>> to >>>>> get their address in kernel32. This dates back to when we had to support >>>>> Windows XP. This should be cleaned up now. Doesn't explain why you are >>>>> seeing though, can you submit a bug? >>>>> >>>>> -Alan >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From claes.redestad at oracle.com Tue Apr 5 15:15:14 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 5 Apr 2016 17:15:14 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> Message-ID: <5703D682.1080300@oracle.com> On 04/04/2016 05:45 PM, Martin Buchholz wrote: >> I think this one is going too far. >> >> A*FU/VarHandles should are supposed to act like a go-to replacement for >> Unsafe throughout the class library, and we want to shrink the Unsafe >> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins >> us anything: there should be no throughput hit, and we*will* load A*FU >> down the road anyway, negating the startup wins. >> >> -Aleksey > It is surprising to see new uses of Unsafe when we have an ongoing > initiative within openjdk (especially from Paul Sandoz) to remove most > uses. Varhandles are coming and are expected to replace uses of > Unsafe in the JDK. This is just a very minor win on hello world/-version style tests, so I'm happy to withdraw this if other early usages, such as CHM, is moving to VarHandles anyhow. OTOH using dangerous, internal APIs like this rather than nice, public APIs early in the VM bootstrap has other merits, such as not unintentionally causing bootstrap issues. Say, I don't know if VarHandles have any dependencies on java.lang.invoke currently... /Claes From volker.simonis at gmail.com Tue Apr 5 17:25:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Apr 2016 19:25:33 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Hi, can somebody please review this trivial change? Regards, Volker On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis wrote: > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > > Currently the value of the java.specification.version property comes > from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is > currently set to VERSION_NUMBER which is the same value which is also > used for the java.version property. > > This is a bad idea, because VERSION_NUMBER is a dot separated sequence > of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. > for every build and/or update version). If we are configuring with > "--with-version-patch=1" for example, VERSION_NUMBER and java.version > will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION > and java.specification.version have the same, dotted value. And it > breaks a lot of legacy applications which parse > java.specification.version as a float number. That code would still > work if java.specification.version would be a concrete number (e.g. > '9' or '10'). > > I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in > common/autoconf/spec.gmk.in. This should be the "right value" until we > get a specification change during a major release which hasn't > happened for quite some time now. > > Regards, > Volker From coleen.phillimore at oracle.com Tue Apr 5 17:29:11 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 13:29:11 -0400 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5703F579.8050702@oracle.com> References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> Message-ID: <5703F5E7.4060404@oracle.com> Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: > > Hi, I've reviewed the hotspot changes and some of the jdk changes. > This looks really good. > > One comment about the jvm function names: > > I think FillInStackTraceElement is too close of a name to > Throwable::fill_in_stack_trace(). > > -JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame)) > +JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject > frame, jobject stack)) > JVMWrapper("JVM_SetMethodInfo"); > - Handle stackFrame(THREAD, JNIHandles::resolve(frame)); > - java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD); > + Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); > + Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); > + java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info, > stack_trace_element, THREAD); JVM_END > > > And the function is called fill_methodInfo in the javaClasses function. > > I think the JVM and the java_lang_StackFrameInfo function names should > be closer. > > I wonder if the name JVM_ToStackFrameElement() and > java_lang_StackFrameInfo::to_stack_frame_element() would be better and > then it'd match the Java name. > > Thanks! > Coleen > > On 4/4/16 9:29 PM, Mandy Chung wrote: >>> On Apr 4, 2016, at 4:45 PM, Brent Christian >>> wrote: >>> >>> Hi, >>> >>> I'd like to check in some footprint and code reduction changes to >>> the java.lang.StackWalker implementation. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8153123 >>> >> This looks good to me. >> >> One thing to mention is that this patch is a follow-up work from the >> investigation on what it takes to enable Throwable to use StackWalker >> (JDK-8141239). The current built-in VM backtrace is very compact and >> performant. We have identified and prototypes the performance >> improvements if Throwable backtrace is generated using stack walker. >> There are some performance gaps that we agree to defer JDK-8141239 to >> a future release and improve the footprint performance and GC >> throughput concerns when MemberNames are stored in the throwable >> backtrace. >> >> Mandy >> > From claes.redestad at oracle.com Tue Apr 5 18:10:56 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 5 Apr 2016 20:10:56 +0200 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5702FC9B.7020600@oracle.com> References: <5702FC9B.7020600@oracle.com> Message-ID: <5703FFB0.5090303@oracle.com> Hi, On 04/05/2016 01:45 AM, Brent Christian wrote: > Hi, > > I'd like to check in some footprint and code reduction changes to the > java.lang.StackWalker implementation. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ this looks really good to me. It seems the new implementation of StackFrameInfo::toStackTraceElement reads the volatile field ste twice on the fast path, though, so perhaps consider something like this: + StackTraceElement s = ste; + if (s == null) { + synchronized(this) { + s = ste; + if (s == null) { + s = new StackTraceElement(); + toStackTraceElement0(s); + ste = s; + } + } + } + return s; Thanks! /Claes > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153123 > > A summary of the changes: > > * remove the "stackwalk.newThrowable" system property and > "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking > > * Streamline StackFrameInfo fields > > * Refactor/streamline StackStreamFactory (no more separate > classes[]/StackFrame[] arrays, remove unneeded (for now) > StackStreamFactory.StackTrace class) > > > Given the hotspot changes, I plan to push this through hs-rt. > > Thanks, > -Brent > From kumar.x.srinivasan at oracle.com Tue Apr 5 18:18:43 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 05 Apr 2016 11:18:43 -0700 Subject: RFR: Message-ID: <57040183.3010300@oracle.com> Hi, The issue here was jimage extract was taking too long, exploding the modules onto certain slow filesystems, thus causing test timeouts. Now using jrtfs to zipfs, it takes a small fraction of that time. Please review: http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ Fix for: https://bugs.openjdk.java.net/browse/JDK-8152622 Thanks Kumar From coleen.phillimore at oracle.com Tue Apr 5 18:25:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 14:25:19 -0400 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5703F5E7.4060404@oracle.com> References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> <5703F5E7.4060404@oracle.com> Message-ID: <5704030F.80906@oracle.com> A correction below. On 4/5/16 1:29 PM, Coleen Phillimore wrote: > > Also meant to include core-libs-dev in the email. > Thanks, > Coleen > > On 4/5/16 1:27 PM, Coleen Phillimore wrote: >> >> Hi, I've reviewed the hotspot changes and some of the jdk changes. >> This looks really good. >> >> One comment about the jvm function names: >> >> I think FillInStackTraceElement is too close of a name to >> Throwable::fill_in_stack_trace(). >> >> -JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame)) >> +JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject >> frame, jobject stack)) >> JVMWrapper("JVM_SetMethodInfo"); >> - Handle stackFrame(THREAD, JNIHandles::resolve(frame)); >> - java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD); >> + Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); >> + Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); >> + java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info, >> stack_trace_element, THREAD); JVM_END >> >> >> And the function is called fill_methodInfo in the javaClasses function. >> >> I think the JVM and the java_lang_StackFrameInfo function names >> should be closer. >> >> I wonder if the name JVM_ToStackFrameElement() and >> java_lang_StackFrameInfo::to_stack_frame_element() would be better >> and then it'd match the Java name. >> I meant JVM_ToStackTraceElement() and java_lang_StackFrameInfo::to_stack_trace_element(), since it's producing a StackTraceElement. thanks, Coleen >> Thanks! >> Coleen >> >> On 4/4/16 9:29 PM, Mandy Chung wrote: >>>> On Apr 4, 2016, at 4:45 PM, Brent Christian >>>> wrote: >>>> >>>> Hi, >>>> >>>> I'd like to check in some footprint and code reduction changes to >>>> the java.lang.StackWalker implementation. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8153123 >>>> >>> This looks good to me. >>> >>> One thing to mention is that this patch is a follow-up work from the >>> investigation on what it takes to enable Throwable to use >>> StackWalker (JDK-8141239). The current built-in VM backtrace is very >>> compact and performant. We have identified and prototypes the >>> performance improvements if Throwable backtrace is generated using >>> stack walker. There are some performance gaps that we agree to >>> defer JDK-8141239 to a future release and improve the footprint >>> performance and GC throughput concerns when MemberNames are stored >>> in the throwable backtrace. >>> >>> Mandy >>> >> > From kumar.x.srinivasan at oracle.com Tue Apr 5 18:25:58 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 05 Apr 2016 11:25:58 -0700 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <57040183.3010300@oracle.com> References: <57040183.3010300@oracle.com> Message-ID: <57040336.9020703@oracle.com> sorry missed the subject. Kumar > Hi, > > The issue here was jimage extract was taking too long, exploding > the modules onto certain slow filesystems, thus causing test > timeouts. Now using jrtfs to zipfs, it takes a small fraction of > that time. > > Please review: > http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ > > Fix for: > https://bugs.openjdk.java.net/browse/JDK-8152622 > > Thanks > Kumar > From mandy.chung at oracle.com Tue Apr 5 23:33:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Apr 2016 16:33:00 -0700 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module In-Reply-To: References: Message-ID: <55EB013A-6F42-424F-BED7-490BF635BB70@oracle.com> > On Apr 5, 2016, at 2:51 AM, Chris Hegarty wrote: > > sun.misc.PostVMInitHook::run is called by the VM once its initialization is > complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. > Since sun.misc will be moved out of the base module, the VM should > look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. > > http://cr.openjdk.java.net/~chegar/8153498/ Looks okay. Minor nit: would it be better to rename the vmSymbol to match the package name: vmSymbols::jdk_internal_vm_PostVMInitHook() Mandy From aleksej.efimov at oracle.com Tue Apr 5 23:47:24 2016 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 6 Apr 2016 02:47:24 +0300 Subject: Bug id : 8140747 - Data corruption when parsing XML using StAX/Xerces In-Reply-To: <1964669852.72080.1459405377521.JavaMail.yahoo@mail.yahoo.com> References: <1964669852.72080.1459405377521.JavaMail.yahoo.ref@mail.yahoo.com> <1964669852.72080.1459405377521.JavaMail.yahoo@mail.yahoo.com> Message-ID: <57044E8C.1000903@oracle.com> Hi Vlad, This bug was fixed in 7u80. Please, see JDK-8059327 [1] for more information. Also I have successfully executed the test from JDK-8140747 on 7u80 and on 7u75 with [1] applied: It gave me a lot of 'rugs' =). Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8059327 On 03/31/2016 09:22 AM, Vlad-Lucian G?nju wrote: > Hello, > Encountered this bug on our server and after some investigations I was able to find the bug reported here https://bugs.openjdk.java.net/browse/JDK-8140747. > It seems that you were not able to reproduce on the Java versions mentioned in the bug's description. > I am able to reproduce it on JDK 7u75 constantly. Installed this Java version on several linux machines and I am able to reproduce it on every one of them using the code provided in bug's description.I hope this info can help you find the problem mentioned in the bug's description. > > [vlg at sec vladtmp]$ for i in $(seq 1 10); do java TestXmlReader; done; > bugs > bugs > bugs > bugs > bugs > bugs > bugs > bugs > bugs > bugs > [vlg at sec vladtmp]$ java -version > java version "1.7.0_75" > Java(TM) SE Runtime Environment (build 1.7.0_75-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) > > > Regards,Vlad-Lucian G?nju From brent.christian at oracle.com Tue Apr 5 23:48:24 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 05 Apr 2016 16:48:24 -0700 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5704030F.80906@oracle.com> References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> <5703F5E7.4060404@oracle.com> <5704030F.80906@oracle.com> Message-ID: <57044EC8.7050602@oracle.com> Thanks, Coleen. Coordinating method/function names on "to stack trace element" is a fine thing. I've done so in the updated webrev, and also implemented Claes's suggestion. http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html -Brent On 04/05/2016 11:25 AM, Coleen Phillimore wrote: > > A correction below. > > On 4/5/16 1:29 PM, Coleen Phillimore wrote: >> >> Also meant to include core-libs-dev in the email. >> Thanks, >> Coleen >> >> On 4/5/16 1:27 PM, Coleen Phillimore wrote: >>> >>> Hi, I've reviewed the hotspot changes and some of the jdk changes. >>> This looks really good. >>> >>> One comment about the jvm function names: >>> >>> I think FillInStackTraceElement is too close of a name to >>> Throwable::fill_in_stack_trace(). >>> >>> -JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame)) >>> +JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject >>> frame, jobject stack)) >>> JVMWrapper("JVM_SetMethodInfo"); >>> - Handle stackFrame(THREAD, JNIHandles::resolve(frame)); >>> - java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD); >>> + Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); >>> + Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); >>> + java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info, >>> stack_trace_element, THREAD); JVM_END >>> >>> >>> And the function is called fill_methodInfo in the javaClasses function. >>> >>> I think the JVM and the java_lang_StackFrameInfo function names >>> should be closer. >>> >>> I wonder if the name JVM_ToStackFrameElement() and >>> java_lang_StackFrameInfo::to_stack_frame_element() would be better >>> and then it'd match the Java name. >>> > > I meant JVM_ToStackTraceElement() and > java_lang_StackFrameInfo::to_stack_trace_element(), since it's producing > a StackTraceElement. > > thanks, > Coleen >>> Thanks! >>> Coleen >>> >>> On 4/4/16 9:29 PM, Mandy Chung wrote: >>>>> On Apr 4, 2016, at 4:45 PM, Brent Christian >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'd like to check in some footprint and code reduction changes to >>>>> the java.lang.StackWalker implementation. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8153123 >>>>> >>>> This looks good to me. >>>> >>>> One thing to mention is that this patch is a follow-up work from the >>>> investigation on what it takes to enable Throwable to use >>>> StackWalker (JDK-8141239). The current built-in VM backtrace is very >>>> compact and performant. We have identified and prototypes the >>>> performance improvements if Throwable backtrace is generated using >>>> stack walker. There are some performance gaps that we agree to >>>> defer JDK-8141239 to a future release and improve the footprint >>>> performance and GC throughput concerns when MemberNames are stored >>>> in the throwable backtrace. >>>> >>>> Mandy >>>> >>> >> > From steve.dohrmann at intel.com Wed Apr 6 01:49:01 2016 From: steve.dohrmann at intel.com (Dohrmann, Steve) Date: Wed, 6 Apr 2016 01:49:01 +0000 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory Message-ID: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> Re: JDK-8153111 Hi, Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. One motivation we saw for doing anything beyond a concrete ByteBuffer class was application code (e.g. Cassandra) that allocates many off-heap ByteBuffers using ByteBuffer#allocateDirect. We reasoned that if the allocation of ByteBuffers could be done using a common memory interface then only the code that provisioned instances of the the memory spaces would have to change in order to switch or mix memory types. We did think of overloading the ByteBuffer#allocateDirect method with memory space info and avoid an allocation interface. We ended up with a separate user called interface scheme because we imagined that extensions of the memory interface would enable new memory functionality that required new methods (e.g. memory transactions for persistence). Without a separate callable interface, the static method space in ByteBuffer might have to change again. For any API In general we saw the need for two things 1) something to represent a memory space from which objects are allocated (a Memory instance) and 2) a broadly usable familiar "anchor" type as the common data object (java.nio.ByteBuffer). The two points for extension with the current proposal are: 1) Constructors on Memory implementation classes -- allow implementors the ability to offer features on the memory space itself (e.g. partitioning, size limits) and 2) future extensions on the Memory interface -- for example PersistentMemory. Regarding a more elaborate scheme for memory space creation -- we did consider a factory scheme for memory object allocation but could not get comfortable with either a) standardized method signatures suitable for various kinds of memory or b) the complexity that something like a general-purpose "spec" format would add, even if we could come up with it. Direct construction does expose more to the user but it seems sufficient and might be the best given what we can say about the future of heterogeneous memory at this point. Regarding the suggested addition of keyed access to ByteBuffers, we are assuming this is only proposed to enable sharing? We thought it might take a while to properly explore the details (i.e. semantics / thread safety / predicable performance) of sharing such that it would work well and maybe even extend well to things like process-shared and cluster-shared ByteBuffers. We elected to propose nothing for JDK 9 beyond what developers can already do with schemes based on e.g. ByteBuffer#duplicate. We were thinking shared buffers could appear later, possibly as an extension of the Memory interface. The keyed access scheme is simple and appealing, however. One question: how is the request method's size parameter to be interpreted? The suggestion of parameterizing the Memory interface bounded by ByteBuffers seems useful as it gives a clean way to support extended ByteBuffers. Not sure if the change of the allocation method name from #allocateByteBuffer to #allocate was incidental or not? Alternates to the "Memory" interface name might be preferred, BufferSupplier is certainly reasonable. We imagined instances that name different memory spaces (e.g. OffHeapRAM) for allocation rather that the role played -- thinking the role is explicit in the allocation method name (allocateByteBuffer). Regarding changing the allocation size parameter to a long, this would be very nice to have. We avoided it in order to match the existing ByteBuffer API. If 64-bit ByteBuffers are planned, sticking with int sizes might have been the wrong call. We are still coming up to speed on VarHandles (JEP 193), atomics for ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827). We hope there is continued interest in this proposal and happy to provide a modified patch. Best regards, Steve Dohrmann From mandy.chung at oracle.com Wed Apr 6 01:56:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Apr 2016 18:56:47 -0700 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <5703CE96.4040001@gmail.com> References: <56B72242.7050102@gmail.com> <56C34B1B.8050001@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.40! 40001@gmail.com> Message-ID: Hi Peter, > On Apr 5, 2016, at 7:41 AM, Peter Levart wrote: > > The bottom line is that we need a mechanism that: > > - triggers reference discovery when native memory limit is approached or reached > - retires native memory reservation at appropriate time slots until succeeding or until all pending references have been processed and Cleanables executed at which time native memory reservation can fail with OOME. > - if possible, doesn't execute cleanup functions by the allocating thread but just waits for system threads to do the job. > - when triggered, does not make native memory allocation a bottleneck. > > I think that what I did in my latest webrevs with ReferenceHandler thread is an improvement in minimizing contended synchronization and interference of allocating thread(s) with Reference enqueue-ing. But interaction of allocating thread(s) with Cleaner background thread could be improved and I have a couple of ideas to explore. This is about timely native memory deallocation. Since direct byte buffer is the only one using jdk.internal.ref.Cleaner, I am inclined to suggest keep jdk.internal.ref.Cleaner as is and replaced it with a better mechanism when it?s available, either panama or better pending reference enqueuing that you and Per discussed. Given the time we have, I think it?s likely post JDK 9 timeframe. Minimizing contention and interference of allocating threads and ReferenceHandler may worth exploring. Mandy From kumar.x.srinivasan at oracle.com Wed Apr 6 03:47:50 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 05 Apr 2016 20:47:50 -0700 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <57040336.9020703@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> Message-ID: <570486E6.2030405@oracle.com> Hi, I made some adjustments, based on private feedback. New Webrev: http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/ Changes * Modified ModuleAttributes test to use the new utility method, this also requires a way to filter/select filename patterns. * Use preVisitDirectory to create directories once, and ignore /packages directories. Thanks Kumar > > sorry missed the subject. > > Kumar >> Hi, >> >> The issue here was jimage extract was taking too long, exploding >> the modules onto certain slow filesystems, thus causing test >> timeouts. Now using jrtfs to zipfs, it takes a small fraction of >> that time. >> >> Please review: >> http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ >> >> Fix for: >> https://bugs.openjdk.java.net/browse/JDK-8152622 >> >> Thanks >> Kumar >> > From sundararajan.athijegannathan at oracle.com Wed Apr 6 04:40:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 6 Apr 2016 10:10:51 +0530 Subject: RFR: In-Reply-To: <57040183.3010300@oracle.com> References: <57040183.3010300@oracle.com> Message-ID: <57049353.2000809@oracle.com> +1 On 4/5/2016 11:48 PM, Kumar Srinivasan wrote: > Hi, > > The issue here was jimage extract was taking too long, exploding > the modules onto certain slow filesystems, thus causing test > timeouts. Now using jrtfs to zipfs, it takes a small fraction of > that time. > > Please review: > http://cr.openjdk.java.net/~ksrini/8152622/webrev.00/ > > Fix for: > https://bugs.openjdk.java.net/browse/JDK-8152622 > > Thanks > Kumar > From alejandro.murillo at oracle.com Wed Apr 6 05:14:00 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Tue, 5 Apr 2016 23:14:00 -0600 Subject: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed Message-ID: <57049B18.5050307@oracle.com> I'd like to push the changeset below to exclude java/nio/Buffer/BasicByte.java It started failing after the hotspot snapshot was pushed to jdk9/dev tonight. https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for that failure. $ hg -R jdk9.dev/jdk tip -pv changeset: 14082:5c98c9ad8ff2 tag: tip user: amurillo date: Tue Apr 05 22:06:15 2016 -0700 files: test/ProblemList.txt description: 8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed Reviewed-by: tbd diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt --- a/test/ProblemList.txt Tue Apr 05 20:02:21 2016 -0700 +++ b/test/ProblemList.txt Tue Apr 05 22:06:15 2016 -0700 @@ -185,6 +185,8 @@ java/nio/charset/coders/BashStreams.java 8149712 generic-all +java/nio/Buffer/BasicByte.java 8153563 generic-all + ############################################################################ # jdk_rmi -- Alejandro From mandy.chung at oracle.com Wed Apr 6 05:36:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Apr 2016 22:36:23 -0700 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <57044EC8.7050602@oracle.com> References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> <5703F5E7.4060404@oracle.com> <5704030F.80906@oracle.com> <57044EC8.7050602@oracle.com> Message-ID: > On Apr 5, 2016, at 4:48 PM, Brent Christian wrote: > > Thanks, Coleen. Coordinating method/function names on "to stack trace element" is a fine thing. I've done so in the updated webrev, and also implemented Claes's suggestion. > > http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html > Looks good. Nit: can you add a space after ?synchronized? in StackFrameInfo.java line 109: 109 synchronized(this) { Mandy From amy.lu at oracle.com Wed Apr 6 05:59:43 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 6 Apr 2016 13:59:43 +0800 Subject: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed In-Reply-To: <57049B18.5050307@oracle.com> References: <57049B18.5050307@oracle.com> Message-ID: <5704A5CF.2090804@oracle.com> java/nio/Buffer/CopyDirectMemory.java run into the same issue, maybe it could be problem listed together in this patch? Thanks, Amy On 4/6/16 1:14 PM, Alejandro Murillo wrote: > > I'd like to push the changeset below to exclude > java/nio/Buffer/BasicByte.java > It started failing after the hotspot snapshot was pushed to jdk9/dev > tonight. > https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for > that failure. > > $ hg -R jdk9.dev/jdk tip -pv > > changeset: 14082:5c98c9ad8ff2 > tag: tip > user: amurillo > date: Tue Apr 05 22:06:15 2016 -0700 > files: test/ProblemList.txt > description: > 8153564: Add java/nio/Buffer/BasicByte.java to exclude list until > JDK-8153563 is fixed > Reviewed-by: tbd > > > diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt > --- a/test/ProblemList.txt Tue Apr 05 20:02:21 2016 -0700 > +++ b/test/ProblemList.txt Tue Apr 05 22:06:15 2016 -0700 > @@ -185,6 +185,8 @@ > > java/nio/charset/coders/BashStreams.java 8149712 generic-all > > +java/nio/Buffer/BasicByte.java 8153563 generic-all > + > ############################################################################ > > > # jdk_rmi > > From alejandro.murillo at oracle.com Wed Apr 6 06:22:29 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Wed, 6 Apr 2016 00:22:29 -0600 Subject: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed In-Reply-To: <5704A5CF.2090804@oracle.com> References: <57049B18.5050307@oracle.com> <5704A5CF.2090804@oracle.com> Message-ID: <5704AB25.903@oracle.com> I didn't see that one failing on my jprt sanity job I went to check the code CopyDirectMemory.java, and it doesn't use jdk.internal.misc.Unsafe (at least directly), so doesn't look like it's the same issue. where did you see the failure ? Alejandro On 4/5/2016 11:59 PM, Amy Lu wrote: > java/nio/Buffer/CopyDirectMemory.java > run into the same issue, maybe it could be problem listed together in > this patch? > > Thanks, > Amy > > On 4/6/16 1:14 PM, Alejandro Murillo wrote: >> >> I'd like to push the changeset below to exclude >> java/nio/Buffer/BasicByte.java >> It started failing after the hotspot snapshot was pushed to jdk9/dev >> tonight. >> https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for >> that failure. >> >> $ hg -R jdk9.dev/jdk tip -pv >> >> changeset: 14082:5c98c9ad8ff2 >> tag: tip >> user: amurillo >> date: Tue Apr 05 22:06:15 2016 -0700 >> files: test/ProblemList.txt >> description: >> 8153564: Add java/nio/Buffer/BasicByte.java to exclude list until >> JDK-8153563 is fixed >> Reviewed-by: tbd >> >> >> diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt >> --- a/test/ProblemList.txt Tue Apr 05 20:02:21 2016 -0700 >> +++ b/test/ProblemList.txt Tue Apr 05 22:06:15 2016 -0700 >> @@ -185,6 +185,8 @@ >> >> java/nio/charset/coders/BashStreams.java 8149712 generic-all >> >> +java/nio/Buffer/BasicByte.java 8153563 generic-all >> + >> ############################################################################ >> >> >> # jdk_rmi >> >> > -- Alejandro From ecki at zusammenkunft.net Wed Apr 6 06:37:09 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 6 Apr 2016 08:37:09 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> Message-ID: <5704ae9a.d4b61c0a.b7e1a.5525@mx.google.com> Hello Steve, Thank you for addressing all concerns raised in the discussion. For my points: Using BufferSupplier or similar as the interface name can be mixed with class/constructor names which describe the actual type of memory. However yes I agree that ?Memory? has the additional benefit that it can be used directly as a postfix in the class name, so thinking more about it, I agree with the nice and concrete ?Memory? name. I shortened the method to ?allocate()?, but you are right it might be better to make it a bit more specific if extensions are to be expected. My main motivation behind a long key was, that in most scenarios which come to my mind (NVRAM, Flash, mmaped, shmem) the position of the allocated segment is relevant for cross VM (concurrent or sequential, as in the persisted case) sharing. As a ByteBuffer is not only a window into those memory segments but also a active datastructure (pos) it would be ugly to request only a single buffer to cover a large region. Especially with a 32bit size limit. But yes it might also be possible to setup the position/sharing details with the Memory constructor request a large ByteBuffer and then split the actual buffers mapped on top of it (and do the allocation management based on start positions by hand) The meaning of size in combination with the allocation key would be provider dependent. One option would be to refuse overlapping allocations but a more common implementation would simply allocate the segments (and if two VMs use overlapping regions they will exactly receive them). In all cases it should describe the capacity of the buffer. Greetings bernd -- http://bernd.eckenfels.net Von: Dohrmann, Steve Gesendet: Mittwoch, 6. April 2016 03:59 An: core-libs-dev at openjdk.java.net Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory Re: JDK-8153111 Hi, Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. One motivation we saw for doing anything beyond a concrete ByteBuffer class was application code (e.g. Cassandra) that allocates many off-heap ByteBuffers using ByteBuffer#allocateDirect. We reasoned that if the allocation of ByteBuffers could be done using a common memory interface then only the code that provisioned instances of the the memory spaces would have to change in order to switch or mix memory types. We did think of overloading the ByteBuffer#allocateDirect method with memory space info and avoid an allocation interface. We ended up with a separate user called interface scheme because we imagined that extensions of the memory interface would enable new memory functionality that required new methods (e.g. memory transactions for persistence). Without a separate callable interface, the static method space in ByteBuffer might have to change again. For any API In general we saw the need for two things 1) something to represent a memory space from which objects are allocated (a Memory instance) and 2) a broadly usable familiar "anchor" type as the common data object (java.nio.ByteBuffer). The two points for extension with the current proposal are: 1) Constructors on Memory implementation classes -- allow implementors the ability to offer features on the memory space itself (e.g. partitioning, size limits) and 2) future extensions on the Memory interface -- for example PersistentMemory. Regarding a more elaborate scheme for memory space creation -- we did consider a factory scheme for memory object allocation but could not get comfortable with either a) standardized method signatures suitable for various kinds of memory or b) the complexity that something like a general-purpose "spec" format would add, even if we could come up with it. Direct construction does expose more to the user but it seems sufficient and might be the best given what we can say about the future of heterogeneous memory at this point. Regarding the suggested addition of keyed access to ByteBuffers, we are assuming this is only proposed to enable sharing? We thought it might take a while to properly explore the details (i.e. semantics / thread safety / predicable performance) of sharing such that it would work well and maybe even extend well to things like process-shared and cluster-shared ByteBuffers. We elected to propose nothing for JDK 9 beyond what developers can already do with schemes based on e.g. ByteBuffer#duplicate. We were thinking shared buffers could appear later, possibly as an extension of the Memory interface. The keyed access scheme is simple and appealing, however. One question: how is the request method's size parameter to be interpreted? The suggestion of parameterizing the Memory interface bounded by ByteBuffers seems useful as it gives a clean way to support extended ByteBuffers. Not sure if the change of the allocation method name from #allocateByteBuffer to #allocate was incidental or not? Alternates to the "Memory" interface name might be preferred, BufferSupplier is certainly reasonable. We imagined instances that name different memory spaces (e.g. OffHeapRAM) for allocation rather that the role played -- thinking the role is explicit in the allocation method name (allocateByteBuffer). Regarding changing the allocation size parameter to a long, this would be very nice to have. We avoided it in order to match the existing ByteBuffer API. If 64-bit ByteBuffers are planned, sticking with int sizes might have been the wrong call. We are still coming up to speed on VarHandles (JEP 193), atomics for ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827). We hope there is continued interest in this proposal and happy to provide a modified patch. Best regards, Steve Dohrmann From peter.levart at gmail.com Wed Apr 6 06:43:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 6 Apr 2016 08:43:43 +0200 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <5703CE96.4040001@gmail.com> References: <56B72242.7050102@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> Message-ID: <5704B01F.4070406@gmail.com> Hi Roger, On 04/05/2016 04:41 PM, Peter Levart wrote: >> On 04/04/2016 11:50 PM, Roger Riggs wrote: >> I don't see the need to change Cleaner to an interface to be able to >> provide >> an additional method on CleanerImpl or a subclass and a factory >> method could >> provide for a clean and very targeted interface to Bits/Direct buffer. > > I would like this to be an instance method so it would naturally > pertain to a particular Cleaner instance. Or it could be a static > method that takes a Cleaner instance. One of my previous webrevs did > have such method on the CleanerImpl, but I was advised to move it to > Cleaner as a package-private method and expose it via SharedSecrets to > internal code. I feel such "camouflage" is very awkward now that we > have modules and other mechanisms exist. So I thought it would be most > elegant to make Cleaner an interface so it can be extended with an > internal interface to communicate intent in a type-safe and > auto-discoverable way. The change to make it interface: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ > > ...actually simplifies implementation (33 lines removed in total) and > could be seen as an improvement in itself. > > Are you afraid that if Cleaner was an interface, others would attempt > to make implementations of it? Now that we have default methods on > interfaces it is easy to compatibly extend the API even if it is an > interface so that no 3rd party implementations are immediately broken. > Are you thinking of security implications when some code is handed a > Cleaner instance that it doesn't trust? I don't think there is a > utility for Cleaner instances to be passed from untrusted to trusted > code, do you? ...even if we don't do anything for DirectByteBuffer(s) in java.lang.ref.Cleaner and leave things as they stand (using jdk.internal.ref.Cleaner), I would still make this transition to interface to enable possible future internal extensions to java.lang.ref.Cleaner. As I said, this is a source compatible change, but not binary compatible, so if we do it, it must be performed before JDK 9 ships. Regards, Peter From Alan.Bateman at oracle.com Wed Apr 6 07:36:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 08:36:54 +0100 Subject: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed In-Reply-To: <57049B18.5050307@oracle.com> References: <57049B18.5050307@oracle.com> Message-ID: <5704BC96.1060303@oracle.com> On 06/04/2016 06:14, Alejandro Murillo wrote: > > I'd like to push the changeset below to exclude > java/nio/Buffer/BasicByte.java > It started failing after the hotspot snapshot was pushed to jdk9/dev > tonight. > https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for > that failure. Would it be possible to add @modules java.base/jdk.internal.misc, as below, and not exclude these tests? -Alan $ hg diff -g . diff --git a/test/java/nio/Buffer/Basic.java b/test/java/nio/Buffer/Basic.java --- a/test/java/nio/Buffer/Basic.java +++ b/test/java/nio/Buffer/Basic.java @@ -22,6 +22,7 @@ */ /* @test + * @modules java.base/jdk.internal.misc * @summary Unit test for buffers * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 4490253 4523725 * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529 diff --git a/test/java/nio/Buffer/CopyDirectMemory.java b/test/java/nio/Buffer/CopyDirectMemory.java --- a/test/java/nio/Buffer/CopyDirectMemory.java +++ b/test/java/nio/Buffer/CopyDirectMemory.java @@ -25,6 +25,7 @@ * @summary Test view buffer bulk operations for large buffers. * @bug 4463011 * + * @modules java.base/jdk.internal.misc * @build Basic * @run main CopyDirectMemory */ From paul.sandoz at oracle.com Wed Apr 6 07:37:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 09:37:00 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <5703D682.1080300@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <5703D682.1080300@oracle.com> Message-ID: <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> > On 5 Apr 2016, at 17:15, Claes Redestad wrote: > > On 04/04/2016 05:45 PM, Martin Buchholz wrote: >>> I think this one is going too far. >>> >>> A*FU/VarHandles should are supposed to act like a go-to replacement for >>> Unsafe throughout the class library, and we want to shrink the Unsafe >>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins >>> us anything: there should be no throughput hit, and we *will* load A*FU >>> down the road anyway, negating the startup wins. +1 i would leave this one as is. In general same goes for the @Stable/ForceInline annotations etc. We should use this stuff carefully within java.base and also sparingly to qualifying JDK modules. >>> >>> -Aleksey >> It is surprising to see new uses of Unsafe when we have an ongoing >> initiative within openjdk (especially from Paul Sandoz) to remove most >> uses. Varhandles are coming and are expected to replace uses of >> Unsafe in the JDK. > > This is just a very minor win on hello world/-version style tests, so I'm happy to withdraw this if other early usages, such as CHM, is moving to VarHandles anyhow. > > OTOH using dangerous, internal APIs like this rather than nice, public APIs early in the VM bootstrap has other merits, such as not unintentionally causing bootstrap issues. Say, I don't know if VarHandles have any dependencies on java.lang.invoke currently? It does, but was designed to be minimize bootstrap issues and class spinning so there are less dependencies than MHs. CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. There is probably a way of switching from a less concurrent concurrent map to CHM at ?safe-point? when the VM transitions to booted. To be investigated... Paul. From amy.lu at oracle.com Wed Apr 6 07:47:58 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 6 Apr 2016 15:47:58 +0800 Subject: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469 Message-ID: <5704BF2E.7080500@oracle.com> With test/java/nio/Buffer/BasicByte.java change in JDK-8149469, test java/nio/Buffer/Basic.java java/nio/Buffer/CopyDirectMemory.java now requires @modules java.base/jdk.internal.misc Please review the patch. bug: https://bugs.openjdk.java.net/browse/JDK-8153563 webrev: http://cr.openjdk.java.net/~amlu/8153563/webrev.00/ Thanks, Amy --- old/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.000000000 +0800 +++ new/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529 * 6221101 6234263 6535542 6591971 6593946 6795561 7190219 7199551 8065556 * 8149469 + * @modules java.base/jdk.internal.misc * @author Mark Reinhold */ --- old/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:39:20.000000000 +0800 +++ new/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:39:20.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -26,6 +26,7 @@ * @bug 4463011 * * @build Basic + * @modules java.base/jdk.internal.misc * @run main CopyDirectMemory */ From Alan.Bateman at oracle.com Wed Apr 6 07:52:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 08:52:03 +0100 Subject: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469 In-Reply-To: <5704BF2E.7080500@oracle.com> References: <5704BF2E.7080500@oracle.com> Message-ID: <5704C023.7050704@oracle.com> On 06/04/2016 08:47, Amy Lu wrote: > : > * > * @build Basic > + * @modules java.base/jdk.internal.misc > * @run main CopyDirectMemory > */ > It might be clearer to put it before the @build, otherwise looks okay. -Alan From amy.lu at oracle.com Wed Apr 6 07:59:59 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 6 Apr 2016 15:59:59 +0800 Subject: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469 In-Reply-To: <5704C023.7050704@oracle.com> References: <5704BF2E.7080500@oracle.com> <5704C023.7050704@oracle.com> Message-ID: <5704C1FF.4020404@oracle.com> On 4/6/16 3:52 PM, Alan Bateman wrote: > > On 06/04/2016 08:47, Amy Lu wrote: >> : >> * >> * @build Basic >> + * @modules java.base/jdk.internal.misc >> * @run main CopyDirectMemory >> */ >> > It might be clearer to put it before the @build, otherwise looks okay. Yes :-) Please review the updated patch: http://cr.openjdk.java.net/~amlu/8153563/webrev.01/ Thanks, Amy --- old/test/java/nio/Buffer/Basic.java 2016-04-06 15:57:56.000000000 +0800 +++ new/test/java/nio/Buffer/Basic.java 2016-04-06 15:57:56.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529 * 6221101 6234263 6535542 6591971 6593946 6795561 7190219 7199551 8065556 * 8149469 + * @modules java.base/jdk.internal.misc * @author Mark Reinhold */ --- old/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:57:57.000000000 +0800 +++ new/test/java/nio/Buffer/CopyDirectMemory.java 2016-04-06 15:57:57.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -25,6 +25,7 @@ * @summary Test view buffer bulk operations for large buffers. * @bug 4463011 * + * @modules java.base/jdk.internal.misc * @build Basic * @run main CopyDirectMemory */ From Alan.Bateman at oracle.com Wed Apr 6 08:32:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 09:32:22 +0100 Subject: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469 In-Reply-To: <5704C1FF.4020404@oracle.com> References: <5704BF2E.7080500@oracle.com> <5704C023.7050704@oracle.com> <5704C1FF.4020404@oracle.com> Message-ID: <5704C996.70104@oracle.com> On 06/04/2016 08:59, Amy Lu wrote: > Yes :-) > > Please review the updated patch: > http://cr.openjdk.java.net/~amlu/8153563/webrev.01/ > > Thanks, > Amy Looks fine. From Alan.Bateman at oracle.com Wed Apr 6 08:39:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 09:39:22 +0100 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <570486E6.2030405@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> <570486E6.2030405@oracle.com> Message-ID: <5704CB3A.8080004@oracle.com> On 06/04/2016 04:47, Kumar Srinivasan wrote: > Hi, > > I made some adjustments, based on private feedback. > > New Webrev: > http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/ > > Changes > * Modified ModuleAttributes test to use the new utility method, > this also requires a way to filter/select filename patterns. > > * Use preVisitDirectory to create directories once, and ignore > /packages directories. > Creating a zip file from the classes in the jrt file system make sense, and should be fast. A few comments on Utils.JrtToZip: - the URI creation in the run() method isn't reliable, could you use this instead: URI uri = URI.create("jar:" + outFile.toURI()); - In the toZipFs method then I assume you should use URI.create("jrt:/"), best to stay away from URL. - Is Files.createDirectories needed? The walk is specified to be depth first so you'll also visit parent directories first. - I'm also curious about the REPLACE_EXISTING as I assume that isn't needed. A minor comment is that "root" rather than "p" would be nicer for the root directory. Personally I would avoid the really long lines as it makes future side-by-side reviews harder. Also throws Exception seems too broad but it's test code so not a big deal. -Alan. From michael.haupt at oracle.com Wed Apr 6 09:37:51 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Apr 2016 11:37:51 +0200 Subject: RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment In-Reply-To: <56F12F4C.70201@oracle.com> References: <56F12F4C.70201@oracle.com> Message-ID: <77CBB328-8BBE-4884-9EF4-F91163F84215@oracle.com> Hi Shilpi, note this is not a *R*eview, but thumbs up, and I'll be happy to sponsor the push once a *R*eviewer agrees. Best, Michael > Am 22.03.2016 um 12:41 schrieb shilpi.rastogi at oracle.com: > > Hi All, > > Please review the following- > > https://bugs.openjdk.java.net/browse/JDK-8150829 > http://cr.openjdk.java.net/~srastogi/8150829/webrev.04 > > > Thanks, > Shilpi -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From forax at univ-mlv.fr Wed Apr 6 10:10:03 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Apr 2016 12:10:03 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> Message-ID: <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoy?: Mercredi 6 Avril 2016 09:37:00 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe > > > > On 5 Apr 2016, at 17:15, Claes Redestad wrote: > > > > On 04/04/2016 05:45 PM, Martin Buchholz wrote: > >>> I think this one is going too far. > >>> > >>> A*FU/VarHandles should are supposed to act like a go-to replacement for > >>> Unsafe throughout the class library, and we want to shrink the Unsafe > >>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins > >>> us anything: there should be no throughput hit, and we *will* load A*FU > >>> down the road anyway, negating the startup wins. > > +1 i would leave this one as is. > > In general same goes for the @Stable/ForceInline annotations etc. We should > use this stuff carefully within java.base and also sparingly to qualifying > JDK modules. While i fully agree in the general case, in disagree for this specific case, there are few uses of ARFU inside the JDK (or outside) but currently because BufferedInputStream uses an ARFU, each time someone starts a Java application, the VM loads ARFU and its implementation with a high probability to no need it at all after ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage of Unsafe for a good reason goes in the right direction here, when VarHandle will replace usages of Unsafe, the code of BufferedInputStream will be refactored again. > > >>> > >>> -Aleksey > >> It is surprising to see new uses of Unsafe when we have an ongoing > >> initiative within openjdk (especially from Paul Sandoz) to remove most > >> uses. Varhandles are coming and are expected to replace uses of > >> Unsafe in the JDK. > > > > This is just a very minor win on hello world/-version style tests, so I'm > > happy to withdraw this if other early usages, such as CHM, is moving to > > VarHandles anyhow. > > > > OTOH using dangerous, internal APIs like this rather than nice, public APIs > > early in the VM bootstrap has other merits, such as not unintentionally > > causing bootstrap issues. Say, I don't know if VarHandles have any > > dependencies on java.lang.invoke currently? > > It does, but was designed to be minimize bootstrap issues and class spinning > so there are less dependencies than MHs. > > CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. > There is probably a way of switching from a less concurrent concurrent map > to CHM at ?safe-point? when the VM transitions to booted. To be > investigated... another solution is perhaps to not use a concurrent hashmap in MethodType, method types need to be interned only the first time a method handle is invoked with an invokeExact/invoke (but not by invokedynamic) so instead of interning all method types which artificially put pressure on the interning map to be lock free, interning only the method type when need it may allow to not use a CHM in MethodType. > > Paul. > R?mi From paul.sandoz at oracle.com Wed Apr 6 10:37:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 12:37:50 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> Message-ID: > On 6 Apr 2016, at 12:10, Remi Forax wrote: > > ----- Mail original ----- >> De: "Paul Sandoz" >> Cc: "core-libs-dev Libs" >> Envoy?: Mercredi 6 Avril 2016 09:37:00 >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe >> >> >>> On 5 Apr 2016, at 17:15, Claes Redestad wrote: >>> >>> On 04/04/2016 05:45 PM, Martin Buchholz wrote: >>>>> I think this one is going too far. >>>>> >>>>> A*FU/VarHandles should are supposed to act like a go-to replacement for >>>>> Unsafe throughout the class library, and we want to shrink the Unsafe >>>>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins >>>>> us anything: there should be no throughput hit, and we *will* load A*FU >>>>> down the road anyway, negating the startup wins. >> >> +1 i would leave this one as is. >> >> In general same goes for the @Stable/ForceInline annotations etc. We should >> use this stuff carefully within java.base and also sparingly to qualifying >> JDK modules. > > While i fully agree in the general case, in disagree for this specific case, > there are few uses of ARFU inside the JDK (or outside) but currently because BufferedInputStream uses an ARFU, each time someone starts a Java application, the VM loads ARFU and its implementation with a high probability to no need it at all after > Does that really contribute sufficiently to slow down in start time? It really seems like a micro-optimisation. > ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage of Unsafe for a good reason goes in the right direction here, > when VarHandle will replace usages of Unsafe, the code of BufferedInputStream will be refactored again. > My preference is not to change it if it?s gonna change later on. >> >>>>> >>>>> -Aleksey >>>> It is surprising to see new uses of Unsafe when we have an ongoing >>>> initiative within openjdk (especially from Paul Sandoz) to remove most >>>> uses. Varhandles are coming and are expected to replace uses of >>>> Unsafe in the JDK. >>> >>> This is just a very minor win on hello world/-version style tests, so I'm >>> happy to withdraw this if other early usages, such as CHM, is moving to >>> VarHandles anyhow. >>> >>> OTOH using dangerous, internal APIs like this rather than nice, public APIs >>> early in the VM bootstrap has other merits, such as not unintentionally >>> causing bootstrap issues. Say, I don't know if VarHandles have any >>> dependencies on java.lang.invoke currently? >> >> It does, but was designed to be minimize bootstrap issues and class spinning >> so there are less dependencies than MHs. >> >> CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. >> There is probably a way of switching from a less concurrent concurrent map >> to CHM at ?safe-point? when the VM transitions to booted. To be >> investigated... > > another solution is perhaps to not use a concurrent hashmap in MethodType, method types need to be interned only the first time a method handle is invoked with an invokeExact/invoke (but not by invokedynamic) so instead of interning all method types which artificially put pressure on the interning map to be lock free, interning only the method type when need it may allow to not use a CHM in MethodType. > I need to re-familiarise myself with the code to see what is possible here. MethodType also comes with a shared erased form which also caches LambdaForms for various kinds. It?s not clear to me if this can be easily be teased apart. Paul. From paul.sandoz at oracle.com Wed Apr 6 11:10:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 13:10:38 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> Message-ID: Hi Steve, My feeling is it?s too premature to introduce a general Memory (region) allocation interface at this moment. What is currently specified can be supported using: IntFunction But i don?t wanna discourage you! this thread has raised some interesting points. Project Panama is gonna take a swing at defining a more general notion of a memory region and the Arrays 2.0 work should support indexes greater than Integer.MAX_VALUE. In this respect I think we should hold off doing anything premature for Java 9 (feature freeze is getting closer), and i encourage you to participate on the Panama lists. ? Here is some context some of which you probably know and some which you might not: - ByteBuffer constructors are deliberately package scoped, as there are some intricate dependencies between the implementations and we want control over who can implement. Any new form of allocation will require changes here (package scoped or otherwise). - current ByteBuffer implementations are either backed by a byte[] (managed or non-direct) or an off-heap allocated (direct) region. At the moment access to both those regions go through separate code paths, but they could be unified using the Unsafe double addressing mode, which should greatly simplify the implementations. I have started making some small steps towards that (JDK-8149469 and JDK-8151163). Even these small steps require careful analysis to evaluate performance across multiple platforms. - VarHandles leverages the Unsafe double addressing mode to support enhanced atomic access to heap or direct ByteBuffers [1], thus the same code is used in both kinds of buffer. ? I am not sure what plans you have for buffer implementations themselves. How do you propose to allocate a ByteBuffer instance that covers a region of 3D XPoint memory? Would it be similar to that of direct buffers, e.g. a variation of DirectByteBuffer, but with different factory constructor code to allocate the memory region within the XPoint memory system and assign the buffer base address to the start of that allocated region? Thanks, Paul. [1] http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class, boolean) > On 6 Apr 2016, at 03:49, Dohrmann, Steve wrote: > > Re: JDK-8153111 > > > Hi, > > Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. > > One motivation we saw for doing anything beyond a concrete ByteBuffer class was application code (e.g. Cassandra) that allocates many off-heap ByteBuffers using ByteBuffer#allocateDirect. We reasoned that if the allocation of ByteBuffers could be done using a common memory interface then only the code that provisioned instances of the the memory spaces would have to change in order to switch or mix memory types. > > We did think of overloading the ByteBuffer#allocateDirect method with memory space info and avoid an allocation interface. We ended up with a separate user called interface scheme because we imagined that extensions of the memory interface would enable new memory functionality that required new methods (e.g. memory transactions for persistence). Without a separate callable interface, the static method space in ByteBuffer might have to change again. > > For any API In general we saw the need for two things 1) something to represent a memory space from which objects are allocated (a Memory instance) and 2) a broadly usable familiar "anchor" type as the common data object (java.nio.ByteBuffer). > > The two points for extension with the current proposal are: 1) Constructors on Memory implementation classes -- allow implementors the ability to offer features on the memory space itself (e.g. partitioning, size limits) and 2) future extensions on the Memory interface -- for example PersistentMemory. > > Regarding a more elaborate scheme for memory space creation -- we did consider a factory scheme for memory object allocation but could not get comfortable with either a) standardized method signatures suitable for various kinds of memory or b) the complexity that something like a general-purpose "spec" format would add, even if we could come up with it. Direct construction does expose more to the user but it seems sufficient and might be the best given what we can say about the future of heterogeneous memory at this point. > > Regarding the suggested addition of keyed access to ByteBuffers, we are assuming this is only proposed to enable sharing? We thought it might take a while to properly explore the details (i.e. semantics / thread safety / predicable performance) of sharing such that it would work well and maybe even extend well to things like process-shared and cluster-shared ByteBuffers. We elected to propose nothing for JDK 9 beyond what developers can already do with schemes based on e.g. ByteBuffer#duplicate. We were thinking shared buffers could appear later, possibly as an extension of the Memory interface. The keyed access scheme is simple and appealing, however. One question: how is the request method's size parameter to be interpreted? > > The suggestion of parameterizing the Memory interface bounded by ByteBuffers seems useful as it gives a clean way to support extended ByteBuffers. Not sure if the change of the allocation method name from #allocateByteBuffer to #allocate was incidental or not? > > Alternates to the "Memory" interface name might be preferred, BufferSupplier is certainly reasonable. We imagined instances that name different memory spaces (e.g. OffHeapRAM) for allocation rather that the role played -- thinking the role is explicit in the allocation method name (allocateByteBuffer). > > Regarding changing the allocation size parameter to a long, this would be very nice to have. We avoided it in order to match the existing ByteBuffer API. If 64-bit ByteBuffers are planned, sticking with int sizes might have been the wrong call. > > We are still coming up to speed on VarHandles (JEP 193), atomics for ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827). > > We hope there is continued interest in this proposal and happy to provide a modified patch. > > Best regards, > Steve Dohrmann > From forax at univ-mlv.fr Wed Apr 6 11:40:58 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Apr 2016 13:40:58 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> Message-ID: <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoy?: Mercredi 6 Avril 2016 12:37:50 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe > > > > On 6 Apr 2016, at 12:10, Remi Forax wrote: > > > > ----- Mail original ----- > >> De: "Paul Sandoz" > >> Cc: "core-libs-dev Libs" > >> Envoy?: Mercredi 6 Avril 2016 09:37:00 > >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > >> AtomicReferenceFieldUpdater with Unsafe > >> > >> > >>> On 5 Apr 2016, at 17:15, Claes Redestad > >>> wrote: > >>> > >>> On 04/04/2016 05:45 PM, Martin Buchholz wrote: > >>>>> I think this one is going too far. > >>>>> > >>>>> A*FU/VarHandles should are supposed to act like a go-to replacement for > >>>>> Unsafe throughout the class library, and we want to shrink the Unsafe > >>>>> exposure. Also, I don't think removing A*FU in favor of Unsafe here > >>>>> wins > >>>>> us anything: there should be no throughput hit, and we *will* load A*FU > >>>>> down the road anyway, negating the startup wins. > >> > >> +1 i would leave this one as is. > >> > >> In general same goes for the @Stable/ForceInline annotations etc. We > >> should > >> use this stuff carefully within java.base and also sparingly to qualifying > >> JDK modules. > > > > While i fully agree in the general case, in disagree for this specific > > case, > > there are few uses of ARFU inside the JDK (or outside) but currently > > because BufferedInputStream uses an ARFU, each time someone starts a Java > > application, the VM loads ARFU and its implementation with a high > > probability to no need it at all after > > > > Does that really contribute sufficiently to slow down in start time? It > really seems like a micro-optimisation. small streams become big rivers (i don't know the idiomatic sentence in English, so it's a rough translation from a French idiom), currently the main problem is that the loading of modules adds so much overhead to the startup time that you see nothing :( Also, startup time is one aspect, size of the VM data structures at runtime, size of the CDS archive* are also impacted. > > > > ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage > > of Unsafe for a good reason goes in the right direction here, > > when VarHandle will replace usages of Unsafe, the code of > > BufferedInputStream will be refactored again. > > > > My preference is not to change it if it?s gonna change later on. but there is also a good chance to miss that change later because you will look for usages of Unsafe and not usages of ARFU. Replacing ARFU by Unsafe in BufferedInputStream makes the code more similar to the other usages of Unsafe in the JDK. [...] > > Paul. > R?mi * removing classes from a CDS archive is important for 32 bits windows VM R?mi From paul.sandoz at oracle.com Wed Apr 6 12:54:54 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 14:54:54 +0200 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: References: Message-ID: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> Hi Martin, miscellaneous ? You reverted Aleksey?s change s/putOrderedObject/putObjectRelease. The *Ordered* methods are now removed from the ?real? jdk.internal.misc.Unsafe. Paul. > On 3 Apr 2016, at 20:29, Martin Buchholz wrote: > > Easy changes to review, up to April Fools day, in part to make room > for later unfinished more exciting changes. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ From vitalyd at gmail.com Wed Apr 6 13:04:39 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 6 Apr 2016 09:04:39 -0400 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> References: <57006917.4090200@oracle.com> <614728155.1438453.1459684620433.JavaMail.zimbra@u-pem.fr> <57010A68.9050307@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> Message-ID: On Wednesday, April 6, 2016, Remi Forax wrote: > ----- Mail original ----- > > De: "Paul Sandoz" > > > Cc: "core-libs-dev Libs" > > > Envoy?: Mercredi 6 Avril 2016 12:37:50 > > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > > > > On 6 Apr 2016, at 12:10, Remi Forax > > wrote: > > > > > > ----- Mail original ----- > > >> De: "Paul Sandoz" > > > >> Cc: "core-libs-dev Libs" > > > >> Envoy?: Mercredi 6 Avril 2016 09:37:00 > > >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > > >> AtomicReferenceFieldUpdater with Unsafe > > >> > > >> > > >>> On 5 Apr 2016, at 17:15, Claes Redestad > > > >>> wrote: > > >>> > > >>> On 04/04/2016 05:45 PM, Martin Buchholz wrote: > > >>>>> I think this one is going too far. > > >>>>> > > >>>>> A*FU/VarHandles should are supposed to act like a go-to > replacement for > > >>>>> Unsafe throughout the class library, and we want to shrink the > Unsafe > > >>>>> exposure. Also, I don't think removing A*FU in favor of Unsafe here > > >>>>> wins > > >>>>> us anything: there should be no throughput hit, and we *will* load > A*FU > > >>>>> down the road anyway, negating the startup wins. > > >> > > >> +1 i would leave this one as is. > > >> > > >> In general same goes for the @Stable/ForceInline annotations etc. We > > >> should > > >> use this stuff carefully within java.base and also sparingly to > qualifying > > >> JDK modules. > > > > > > While i fully agree in the general case, in disagree for this specific > > > case, > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > because BufferedInputStream uses an ARFU, each time someone starts a > Java > > > application, the VM loads ARFU and its implementation with a high > > > probability to no need it at all after > > > > > > > Does that really contribute sufficiently to slow down in start time? It > > really seems like a micro-optimisation. > > small streams become big rivers (i don't know the idiomatic sentence in > English, so it's a rough translation from a French idiom), "Death by a thousand cuts" is one of my favorites :). A "flat profile" is another description of a similar thing. In general, I agree that easy/cheap/maintainable/etc wins should be done even if individually they don't matter much (if that were the requirement, there would be no progress whatsoever). In this case, using Unsafe for now seems trivial; when VH is ready, someone is going to sweep the code anyway and this will be just one more place to mechanically update. Is VH definitely going to be part of Java 9? If so, then perhaps no point in making this change unless it's going to be backported to Java 8. currently the main problem is that the loading of modules adds so much > overhead to the startup time that you see nothing :( > > Also, startup time is one aspect, size of the VM data structures at > runtime, size of the CDS archive* are also impacted. > > > > > > > > ARFU are not a replacement of Unsafe, VarHandles are. So adding a new > usage > > > of Unsafe for a good reason goes in the right direction here, > > > when VarHandle will replace usages of Unsafe, the code of > > > BufferedInputStream will be refactored again. > > > > > > > My preference is not to change it if it?s gonna change later on. > > but there is also a good chance to miss that change later because you will > look for usages of Unsafe and not usages of ARFU. > Replacing ARFU by Unsafe in BufferedInputStream makes the code more > similar to the other usages of Unsafe in the JDK. > > [...] > > > > > Paul. > > > > R?mi > > * removing classes from a CDS archive is important for 32 bits windows VM > > R?mi > -- Sent from my phone From kumar.x.srinivasan at oracle.com Wed Apr 6 13:09:41 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 06 Apr 2016 06:09:41 -0700 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <5704CB3A.8080004@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> <570486E6.2030405@oracle.com> <5704CB3A.8080004@oracle.com> Message-ID: <57050A95.4040801@oracle.com> Alan, Thanks for the review. Please see inline comments. >> > Creating a zip file from the classes in the jrt file system make > sense, and should be fast. > > A few comments on Utils.JrtToZip: > > - the URI creation in the run() method isn't reliable, could you use > this instead: > URI uri = URI.create("jar:" + outFile.toURI()); Ok > > - In the toZipFs method then I assume you should use > URI.create("jrt:/"), best to stay away from URL. Ok > > - Is Files.createDirectories needed? The walk is specified to be depth > first so you'll also visit parent directories first. Yes, zipfs does not allow me to create the file without creating the enclosing directory first, so if I were to do this in visitFile, then presumably I would have to add a check, to prevent duplicate creation going into the provider, only to find a directory already exists and return, not sure if this is what you want, because preVisitDirectory does this conveniently. > > - I'm also curious about the REPLACE_EXISTING as I assume that isn't > needed. Oh! while I was developing in NB as a discrete/stand alone project, I was reusing the same zip/jar output file, will leave it as-is, no harm, right ?. > > A minor comment is that "root" rather than "p" would be nicer for the > root directory. Personally I would avoid the really long lines as it > makes future side-by-side reviews harder. Also throws Exception seems > too broad but it's test code so not a big deal. Ok Thanks Kumar > > -Alan. From Alan.Bateman at oracle.com Wed Apr 6 13:21:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 14:21:18 +0100 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <57050A95.4040801@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> <570486E6.2030405@oracle.com> <5704CB3A.8080004@oracle.com> <57050A95.4040801@oracle.com> Message-ID: <57050D4E.30807@oracle.com> On 06/04/2016 14:09, Kumar Srinivasan wrote: > >> >> - Is Files.createDirectories needed? The walk is specified to be >> depth first so you'll also visit parent directories first. > > Yes, zipfs does not allow me to create the file without creating the > enclosing directory > first, so if I were to do this in visitFile, then presumably I would > have to add a > check, to prevent duplicate creation going into the provider, only to > find a > directory already exists and return, not sure if this is what you > want, because > preVisitDirectory does this conveniently. I should have been clearer, I was trying to say that createDirectory should be sufficient here because the walk is specified to be depth first. > >> >> - I'm also curious about the REPLACE_EXISTING as I assume that isn't >> needed. > > Oh! while I was developing in NB as a discrete/stand alone project, I > was reusing the > same zip/jar output file, will leave it as-is, no harm, right ?. No harm, it just caught my eye as not needed. -Alan From forax at univ-mlv.fr Wed Apr 6 13:28:47 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 6 Apr 2016 15:28:47 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> Message-ID: <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Vitaly Davidovich" > ?: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev Libs" > > Envoy?: Mercredi 6 Avril 2016 15:04:39 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > On Wednesday, April 6, 2016, Remi Forax < forax at univ-mlv.fr > wrote: > > ----- Mail original ----- > > > > De: "Paul Sandoz" < paul.sandoz at oracle.com > > > > > Cc: "core-libs-dev Libs" < core-libs-dev at openjdk.java.net > > > > > Envoy?: Mercredi 6 Avril 2016 12:37:50 > > > > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > > > AtomicReferenceFieldUpdater with Unsafe > > > > > > > > > > > > > On 6 Apr 2016, at 12:10, Remi Forax < forax at univ-mlv.fr > wrote: > [...] > > > > While i fully agree in the general case, in disagree for this specific > > > > > case, > > > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > > > because BufferedInputStream uses an ARFU, each time someone starts a > > > > Java > > > > > application, the VM loads ARFU and its implementation with a high > > > > > probability to no need it at all after > > > > > > > > > > > > > Does that really contribute sufficiently to slow down in start time? It > > > > really seems like a micro-optimisation. > > > small streams become big rivers (i don't know the idiomatic sentence in > > English, so it's a rough translation from a French idiom), > > "Death by a thousand cuts" is one of my favorites :). A "flat profile" is > another description of a similar thing. > In general, I agree that easy/cheap/maintainable/etc wins should be done even > if individually they don't matter much (if that were the requirement, there > would be no progress whatsoever). > In this case, using Unsafe for now seems trivial; when VH is ready, someone > is going to sweep the code anyway and this will be just one more place to > mechanically update. Is VH definitely going to be part of Java 9? If so, > then perhaps no point in making this change unless it's going to be > backported to Java 8. Also don't forget that releasing VarHandle API as a public API for 9 is vastly different from replacing all usages of Unsafe by some VarHandle methods inside the JDK, see Paul's answser about the bootstrap issues. R?mi From Roger.Riggs at Oracle.com Wed Apr 6 13:53:05 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 6 Apr 2016 09:53:05 -0400 Subject: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more In-Reply-To: <5704B01F.4070406@gmail.com> References: <56B72242.7050102@gmail.com> <56C43817.7060805@gmail.com> <7BA56B2F-C1C6-4EAF-B900-A825C6B602EF@oracle.com> <56CA080F.6010308@gmail.com> <56CB83FF.4010808@Oracle.com> <56CC8A4A.9080303@gmail.com> <56CEAC28.80802@gmail.com> <56CEB49A.4090000@oracle.com> <56CEC6A5.3070202@gmail.com> <56D0C5F5.7060509@Oracle.com> <56DC29DE.4040006@gmail.com> <059F3798-66D4-4300-B618-09868A04E3DC@oracle.com> <56E09299.2050900@gmail.com> <56ED5B! 7A.3090809@gmail.com> <8EDD817B-F124-4613-9EEE-7865EE67037D@oracle.com> <56F96778.5020202@gmail.com> <56FE914E.2070804@gmail.com> <56FE9D14.8010404@gmail.com> <56FEA5FF.4060801@gmail.com> <56FEED59.7090906@Oracle.com> <56FF04B5.2030507@oracle.com> <56FFABED.2060708@gmail.com> <5702E18D.7010807@Oracle.com> <5703CE96.4040001@gmail.com> <5704B01F.4070406@gmail.com> Message-ID: <570514C1.5000507@Oracle.com> Hi Peter, Since the current implementation of the old Cleaner and DirectByteBuffer works well and there is a lot of work piling up against the FC date, I'm in favor of keeping it as it is until the possibilities with Panama settle out. It would best if reclamation was not GC based, except as a last resort. As for the Cleaner API, it is intended to have a specific function and API. It may be that there is some advantage/optimization in the cleaner implementation at some future point but the API for general use should be concrete and specific. For more specific purposes, especially internal ones like the topic here, separate factory methods would be more appropriate than potential overloading and mix-in interfaces. Roger On 4/6/2016 2:43 AM, Peter Levart wrote: > Hi Roger, > > On 04/05/2016 04:41 PM, Peter Levart wrote: >>> On 04/04/2016 11:50 PM, Roger Riggs wrote: >>> I don't see the need to change Cleaner to an interface to be able to >>> provide >>> an additional method on CleanerImpl or a subclass and a factory >>> method could >>> provide for a clean and very targeted interface to Bits/Direct buffer. >> >> I would like this to be an instance method so it would naturally >> pertain to a particular Cleaner instance. Or it could be a static >> method that takes a Cleaner instance. One of my previous webrevs did >> have such method on the CleanerImpl, but I was advised to move it to >> Cleaner as a package-private method and expose it via SharedSecrets >> to internal code. I feel such "camouflage" is very awkward now that >> we have modules and other mechanisms exist. So I thought it would be >> most elegant to make Cleaner an interface so it can be extended with >> an internal interface to communicate intent in a type-safe and >> auto-discoverable way. The change to make it interface: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ >> >> >> ...actually simplifies implementation (33 lines removed in total) and >> could be seen as an improvement in itself. >> >> Are you afraid that if Cleaner was an interface, others would attempt >> to make implementations of it? Now that we have default methods on >> interfaces it is easy to compatibly extend the API even if it is an >> interface so that no 3rd party implementations are immediately >> broken. Are you thinking of security implications when some code is >> handed a Cleaner instance that it doesn't trust? I don't think there >> is a utility for Cleaner instances to be passed from untrusted to >> trusted code, do you? > > ...even if we don't do anything for DirectByteBuffer(s) in > java.lang.ref.Cleaner and leave things as they stand (using > jdk.internal.ref.Cleaner), I would still make this transition to > interface to enable possible future internal extensions to > java.lang.ref.Cleaner. As I said, this is a source compatible change, > but not binary compatible, so if we do it, it must be performed before > JDK 9 ships. > > Regards, Peter > From paul.sandoz at oracle.com Wed Apr 6 14:09:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 16:09:14 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> References: <57006917.4090200@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> Message-ID: > On 6 Apr 2016, at 15:28, forax at univ-mlv.fr wrote: > > > > While i fully agree in the general case, in disagree for this specific > > > case, > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > because BufferedInputStream uses an ARFU, each time someone starts a Java > > > application, the VM loads ARFU and its implementation with a high > > > probability to no need it at all after > > > > > > > Does that really contribute sufficiently to slow down in start time? It > > really seems like a micro-optimisation. > > small streams become big rivers (i don't know the idiomatic sentence in English, so it's a rough translation from a French idiom), > "Death by a thousand cuts" is one of my favorites :). A "flat profile" is another description of a similar thing. > I still remain unconvinced in this case that such changes warrant an increase in unsafe usage (temporary or otherwise). > In general, I agree that easy/cheap/maintainable/etc wins should be done even if individually they don't matter much (if that were the requirement, there would be no progress whatsoever). > > In this case, using Unsafe for now seems trivial; when VH is ready, someone is going to sweep the code anyway and this will be just one more place to mechanically update. Is VH definitely going to be part of Java 9? If so, then perhaps no point in making this change unless it's going to be backported to Java 8. > > Also don't forget that releasing VarHandle API as a public API for 9 is vastly different from replacing all usages of Unsafe by some VarHandle methods inside the JDK, see Paul's answser about the bootstrap issues. > VHs are now in jdk9/dev. I dunno when it will rise up to the master and the next EA build. Paul. From kumar.x.srinivasan at oracle.com Wed Apr 6 14:20:25 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 06 Apr 2016 07:20:25 -0700 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <57050D4E.30807@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> <570486E6.2030405@oracle.com> <5704CB3A.8080004@oracle.com> <57050A95.4040801@oracle.com> <57050D4E.30807@oracle.com> Message-ID: <57051B29.2030408@oracle.com> Alan, http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/ I made the changes as you suggested below, I have retained Files.createDirectories, here is why, changing it to createDirectory will throw FileAlreadyExistsException, which means, that if the output zip/jar file exists then an exception handler is required to ignore it. I don't think its worth the trouble. Thanks Kumar > > > On 06/04/2016 14:09, Kumar Srinivasan wrote: >> >>> >>> - Is Files.createDirectories needed? The walk is specified to be >>> depth first so you'll also visit parent directories first. >> >> Yes, zipfs does not allow me to create the file without creating the >> enclosing directory >> first, so if I were to do this in visitFile, then presumably I would >> have to add a >> check, to prevent duplicate creation going into the provider, only to >> find a >> directory already exists and return, not sure if this is what you >> want, because >> preVisitDirectory does this conveniently. > I should have been clearer, I was trying to say that createDirectory > should be sufficient here because the walk is specified to be depth > first. > >> >>> >>> - I'm also curious about the REPLACE_EXISTING as I assume that isn't >>> needed. >> >> Oh! while I was developing in NB as a discrete/stand alone project, I >> was reusing the >> same zip/jar output file, will leave it as-is, no harm, right ?. > No harm, it just caught my eye as not needed. > > -Alan From Alan.Bateman at oracle.com Wed Apr 6 14:38:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 15:38:11 +0100 Subject: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out In-Reply-To: <57051B29.2030408@oracle.com> References: <57040183.3010300@oracle.com> <57040336.9020703@oracle.com> <570486E6.2030405@oracle.com> <5704CB3A.8080004@oracle.com> <57050A95.4040801@oracle.com> <57050D4E.30807@oracle.com> <57051B29.2030408@oracle.com> Message-ID: <57051F53.70008@oracle.com> On 06/04/2016 15:20, Kumar Srinivasan wrote: > Alan, > > http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/ > > I made the changes as you suggested below, I have retained > Files.createDirectories, > here is why, changing it to createDirectory will throw > FileAlreadyExistsException, > which means, that if the output zip/jar file exists then an exception > handler is > required to ignore it. I don't think its worth the trouble. Okay, although each directory is only visited once so I don't immediately see how the FileAlreadyExistsException arises, unless this related to sym links in the jrt file system. In any case, the updated changes looking fine. I think I would still reduce some of the really long lines to make it easier for reviewers in the future. -Alan From claes.redestad at oracle.com Wed Apr 6 14:45:52 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Apr 2016 16:45:52 +0200 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> Message-ID: <57052120.5010609@oracle.com> On 04/06/2016 04:09 PM, Paul Sandoz wrote: >> small streams become big rivers (i don't know the idiomatic sentence in English, so it's a rough translation from a French idiom), >> "Death by a thousand cuts" is one of my favorites:). A "flat profile" is another description of a similar thing. >> > I still remain unconvinced in this case that such changes warrant an increase in unsafe usage (temporary or otherwise). > I did not intend for this patch to spark any controversy - in my mind it was just a rather straightforward and easy way to save a few Kbs (and some theoretic startup time) on small program startup and I'm happy to withdraw it based on the feedback. I do however think that reducing the dependency graph of things which are loaded in this early has merits on its own, regardless of how much it actually improves things. Using VHs here - or even in CHM - seems more controversial to me than using Unsafe to take shortcuts in low-level class libraries that need to boot fast and with as few dependencies as possible (since that allows them to be used in more places). Thanks! /Claes From forax at univ-mlv.fr Wed Apr 6 14:46:25 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Apr 2016 16:46:25 +0200 (CEST) Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> Message-ID: <1225605745.1953390.1459953985317.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoy?: Mercredi 6 Avril 2016 16:09:14 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe > > > > On 6 Apr 2016, at 15:28, forax at univ-mlv.fr wrote: > > > > > > While i fully agree in the general case, in disagree for this specific > > > > case, > > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > > because BufferedInputStream uses an ARFU, each time someone starts a > > > > Java > > > > application, the VM loads ARFU and its implementation with a high > > > > probability to no need it at all after > > > > > > > > > > Does that really contribute sufficiently to slow down in start time? It > > > really seems like a micro-optimisation. > > > > small streams become big rivers (i don't know the idiomatic sentence in > > English, so it's a rough translation from a French idiom), > > "Death by a thousand cuts" is one of my favorites :). A "flat profile" is > > another description of a similar thing. > > > I still remain unconvinced in this case that such changes warrant an increase > in unsafe usage (temporary or otherwise). Ok, you win :) > > > In general, I agree that easy/cheap/maintainable/etc wins should be done > > even if individually they don't matter much (if that were the requirement, > > there would be no progress whatsoever). > > > > In this case, using Unsafe for now seems trivial; when VH is ready, someone > > is going to sweep the code anyway and this will be just one more place to > > mechanically update. Is VH definitely going to be part of Java 9? If so, > > then perhaps no point in making this change unless it's going to be > > backported to Java 8. > > > > Also don't forget that releasing VarHandle API as a public API for 9 is > > vastly different from replacing all usages of Unsafe by some VarHandle > > methods inside the JDK, see Paul's answser about the bootstrap issues. > > > > VHs are now in jdk9/dev. I dunno when it will rise up to the master and the > next EA build. Oh, i didn't notice. congrat ! > > Paul. > R?mi From vitalyd at gmail.com Wed Apr 6 14:52:31 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 6 Apr 2016 10:52:31 -0400 Subject: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe In-Reply-To: References: <57006917.4090200@oracle.com> <5703D682.1080300@oracle.com> <5BA27ADF-6577-4E85-B1B9-81DA5F93EF24@oracle.com> <1893890061.1837846.1459937403446.JavaMail.zimbra@u-pem.fr> <1396002249.1867527.1459942858286.JavaMail.zimbra@u-pem.fr> <1118297661.1921574.1459949327057.JavaMail.zimbra@u-pem.fr> Message-ID: So are there any bootstrap issues with VH that would preclude using it in BufferedInputStream? Is that even known at this point? You mentioned that VH was designed to minimize bootstrapping issues, but where's the "minimized" line drawn? On Wed, Apr 6, 2016 at 10:09 AM, Paul Sandoz wrote: > > > On 6 Apr 2016, at 15:28, forax at univ-mlv.fr wrote: > > > > > > While i fully agree in the general case, in disagree for this > specific > > > > case, > > > > there are few uses of ARFU inside the JDK (or outside) but currently > > > > because BufferedInputStream uses an ARFU, each time someone starts a > Java > > > > application, the VM loads ARFU and its implementation with a high > > > > probability to no need it at all after > > > > > > > > > > Does that really contribute sufficiently to slow down in start time? It > > > really seems like a micro-optimisation. > > > > small streams become big rivers (i don't know the idiomatic sentence in > English, so it's a rough translation from a French idiom), > > "Death by a thousand cuts" is one of my favorites :). A "flat profile" > is another description of a similar thing. > > > I still remain unconvinced in this case that such changes warrant an > increase in unsafe usage (temporary or otherwise). > > > In general, I agree that easy/cheap/maintainable/etc wins should be done > even if individually they don't matter much (if that were the requirement, > there would be no progress whatsoever). > > > > In this case, using Unsafe for now seems trivial; when VH is ready, > someone is going to sweep the code anyway and this will be just one more > place to mechanically update. Is VH definitely going to be part of Java 9? > If so, then perhaps no point in making this change unless it's going to be > backported to Java 8. > > > > Also don't forget that releasing VarHandle API as a public API for 9 is > vastly different from replacing all usages of Unsafe by some VarHandle > methods inside the JDK, see Paul's answser about the bootstrap issues. > > > > VHs are now in jdk9/dev. I dunno when it will rise up to the master and > the next EA build. > > Paul. > From paul.sandoz at oracle.com Wed Apr 6 15:48:53 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Apr 2016 17:48:53 +0200 Subject: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations In-Reply-To: References: <755756441.20160401222505@gmail.com> Message-ID: <9DA064B7-FB87-46D7-931E-D738C912AFD9@oracle.com> > On 4 Apr 2016, at 21:28, Stefan Zobel wrote: > > Hi Tagir, > > good catch! I like the proposal. > Me too. +1. Extra bonus points to test, in addition to the tested characteristics, that the boxed/converted elements remain sorted/distinct :-) >> >> (different longs can be converted into the same double, so DISTINCT is >> not preserved here; not sure whether this is possible for ints) >> > > I think IntStream.asDoubleStream() can also preserve DISTINCT as > different ints can't be mapped to the same double. > Yes, there are 53 bits to play with, which is more than enough to exactly represent the full range of int values. Paul. > > Math.ulp((double) Integer.MIN_VALUE) ~ 4.7E-7 > > in contrast to > > Math.ulp((double) Long.MIN_VALUE) = 2048.0 > > > So there are more than enough doubles in the vicinity of large int > values. It's only when ulp get's >= 1.0 that distinct integral values > need to be mapped to the same double (that happens between 1.0E15 and > 1.0E16 for longs). Please anyone correct me if I'm wrong. > > > Regards, > Stefan > From alejandro.murillo at oracle.com Wed Apr 6 16:48:32 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Wed, 6 Apr 2016 10:48:32 -0600 Subject: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed In-Reply-To: <5704BC96.1060303@oracle.com> References: <57049B18.5050307@oracle.com> <5704BC96.1060303@oracle.com> Message-ID: <57053DE0.6080001@oracle.com> It was late for me, so Amy took over and fixed it Thanks Alejandro On 4/6/2016 1:36 AM, Alan Bateman wrote: > > > On 06/04/2016 06:14, Alejandro Murillo wrote: >> >> I'd like to push the changeset below to exclude >> java/nio/Buffer/BasicByte.java >> It started failing after the hotspot snapshot was pushed to jdk9/dev >> tonight. >> https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for >> that failure. > > Would it be possible to add @modules java.base/jdk.internal.misc, as > below, and not exclude these tests? > > -Alan > > > $ hg diff -g . > diff --git a/test/java/nio/Buffer/Basic.java > b/test/java/nio/Buffer/Basic.java > --- a/test/java/nio/Buffer/Basic.java > +++ b/test/java/nio/Buffer/Basic.java > @@ -22,6 +22,7 @@ > */ > > /* @test > + * @modules java.base/jdk.internal.misc > * @summary Unit test for buffers > * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 > 4490253 4523725 > * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 > 4938424 6231529 > diff --git a/test/java/nio/Buffer/CopyDirectMemory.java > b/test/java/nio/Buffer/CopyDirectMemory.java > --- a/test/java/nio/Buffer/CopyDirectMemory.java > +++ b/test/java/nio/Buffer/CopyDirectMemory.java > @@ -25,6 +25,7 @@ > * @summary Test view buffer bulk operations for large buffers. > * @bug 4463011 > * > + * @modules java.base/jdk.internal.misc > * @build Basic > * @run main CopyDirectMemory > */ -- Alejandro From coleen.phillimore at oracle.com Wed Apr 6 17:58:56 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Apr 2016 13:58:56 -0400 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <57044EC8.7050602@oracle.com> References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> <5703F5E7.4060404@oracle.com> <5704030F.80906@oracle.com> <57044EC8.7050602@oracle.com> Message-ID: <57054E60.6030504@oracle.com> On 4/5/16 7:48 PM, Brent Christian wrote: > Thanks, Coleen. Coordinating method/function names on "to stack trace > element" is a fine thing. I've done so in the updated webrev, and > also implemented Claes's suggestion. > > http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html Thank you for making this change. It looks good! I've reviewed this. Coleen > > -Brent > On 04/05/2016 11:25 AM, Coleen Phillimore wrote: >> >> A correction below. >> >> On 4/5/16 1:29 PM, Coleen Phillimore wrote: >>> >>> Also meant to include core-libs-dev in the email. >>> Thanks, >>> Coleen >>> >>> On 4/5/16 1:27 PM, Coleen Phillimore wrote: >>>> >>>> Hi, I've reviewed the hotspot changes and some of the jdk changes. >>>> This looks really good. >>>> >>>> One comment about the jvm function names: >>>> >>>> I think FillInStackTraceElement is too close of a name to >>>> Throwable::fill_in_stack_trace(). >>>> >>>> -JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame)) >>>> +JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject >>>> frame, jobject stack)) >>>> JVMWrapper("JVM_SetMethodInfo"); >>>> - Handle stackFrame(THREAD, JNIHandles::resolve(frame)); >>>> - java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD); >>>> + Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); >>>> + Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); >>>> + java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info, >>>> stack_trace_element, THREAD); JVM_END >>>> >>>> >>>> And the function is called fill_methodInfo in the javaClasses >>>> function. >>>> >>>> I think the JVM and the java_lang_StackFrameInfo function names >>>> should be closer. >>>> >>>> I wonder if the name JVM_ToStackFrameElement() and >>>> java_lang_StackFrameInfo::to_stack_frame_element() would be better >>>> and then it'd match the Java name. >>>> >> >> I meant JVM_ToStackTraceElement() and >> java_lang_StackFrameInfo::to_stack_trace_element(), since it's producing >> a StackTraceElement. >> >> thanks, >> Coleen >>>> Thanks! >>>> Coleen >>>> >>>> On 4/4/16 9:29 PM, Mandy Chung wrote: >>>>>> On Apr 4, 2016, at 4:45 PM, Brent Christian >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to check in some footprint and code reduction changes to >>>>>> the java.lang.StackWalker implementation. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8153123 >>>>>> >>>>> This looks good to me. >>>>> >>>>> One thing to mention is that this patch is a follow-up work from the >>>>> investigation on what it takes to enable Throwable to use >>>>> StackWalker (JDK-8141239). The current built-in VM backtrace is very >>>>> compact and performant. We have identified and prototypes the >>>>> performance improvements if Throwable backtrace is generated using >>>>> stack walker. There are some performance gaps that we agree to >>>>> defer JDK-8141239 to a future release and improve the footprint >>>>> performance and GC throughput concerns when MemberNames are stored >>>>> in the throwable backtrace. >>>>> >>>>> Mandy >>>>> >>>> >>> >> > From iris.clark at oracle.com Wed Apr 6 18:28:12 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Apr 2016 11:28:12 -0700 (PDT) Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References:

Message-ID: Hi, Volker. Sorry for the delay. I agree that the old implementation isn't quite correct. I can't see us potentially having a JCP MR for a security or patch release (9.0.0.X and 9.0.X respectively). I could see a MR for an very unusual minor release (9.X). If we had an MR there's no guarantee that we'd need to change the java.specification.version system property. However, in the event that we did need to change the java.specification.version, it should match that release's $MAJOR.$MINOR, even if it meant that we had a sequence of specification version numbers with gaps. As an example, let's say that JDK 9 is released via umbrella JSR with java.specification.value of "9". The system property would remain at "9" for all releases regardless of type until we choose to have a MR. Should that MR occur while we're working on minor release 9.3.X and there is a need to change the value of java.specification.value, it would become "9.3" and would remain so in every release until the next MR. While we haven't changed the system property recently, I think that we need to future-proof ourselves a little bit for MRs as described above. Assuming that we change the syntax of java.specification.version to $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make a similar change to the syntax of java.vm.specification.version. [ Note that in the current implementation, I believe that the values of java.specification.version and java.vm.specification.version are tied to each other. ] Changing the syntax of java{.vm}?specification.version requires a CCC which I will file once we have agreement on the necessary changes. Regards, Iris -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Tuesday, April 05, 2016 10:26 AM To: Java Core Libs Cc: verona-dev at openjdk.java.net Subject: Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version Hi, can somebody please review this trivial change? Regards, Volker On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis wrote: > Hi, > > can I please have a review for this small fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 > https://bugs.openjdk.java.net/browse/JDK-8149519 > > Currently the value of the java.specification.version property comes > from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is > currently set to VERSION_NUMBER which is the same value which is also > used for the java.version property. > > This is a bad idea, because VERSION_NUMBER is a dot separated sequence > of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. > for every build and/or update version). If we are configuring with > "--with-version-patch=1" for example, VERSION_NUMBER and java.version > will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION > and java.specification.version have the same, dotted value. And it > breaks a lot of legacy applications which parse > java.specification.version as a float number. That code would still > work if java.specification.version would be a concrete number (e.g. > '9' or '10'). > > I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in > common/autoconf/spec.gmk.in. This should be the "right value" until we > get a specification change during a major release which hasn't > happened for quite some time now. > > Regards, > Volker From brent.christian at oracle.com Wed Apr 6 18:50:35 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 06 Apr 2016 11:50:35 -0700 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: References: <5702FC9B.7020600@oracle.com> <5703F579.8050702@oracle.com> <5703F5E7.4060404@oracle.com> <5704030F.80906@oracle.com> <57044EC8.7050602@oracle.com> Message-ID: <57055A7B.30903@oracle.com> On 04/05/2016 10:36 PM, Mandy Chung wrote: > > Looks good. Nit: can you add a space after ?synchronized? in StackFrameInfo.java line 109: > 109 synchronized(this) { Yep - changed locally. Thanks, -Brent From huizhe.wang at oracle.com Wed Apr 6 19:33:49 2016 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 06 Apr 2016 12:33:49 -0700 Subject: RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file. Message-ID: <5705649D.3080001@oracle.com> Hi, Fix a typo in the catalog reader where the intention was to set the defer attribute, but the prefer was set instead. The tests are from the JCK. JBS: https://bugs.openjdk.java.net/browse/JDK-8150969 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/webrev/ Thanks, Joe From lance.andersen at oracle.com Wed Apr 6 20:09:58 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 6 Apr 2016 16:09:58 -0400 Subject: RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file. In-Reply-To: <5705649D.3080001@oracle.com> References: <5705649D.3080001@oracle.com> Message-ID: looks fine joe > On Apr 6, 2016, at 3:33 PM, huizhe wang wrote: > > Hi, > > Fix a typo in the catalog reader where the intention was to set the defer attribute, but the prefer was set instead. The tests are from the JCK. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8150969 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/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 Wed Apr 6 20:17:05 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Apr 2016 13:17:05 -0700 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> References: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> Message-ID: We missed Aleksey's changes, which broke our integration. Historically, hotspot was more independent from jdk, and there were no "flag days" that required both to be modified together. In jsr166 CVS we still consistently use sun.misc.Unsafe, because it's ... ummm ... more portable. Our openjdk integration script changes that to jdk.internal.misc, but needs modification. Most of these will sadly soon change again, due to varhandlification. Everything regenerated, now with: # Replaces sun.misc.Unsafe with jdk9's preferred jdk.internal.misc find src/main -name '*.java' \ | xargs perl -pi -0777 \ -e 's~\bsun\.misc\.Unsafe\b~jdk.internal.misc.Unsafe~g; s~\bputOrdered([A-Za-z]+)\b~put${1}Release~g' On Wed, Apr 6, 2016 at 5:54 AM, Paul Sandoz wrote: > Hi Martin, > > miscellaneous > ? > > You reverted Aleksey?s change s/putOrderedObject/putObjectRelease. > > The *Ordered* methods are now removed from the ?real? jdk.internal.misc.Unsafe. > > Paul. > > >> On 3 Apr 2016, at 20:29, Martin Buchholz wrote: >> >> Easy changes to review, up to April Fools day, in part to make room >> for later unfinished more exciting changes. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > From Roger.Riggs at Oracle.com Wed Apr 6 20:19:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 6 Apr 2016 16:19:22 -0400 Subject: RFR:JDK-8148849:Truncating Duration In-Reply-To: References: <56FA727C.201@oracle.com> <56FBB7AF.3030409@oracle.com> Message-ID: <57056F4A.4070905@Oracle.com> Hi Nadeesh, An internal reviewer pointed out that Duration does not have 'fields' (it is not a TemporalAccessor) so the description might be clarified by saying: + * Truncating the duration returns a copy of the original with *conceptual *fields + * smaller than the specified unit set to zero. The rest is fine. Reviewed Thanks, Roger On 3/30/2016 9:33 AM, Stephen Colebourne wrote: > Yes, that looks OK now. > thanks > Stephen > > > On 30 March 2016 at 12:25, nadeesh tv wrote: >> Hi Stephen, >> >> Thanks for the comments. >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8148849/webrev.01/ >> >> Made a change in unit == ChronoUnit.SECONDS also >> >> >> Regards, >> Nadeesh TV >> >> >> On 3/29/2016 6:10 PM, Stephen Colebourne wrote: >>> We're almost there, but looking at the tests, it looks like the >>> behaviour is wrong: >>> >>> The intended behaviour is that >>> -20.5mins (minus 20 minutes 30 secs) should truncate to -20mins >>> -2.1secs truncate to -2secs >>> >>> Note that the truncation is different to Instant here. >>> An Instant truncates towards the far past - like RoundingMode.FLOOR >>> A Duration truncates towards the zero - like RoundingMode.DOWN >>> >>> Stephen >>> >>> >>> On 29 March 2016 at 13:18, nadeesh tv wrote: >>>> Hi all, >>>> >>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8148849 >>>> >>>> Enhanced Duration by adding public Duration truncatedTo(TemporalUnit >>>> unit) >>>> >>>> Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/ >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> -- >> Thanks and Regards, >> Nadeesh TV >> From john.r.rose at oracle.com Wed Apr 6 22:03:29 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Apr 2016 15:03:29 -0700 Subject: RFR: 8150469: unpack200 fails to compare crc correctly. In-Reply-To: <56D46C79.80807@oracle.com> References: <56D46C79.80807@oracle.com> Message-ID: <4BF8B530-17D0-435A-B417-75389637A16D@oracle.com> Looks good, a clean fix. The negative test should be called "testBadChecksum" or "testBrokenTrailer". ? John On Feb 29, 2016, at 8:06 AM, Kumar Srinivasan wrote: > > Hello John, Alex, > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8150469 > > The previous fix keeps the storage in the unpacker object which is > reset, for a multi-segmented pack archive, thus the computed crc32 is lost. > > Now the storage is moved into the gzip container, which persists, across > multiple segments, I also added the length check as specified by RFC 1952, > as implemented by JDK. > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/e4af8119eba4/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#l222 > > The review is at: > http://cr.openjdk.java.net/~ksrini/8150469/webrev.00/ > > > Thanks > Kumar > > From john.r.rose at oracle.com Wed Apr 6 23:14:07 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Apr 2016 16:14:07 -0700 Subject: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR In-Reply-To: <56F0504A.4030204@oracle.com> References: <56F0504A.4030204@oracle.com> Message-ID: <17BABD81-589E-42A0-B5F1-6B3BFE496392@oracle.com> Good. Please change the comment: s/null, no tuple change, force recomputation/null, drop ICs attribute, force CP recomputation/ Reordering BSMs and ICs should work. The BSMs may need extra ICs, but ICs cannot depend on BSMs. I wonder why we did the other order first? I guess because that is what the spec. says. Oh, there's a problem with the attribute insertion order logic; it's buggy that we unconditionally insert a BSMs attr. and then delete it later. (That goes wrong when change<0 and we recompute from scratch.) Suggested amended patch enclosed. ? John On Mar 21, 2016, at 12:49 PM, Kumar Srinivasan wrote: > > Hi John, > > This patch contains fixes for two bugs: > 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR > 8062335: Pack200 Java implementation differs from C version, outputs unused UTF8 for BootstrapMethods Note: The test case exhibits both of the above. > > With this the classes produced by java and the native implementation are congruent, > though the JDK image's classes exhibit these issues, as a precaution I have extracted the > minimal set of classes to reproduce the issues, into the golden jar. > > The webrev is at: > http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/ > > Thanks > Kumar > -------------- next part -------------- diff --git a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java @@ -312,6 +312,12 @@ void setBootstrapMethods(Collection bsms) { assert(bootstrapMethods == null); // do not do this twice bootstrapMethods = new ArrayList<>(bsms); + // Edit the attribute list, if necessary. + Attribute a = getAttribute(attrBootstrapMethodsEmpty); + if (bootstrapMethods != null && a == null) + addAttribute(attrBootstrapMethodsEmpty.canonicalInstance()); + else if (bootstrapMethods == null && a != null) + removeAttribute(a); } boolean hasInnerClasses() { diff --git a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java @@ -1193,16 +1193,25 @@ cls.visitRefs(VRM_CLASSIC, cpRefs); ArrayList bsms = new ArrayList<>(); - /* - * BootstrapMethod(BSMs) are added here before InnerClasses(ICs), - * so as to ensure the order. Noting that the BSMs may be - * removed if they are not found in the CP, after the ICs expansion. - */ - cls.addAttribute(Package.attrBootstrapMethodsEmpty.canonicalInstance()); // flesh out the local constant pool ConstantPool.completeReferencesIn(cpRefs, true, bsms); + // Add the BSMs and references as required. + if (!bsms.isEmpty()) { + // Add the attirbute name to the CP (visitRefs would have wanted this). + cpRefs.add(Package.getRefString("BootstrapMethods")); + // The pack-spec requires that BootstrapMethods precedes the InnerClasses attribute. + // So add BSMs now before running expandLocalICs. + // But first delete any local InnerClasses attr. (This is rare.) + List localICs = cls.getInnerClasses(); + cls.setInnerClasses(null); + Collections.sort(bsms); + cls.setBootstrapMethods(bsms); + // Re-add the ICs, so the attribute lists are in the required order. + cls.setInnerClasses(localICs); + } + // Now that we know all our local class references, // compute the InnerClasses attribute. int changed = cls.expandLocalICs(); @@ -1221,16 +1230,6 @@ ConstantPool.completeReferencesIn(cpRefs, true, bsms); } - // remove the attr previously set, otherwise add the bsm and - // references as required - if (bsms.isEmpty()) { - cls.attributes.remove(Package.attrBootstrapMethodsEmpty.canonicalInstance()); - } else { - cpRefs.add(Package.getRefString("BootstrapMethods")); - Collections.sort(bsms); - cls.setBootstrapMethods(bsms); - } - // construct a local constant pool int numDoubles = 0; for (Entry e : cpRefs) { From paul.sandoz at oracle.com Thu Apr 7 09:07:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Apr 2016 11:07:48 +0200 Subject: RFR 8152645 VarHandle lookup access control tests Message-ID: <81AC210F-C0C7-4DAA-BAA9-FCCCF89699FB@oracle.com> Hi, Please review a test to verify access control of looking up fields using a VarHandle: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webrev/ For completeness i also added tests for MH as i could not find any such existing tests. Further follow on work might be to test lookup to fields across module boundaries. Paul. From volker.simonis at gmail.com Thu Apr 7 10:11:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Apr 2016 12:11:09 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References:

Message-ID: On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark wrote: > Hi, Volker. > > Sorry for the delay. I agree that the old implementation isn't quite correct. I can't see us potentially having a JCP MR for a security or patch release (9.0.0.X and 9.0.X respectively). > > I could see a MR for an very unusual minor release (9.X). If we had an MR there's no guarantee that we'd need to change the java.specification.version system property. However, in the event that we did need to change the java.specification.version, it should match that release's $MAJOR.$MINOR, even if it meant that we had a sequence of specification version numbers with gaps. > > As an example, let's say that JDK 9 is released via umbrella JSR with java.specification.value of "9". The system property would remain at "9" for all releases regardless of type until we choose to have a MR. Should that MR occur while we're working on minor release 9.3.X and there is a need to change the value of java.specification.value, it would become "9.3" and would remain so in every release until the next MR. > > While we haven't changed the system property recently, I think that we need to future-proof ourselves a little bit for MRs as described above. > > Assuming that we change the syntax of java.specification.version to $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make a similar change to the syntax of java.vm.specification.version. [ Note that in the current implementation, I believe that the values of java.specification.version and java.vm.specification.version are tied to each other. ] > > Changing the syntax of java{.vm}?specification.version requires a CCC which I will file once we have agreement on the necessary changes. > Hi Iris, thanks for your comments. I don't think that using $MAJOR.$MINOR for java.specification.version is a good solution. As far as I understand, JEP 223 (i.e. the new version scheme) is an Oracle/OpenJDK implementation detail. There is no JSR for this and it won't be enforced trough a JCK/TCK test (please correct me if I'm wrong). The new versioning schema references the JCP in that is says that the $MAJOR number corresponds to the "Java SE Platform Specification" number as specified by the JCP in the corresponding JSR. But not vice versa - i.e. there's no JSR referencing JEP 223. JEP 223 also says that the $MINOR number will be increased if this is mandated by a Maintenance Release of the relevant Platform Specification (by the JCP). But as you correctly noticed, in reality, $MINOR is expected to be increased frequently compared to the number of Java SE Maintenance Releases (if there will be any at all). So if the JCP should decide to publish a Maintenance Release, why should it name if after the then actual $MINOR update release number of the Oracle/OpenJDK. I think a natural choice for such a MR would be "9.1", no difference at which update release version Oracle/OpenJDK will be at that time. So I think it would be best to decouple java.specification.version from the Java versioning schema. We can start with java.specification.version == $MAJOR. If there should be a MR sometimes in the future, we can just set java.specification.version to the version number of that MR, whatever that will be. That's exactly what this change is about. Regarding the value of java.vm.specification.version I'm not sure what it actually means at all. Until Java 1.6, java.vm.specification.version has always been "1.0", while java.specification.version has changed from 1.4, to 1.5 and 1.6 (notice that java.specification.version has never been changed to 1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting with Java 7, java.vm.specification.version is the same like java.specification.version (i.e. 1.7 and 1.8) but I'm not sure if that is mandated by JCP and if it will be possible that these numbers will diverge for a Java release. I.e. will it be possible to have a new Java version (say Java 10) where the VM specification (and thus java.vm.specification.version) will remain unchanged (say "9")? From my understanding, that should be possible. Especially for a MR, it seems highly probable to me that the java.specification.version will be increased, but the VM specification (and thus java.vm.specification.version) will remain unchanged. So again, I think we shouldn't tie java.vm.specification.version to java.specification.version and simply start with java.vm.specification.version == $MAJOR. The current implementation already does this correctly. While the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in and it is being set in jdk/src/java.base/share/native/libjava/System.c the java.vm.specification.version property is set being in hotspot/src/share/vm/runtime/arguments.cpp directly to the major Java version number. Because of this difference, there are currently no problems with the java.vm.specification.version property caused by the new versioning schema. As a side note: while I wrote all this down, I realized that we have java.lang.Package.getSpecificationVersion() in the class library which returns the specification version of a specific package. But this API is not mentioned anywhere in JEP 223. Shouldn't the output of java.lang.Package.getSpecificationVersion() be aligned with JEP 223 and java.vm.specification.version as well? And a final question. Why did we put jdk.Version into the jdk package? As far as I know, jdk is not a standard Java package and thus not enforced by the Java standard (please correct me if I'm wrong). Shouldn't the Version class be in a standard Java package such that it's implementation will be mandatory for all Java implementations? Regards, Volker > Regards, > Iris > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Tuesday, April 05, 2016 10:26 AM > To: Java Core Libs > Cc: verona-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version > > Hi, > > can somebody please review this trivial change? > > Regards, > Volker > > > On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis wrote: >> Hi, >> >> can I please have a review for this small fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >> https://bugs.openjdk.java.net/browse/JDK-8149519 >> >> Currently the value of the java.specification.version property comes >> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >> currently set to VERSION_NUMBER which is the same value which is also >> used for the java.version property. >> >> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >> for every build and/or update version). If we are configuring with >> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >> and java.specification.version have the same, dotted value. And it >> breaks a lot of legacy applications which parse >> java.specification.version as a float number. That code would still >> work if java.specification.version would be a concrete number (e.g. >> '9' or '10'). >> >> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >> common/autoconf/spec.gmk.in. This should be the "right value" until we >> get a specification change during a major release which hasn't >> happened for quite some time now. >> >> Regards, >> Volker From magnus.ihse.bursie at oracle.com Thu Apr 7 10:52:56 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Apr 2016 12:52:56 +0200 Subject: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport ) In-Reply-To: <5702515D.3040502@oracle.com> References: <570240D6.4000303@oracle.com> <5702416F.3000500@oracle.com> <57024A25.4000202@oracle.com> <5702515D.3040502@oracle.com> Message-ID: <57063C08.1060400@oracle.com> On 2016-04-04 13:34, Alan Bateman wrote: > > > On 04/04/2016 12:04, Erik Joelsson wrote: >> Makefile looks good. >> >> If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of >> libjava, should you also remove it from the mapfile for libjava? >> > Yes, libjava/mapfile-vers will need to be updated too. It otherwise > looks okay to me, just a pity that it requires introducing another > native library. Long term, we could consider trying to consolidate all native libraries for every module into a single one, e.g. something like libjava.base.so etc. Or at least provide a lib$MODULE as a default case where there is no need for a more specific library. /Magnus > > -Alan From daniel.fuchs at oracle.com Thu Apr 7 11:24:02 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Apr 2016 13:24:02 +0200 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <5702FC9B.7020600@oracle.com> References: <5702FC9B.7020600@oracle.com> Message-ID: <57064352.5010800@oracle.com> Hi Brent, This looks good! Thanks for taking care of this one. In http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html 548 objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames)); 549 objArrayHandle frames_array_h(THREAD, fa); 550 551 int limit = start_index + frame_count; 552 if (frames_array_h.is_null()) { 553 THROW_MSG_(vmSymbols::java_lang_IllegalArgumentException(), "parameters and mode mismatch", NULL); 554 } Can frames_array_h.is_null() ever be true, given that we used JNIHandles::resolve_non_null(frames) at line 548? I wonder if lines 552-554 are a remnant of the previous implementation and could be removed now... 589 Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); 590 Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); Should these call JNIHandles::resolve_non_null instead? http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/jdk/src/java.base/share/classes/java/lang/StackFrameInfo.java.frames.html I'd be very tempted to make 'ste' private volatile. That's all for me :-) best regards, -- daniel On 05/04/16 01:45, Brent Christian wrote: > Hi, > > I'd like to check in some footprint and code reduction changes to the > java.lang.StackWalker implementation. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153123 > > A summary of the changes: > > * remove the "stackwalk.newThrowable" system property and > "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking > > * Streamline StackFrameInfo fields > > * Refactor/streamline StackStreamFactory (no more separate > classes[]/StackFrame[] arrays, remove unneeded (for now) > StackStreamFactory.StackTrace class) > > > Given the hotspot changes, I plan to push this through hs-rt. > > Thanks, > -Brent > From paul.sandoz at oracle.com Thu Apr 7 13:17:13 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Apr 2016 15:17:13 +0200 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: References: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> Message-ID: <18424863-8530-47E3-9529-DA8EE8229557@oracle.com> > On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > > We missed Aleksey's changes, which broke our integration. > Looks good. Regarding CompletableFutureTest.testManyDependents i presume that kind of test was not failing before the modifications to CompletableFuture? I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent?s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in theory that test should run more efficiently? Paul. > Historically, hotspot was more independent from jdk, and there were no > "flag days" that required both to be modified together. > > In jsr166 CVS we still consistently use sun.misc.Unsafe, because it's > ... ummm ... more portable. > Our openjdk integration script changes that to jdk.internal.misc, but > needs modification. > Most of these will sadly soon change again, due to varhandlification. > > Everything regenerated, now with: > > # Replaces sun.misc.Unsafe with jdk9's preferred jdk.internal.misc > find src/main -name '*.java' \ > | xargs perl -pi -0777 \ > -e 's~\bsun\.misc\.Unsafe\b~jdk.internal.misc.Unsafe~g; > s~\bputOrdered([A-Za-z]+)\b~put${1}Release~g' > > On Wed, Apr 6, 2016 at 5:54 AM, Paul Sandoz wrote: >> Hi Martin, >> >> miscellaneous >> ? >> >> You reverted Aleksey?s change s/putOrderedObject/putObjectRelease. >> >> The *Ordered* methods are now removed from the ?real? jdk.internal.misc.Unsafe. >> >> Paul. >> >> >>> On 3 Apr 2016, at 20:29, Martin Buchholz wrote: >>> >>> Easy changes to review, up to April Fools day, in part to make room >>> for later unfinished more exciting changes. >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ >> From paul.sandoz at oracle.com Thu Apr 7 13:39:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Apr 2016 15:39:12 +0200 Subject: RFR 8151705 VarHandle.AccessMode enum names should conform to code style Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ I was persuaded (in internal CCC review) to change the enum VarHandle.AccessMode constant names to conform to the expected Java style. Previously, for convenience, the names corresponded exactly with the VH sig-poly method names. Most of the patch is just refactoring. I have added two new methods to translate to/from the sig-poly method name domain: 1175 /** 1176 * Returns the {@code VarHandle} signature-polymorphic method name 1177 * associated with this {@code AccessMode} value 1178 * 1179 * @return the signature-polymorphic method name 1180 * @see #valueFromMethodName 1181 */ 1182 public String methodName() { 1183 return methodName; 1184 } 1185 1186 /** 1187 * Returns the {@code AccessMode} value associated with the specified 1188 * {@code VarHandle} signature-polymorphic method name. 1189 * 1190 * @param methodName the signature-polymorphic method name 1191 * @return the {@code AccessMode} value 1192 * @throws IllegalArgumentException if there is no {@code AccessMode} 1193 * value associated with method name (indicating the method 1194 * name does not correspond to a {@code VarHandle} 1195 * signature-polymorphic method name). 1196 * @see #methodName 1197 */ 1198 public static AccessMode valueFromMethodName(String methodName) { 1199 AccessMode am = methodNameToAccessMode.get(methodName); 1200 if (am != null) return am; 1201 throw new IllegalArgumentException("No AccessMode value for method name " + methodName); 1202 } Paul. From spliterator at gmail.com Thu Apr 7 14:33:14 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Thu, 7 Apr 2016 16:33:14 +0200 Subject: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations In-Reply-To: <755756441.20160401222505@gmail.com> References: <755756441.20160401222505@gmail.com> Message-ID: Hi Tagir, a few comments below a) IntPipeline: public final mapToObj(IntFunction mapper, int opFlags) should be private, not public b) IntPipeline: asDoubleStream() - as already discussed, 0 should be passed as the opFlags value to the DoublePipeline.StatelessOp constructor c) I think, the new "private final mapToObj(...)" methods can be "private" (dropping the "final") Regards, Stefan 2016-04-01 18:25 GMT+02:00 Tagir F. Valeev : > Hello! > > Please review and sponsor the following patch: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ > > The patch preserves more characteristics on primitive stream > operations: > IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT > IntStream.asLongStream() preserves SORTED and DISTINCT > IntStream.asDoubleStream() and LongStream.asDoubleStream() preserves SORTED > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > > Fixing the boxed() case is especially important as distinct() for > primitive streams is implemented like boxed().distinct().unbox, so the > actual distinct() operation cannot take the advantage of DISTINCT flag > (skip the operation at all) or SORTED flag (switch to more efficient > implementation). > > Here's the small JMH benchmark which measures the performance boost of > quite common operation: sort the input numbers and leave only distinct > ones: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/jmh/ > > new Random(1).ints(size).sorted().distinct().toArray() > > I've got the following results. > > 9ea+111: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,612 ? 0,004 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 92,848 ? 1,039 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 32147,205 ? 3487,422 us/op > > 9ea+111 patched: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,435 ? 0,001 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 40,555 ? 0,772 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 9031,651 ? 73,956 us/op > > With best regards, > Tagir Valeev. > From martinrb at google.com Thu Apr 7 14:55:04 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Apr 2016 07:55:04 -0700 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: <18424863-8530-47E3-9529-DA8EE8229557@oracle.com> References: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> <18424863-8530-47E3-9529-DA8EE8229557@oracle.com> Message-ID: On Thu, Apr 7, 2016 at 6:17 AM, Paul Sandoz wrote: > >> On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > Looks good. > > Regarding CompletableFutureTest.testManyDependents i presume that kind of test was not failing before the modifications to CompletableFuture? Right - technically it was not failing before, but the O(N^2) performance in case of regression would be noticed quickly. And it seems like a generally useful test. > > I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent?s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in theory that test should run more efficiently? It's not useful to clean the stack of a future that has completed because all of its dependents will be triggered anyways, so there's no risk of garbage accumulation. But jsr166 CVS already has followon changes in this area that are not part of this integration. From spliterator at gmail.com Thu Apr 7 15:28:54 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Thu, 7 Apr 2016 17:28:54 +0200 Subject: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations In-Reply-To: <755756441.20160401222505@gmail.com> References: <755756441.20160401222505@gmail.com> Message-ID: Hi Tagir, another minor issue. The testFlags() methods in IntPrimitiveOpsTests / LongPrimitiveOpsTests each have a duplicated assert: IntPrimitiveOpsTests: assertFalse(IntStreams.of(1, 10).boxed().spliterator() .hasCharacteristics(Spliterator.SORTED)); LongPrimitiveOpsTests: assertFalse(LongStreams.of(1, 10).boxed().spliterator() .hasCharacteristics(Spliterator.SORTED)); The asserts for IntStreams.range(1, 10).asDoubleStream() would have to be changed to account for DISTINCTness, of course. Regards, Stefan 2016-04-01 18:25 GMT+02:00 Tagir F. Valeev : > Hello! > > Please review and sponsor the following patch: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ > > The patch preserves more characteristics on primitive stream > operations: > IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT > IntStream.asLongStream() preserves SORTED and DISTINCT > IntStream.asDoubleStream() and LongStream.asDoubleStream() preserves SORTED > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > > Fixing the boxed() case is especially important as distinct() for > primitive streams is implemented like boxed().distinct().unbox, so the > actual distinct() operation cannot take the advantage of DISTINCT flag > (skip the operation at all) or SORTED flag (switch to more efficient > implementation). > > Here's the small JMH benchmark which measures the performance boost of > quite common operation: sort the input numbers and leave only distinct > ones: > http://cr.openjdk.java.net/~tvaleev/webrev/8153293/jmh/ > > new Random(1).ints(size).sorted().distinct().toArray() > > I've got the following results. > > 9ea+111: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,612 ? 0,004 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 92,848 ? 1,039 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 32147,205 ? 3487,422 us/op > > 9ea+111 patched: > > Benchmark (size) Mode Cnt Score Error Units > SortDistinctTest.sortedDistinct 10 avgt 30 0,435 ? 0,001 us/op > SortDistinctTest.sortedDistinct 1000 avgt 30 40,555 ? 0,772 us/op > SortDistinctTest.sortedDistinct 100000 avgt 30 9031,651 ? 73,956 us/op > > With best regards, > Tagir Valeev. > From paul.sandoz at oracle.com Thu Apr 7 15:29:55 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Apr 2016 17:29:55 +0200 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: References: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> <18424863-8530-47E3-9529-DA8EE8229557@oracle.com> Message-ID: <0B4F368A-5DFB-40FB-88F0-3B36803DECCE@oracle.com> > On 7 Apr 2016, at 16:55, Martin Buchholz wrote: > > On Thu, Apr 7, 2016 at 6:17 AM, Paul Sandoz wrote: >> >>> On 6 Apr 2016, at 22:17, Martin Buchholz wrote: > >> Looks good. >> >> Regarding CompletableFutureTest.testManyDependents i presume that kind of test was not failing before the modifications to CompletableFuture? > > Right - technically it was not failing before, but the O(N^2) > performance in case of regression would be noticed quickly. And it > seems like a generally useful test. > Yes, no disagreement. >> >> I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent?s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in theory that test should run more efficiently? > > It's not useful to clean the stack of a future that has completed > because all of its dependents will be triggered anyways, so there's no > risk of garbage accumulation. But jsr166 CVS already has followon > changes in this area that are not part of this integration. I was looking at those trying to understand where things are going. Current webrev is fine. Thanks, Paul. From dl at cs.oswego.edu Thu Apr 7 15:39:05 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 7 Apr 2016 11:39:05 -0400 Subject: RFR: jsr166 jdk9 integration wave 6 In-Reply-To: <0B4F368A-5DFB-40FB-88F0-3B36803DECCE@oracle.com> References: <8A4AA663-C714-4460-AE0B-C199C51104B5@oracle.com> <18424863-8530-47E3-9529-DA8EE8229557@oracle.com> <0B4F368A-5DFB-40FB-88F0-3B36803DECCE@oracle.com> Message-ID: <57067F19.3050605@cs.oswego.edu> On 04/07/2016 11:29 AM, Paul Sandoz wrote: >>> >>> I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent?s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in theory that test should run more efficiently? >> >> It's not useful to clean the stack of a future that has completed >> because all of its dependents will be triggered anyways, so there's no >> risk of garbage accumulation. But jsr166 CVS already has followon >> changes in this area that are not part of this integration. > > I was looking at those trying to understand where things are going. > > Current webrev is fine. > Thanks for looking at these! We've been diagnosing and addressing various (potential) CompletableFuture performance issues, as they are used increasingly often. Some of the changes in jsr166 CVS aren't yet evaluated enough to commit to though. -Doug From chris.hegarty at oracle.com Thu Apr 7 17:14:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Apr 2016 18:14:56 +0100 Subject: RFR [9] 8153737: Unsupported Module Message-ID: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized ). The jdk.unsupported module will be present in full JRE and JDK images. http://cr.openjdk.java.net/~chegar/8153737/ https://bugs.openjdk.java.net/browse/JDK-8153737 Summary of the changes: - Restructure, what remains of, the sources in sun/misc to reflect the new modular layout. There are still a few non-Critical APIs in sun.misc that will be addressed later. - Add dependencies from several JDK modules to jdk.unsupported. All dependencies have issues tracking them, and should be removed in 9. - The test library in the top-level repo provides a convenience to tests to retrieve Unsafe. This has been updated to the "real" internal Unsafe, so there are many many tests that require to be updated, mostly the @modules tags. ( The Unsafe dependency in the library should probably be revisited at some point, as it requires many tests, not wishing to use Unsafe, to require an explicit dependency on it ) Note: with recent work from Mikael [2], sun.misc.Unsafe is now just a delegate for the "real" internal Unsafe, so it is time to move the tests to use it directly. - Cleanup any tests unnecessarily/incorrectly declaring a dependency on sun.misc ( this could have been unnecessarily added, been refactored out at one point, or the library upon which the tests depends refactored, that the dependency is no longer required ). I'm sure further cleanup could be done, but this is sufficient for now. - A small number of test in hotspot/test/compiler/unsafe, which are generated, have been updated, along with the generation script, to depend on jdk.unsupported/sun.misc ( they explicitly test the sun.misc version ) All 'core', 'pit', and 'hotspot' testsets have been successfully run on Mac, Linux, Windows, and Solaris. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8149159 From Alan.Bateman at oracle.com Thu Apr 7 18:57:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Apr 2016 19:57:24 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <5706AD94.8030701@oracle.com> On 07/04/2016 18:14, Chris Hegarty wrote: > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ It's great to get to this milestone. I looked over the webrev and I don't see any issues. I'm surprised by the number of tests that had @modules java.base/sun.misc even though they aren't using anything in sun.misc. I see Phil has pushed JDK-8147544 to jdk9/client rather than jdk9/dev so it means that the module-info.java for java.desktop will need to be fixed up when it gets to jdk9/dev. I think we should bump the priority of all the issues that cause you to add `requires jdk.unsupported`we should at least get all of them resolved by FC as we shouldn't have any standard modules with this dependence. -Alan. From christoph.langer at sap.com Thu Apr 7 20:45:15 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Apr 2016 20:45:15 +0000 Subject: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place Message-ID: <69c224ec9bbb4adaac47eee7917255ca@DEWDFE13DE11.global.corp.sap> Hi, I've run into a peculiar issue with Xerces. The problem is happening when a DTD shall be skipped, the DTD is larger than the buffer of the current entity and a CRLF sequence occurs just one char before the buffer end. The reason is that method skipDTD of class XMLDTDScannerImpl (about line 389) calls XMLEntityScanner.scanData() to scan for the next occurrence of ']'. The scanData method might return true which indicates that the delimiter ']' was not found yet and more data is to scan. Other users of scanData would handle this and call this method in a loop until it returns false or some other condition happens. So I've fixed that place like at the other callers of scanData. Nevertheless, the scanData method would usually load more data when it is at the end of the buffer. But in the special case when CRLF is found at the end of buffer - 1, scanData would just return true. So I also removed that check at line 1374 in XMLEntityScanner. Do you see any problem with that? Is there any reason behind it which I'm overseeing? Furthermore I took the chance for further little cleanups. I've added the new copyright header to the files... is that the correct one? I also aligned the calls to invokeListeners(position) in XMLEntityScanner to always pass the actual position from which the load is started. Do you think this is correct? Here is the bug: https://bugs.openjdk.java.net/browse/JDK-8153781 Here is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8153781.0/ Please give me some comments before I finalize my change including a jtreg testcase. Thanks & Best regards Christoph From steve.dohrmann at intel.com Thu Apr 7 22:03:11 2016 From: steve.dohrmann at intel.com (Dohrmann, Steve) Date: Thu, 7 Apr 2016 22:03:11 +0000 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> Message-ID: <7809D2A6-9665-458F-B9DB-37A3FD1451EB@intel.com> Hi Paul, We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9. As you suggest, we will participate in the Panama discussions in this area. Any additional guidance you have would be appreciated. Just to clarify, it is incidental that the proposed Memory interface has only one method. We see the value of the interface as nominative; a new type that can be passed around to abstract various sources of ByteBuffer memory. Regarding construction and allocation, our current Memory implementation allocates ByteBuffers by calling the NewDirectByteBuffer JNI function with a pointer to 3D XPoint memory allocated via a supporting native library. The Linux libraries we have worked with are NVML (https://github.com/pmem/nvml/) and memkind (https://github.com/memkind/memkind). We recently also became aware of the NVM-Direct library (https://github.com/oracle/NVM-Direct). We currently don't need our own subclass and return the ByteBuffer returned by the JNI call. Thanks, Steve On Apr 6, 2016, at 4:10 AM, Paul Sandoz > wrote: Hi Steve, My feeling is it?s too premature to introduce a general Memory (region) allocation interface at this moment. What is currently specified can be supported using: IntFunction But i don?t wanna discourage you! this thread has raised some interesting points. Project Panama is gonna take a swing at defining a more general notion of a memory region and the Arrays 2.0 work should support indexes greater than Integer.MAX_VALUE. In this respect I think we should hold off doing anything premature for Java 9 (feature freeze is getting closer), and i encourage you to participate on the Panama lists. ? Here is some context some of which you probably know and some which you might not: - ByteBuffer constructors are deliberately package scoped, as there are some intricate dependencies between the implementations and we want control over who can implement. Any new form of allocation will require changes here (package scoped or otherwise). - current ByteBuffer implementations are either backed by a byte[] (managed or non-direct) or an off-heap allocated (direct) region. At the moment access to both those regions go through separate code paths, but they could be unified using the Unsafe double addressing mode, which should greatly simplify the implementations. I have started making some small steps towards that (JDK-8149469 and JDK-8151163). Even these small steps require careful analysis to evaluate performance across multiple platforms. - VarHandles leverages the Unsafe double addressing mode to support enhanced atomic access to heap or direct ByteBuffers [1], thus the same code is used in both kinds of buffer. ? I am not sure what plans you have for buffer implementations themselves. How do you propose to allocate a ByteBuffer instance that covers a region of 3D XPoint memory? Would it be similar to that of direct buffers, e.g. a variation of DirectByteBuffer, but with different factory constructor code to allocate the memory region within the XPoint memory system and assign the buffer base address to the start of that allocated region? Thanks, Paul. [1] http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class, boolean) On 6 Apr 2016, at 03:49, Dohrmann, Steve > wrote: Re: JDK-8153111 Hi, Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. One motivation we saw for doing anything beyond a concrete ByteBuffer class was application code (e.g. Cassandra) that allocates many off-heap ByteBuffers using ByteBuffer#allocateDirect. We reasoned that if the allocation of ByteBuffers could be done using a common memory interface then only the code that provisioned instances of the the memory spaces would have to change in order to switch or mix memory types. We did think of overloading the ByteBuffer#allocateDirect method with memory space info and avoid an allocation interface. We ended up with a separate user called interface scheme because we imagined that extensions of the memory interface would enable new memory functionality that required new methods (e.g. memory transactions for persistence). Without a separate callable interface, the static method space in ByteBuffer might have to change again. For any API In general we saw the need for two things 1) something to represent a memory space from which objects are allocated (a Memory instance) and 2) a broadly usable familiar "anchor" type as the common data object (java.nio.ByteBuffer). The two points for extension with the current proposal are: 1) Constructors on Memory implementation classes -- allow implementors the ability to offer features on the memory space itself (e.g. partitioning, size limits) and 2) future extensions on the Memory interface -- for example PersistentMemory. Regarding a more elaborate scheme for memory space creation -- we did consider a factory scheme for memory object allocation but could not get comfortable with either a) standardized method signatures suitable for various kinds of memory or b) the complexity that something like a general-purpose "spec" format would add, even if we could come up with it. Direct construction does expose more to the user but it seems sufficient and might be the best given what we can say about the future of heterogeneous memory at this point. Regarding the suggested addition of keyed access to ByteBuffers, we are assuming this is only proposed to enable sharing? We thought it might take a while to properly explore the details (i.e. semantics / thread safety / predicable performance) of sharing such that it would work well and maybe even extend well to things like process-shared and cluster-shared ByteBuffers. We elected to propose nothing for JDK 9 beyond what developers can already do with schemes based on e.g. ByteBuffer#duplicate. We were thinking shared buffers could appear later, possibly as an extension of the Memory interface. The keyed access scheme is simple and appealing, however. One question: how is the request method's size parameter to be interpreted? The suggestion of parameterizing the Memory interface bounded by ByteBuffers seems useful as it gives a clean way to support extended ByteBuffers. Not sure if the change of the allocation method name from #allocateByteBuffer to #allocate was incidental or not? Alternates to the "Memory" interface name might be preferred, BufferSupplier is certainly reasonable. We imagined instances that name different memory spaces (e.g. OffHeapRAM) for allocation rather that the role played -- thinking the role is explicit in the allocation method name (allocateByteBuffer). Regarding changing the allocation size parameter to a long, this would be very nice to have. We avoided it in order to match the existing ByteBuffer API. If 64-bit ByteBuffers are planned, sticking with int sizes might have been the wrong call. We are still coming up to speed on VarHandles (JEP 193), atomics for ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827). We hope there is continued interest in this proposal and happy to provide a modified patch. Best regards, Steve Dohrmann From brent.christian at oracle.com Thu Apr 7 23:33:52 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 07 Apr 2016 16:33:52 -0700 Subject: RFR 8153123 : Streamline StackWalker code In-Reply-To: <57064352.5010800@oracle.com> References: <5702FC9B.7020600@oracle.com> <57064352.5010800@oracle.com> Message-ID: <5706EE60.3010901@oracle.com> Hi, Daniel On 04/07/2016 04:24 AM, Daniel Fuchs wrote: > > In > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html > > 548 objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames)); > 549 objArrayHandle frames_array_h(THREAD, fa); > 550 > 551 int limit = start_index + frame_count; > 552 if (frames_array_h.is_null()) { > 553 THROW_MSG_(vmSymbols::java_lang_IllegalArgumentException(), > "parameters and mode mismatch", NULL); > 554 } > > Can frames_array_h.is_null() ever be true, given that we used > JNIHandles::resolve_non_null(frames) at line 548? No! As you point out, it will assert out at 548. > I wonder if lines 552-554 are a remnant of the previous > implementation and could be removed now... You're absolutely right. > 589 Handle stack_frame_info(THREAD, JNIHandles::resolve(frame)); > 590 Handle stack_trace_element(THREAD, JNIHandles::resolve(stack)); > > Should these call JNIHandles::resolve_non_null instead? Yes! > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/jdk/src/java.base/share/classes/java/lang/StackFrameInfo.java.frames.html > > I'd be very tempted to make 'ste' private volatile. Sounds good to me. Thank you for having a look. I will send: http://cr.openjdk.java.net/~bchristi/8153123/webrev.02/ to hs-rt shortly. -Brent > On 05/04/16 01:45, Brent Christian wrote: >> Hi, >> >> I'd like to check in some footprint and code reduction changes to the >> java.lang.StackWalker implementation. >> >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8153123 >> >> A summary of the changes: >> >> * remove the "stackwalk.newThrowable" system property and >> "MemberNameInStackFrame" VM flag, originally left in to aid benchmarking >> >> * Streamline StackFrameInfo fields >> >> * Refactor/streamline StackStreamFactory (no more separate >> classes[]/StackFrame[] arrays, remove unneeded (for now) >> StackStreamFactory.StackTrace class) >> >> >> Given the hotspot changes, I plan to push this through hs-rt. >> >> Thanks, >> -Brent >> > From steve.drach at oracle.com Fri Apr 8 01:57:16 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 7 Apr 2016 18:57:16 -0700 Subject: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value Message-ID: <9765B51F-66C8-4273-8166-2AFB56BE9786@oracle.com> I?ve put up a new webrev that addresses the issue of having spaces before (and after) the value ?true? in the Multi-Release attribute. > Hi, > Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of ?true" in order to be effective, i.e. to assert the jar is a multi-release jar. > issue: https://bugs.openjdk.java.net/browse/JDK-8153213 > webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html > Thanks > Steve From mandy.chung at oracle.com Fri Apr 8 02:52:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Apr 2016 19:52:03 -0700 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> > On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 I?m glad to see jdk.unsupported module be created. jdeps tests are intended to test references to sun.misc and flagged as internal API. The jdeps test changes should be reverted. It?s exported to allow existing applications to continue to run on JDK 9 while sun.misc and other critical internal APIs remains to be internal APIs. jdeps -jdkinternals should flag them and get developers? attention to prepare to migrate when the replacements are available. Other than that, looks good. There are so many tests that have @modules java.base sun/misc but unused. It?s good that you clean that up. I agree with Alan that JDK modules depending on jdk.unsupported should get the priority to get eliminated by FC. thanks Mandy From paul.sandoz at oracle.com Fri Apr 8 07:41:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 09:41:30 +0200 Subject: RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value In-Reply-To: <9765B51F-66C8-4273-8166-2AFB56BE9786@oracle.com> References: <9765B51F-66C8-4273-8166-2AFB56BE9786@oracle.com> Message-ID: Hi Steve, > On 8 Apr 2016, at 03:57, Steve Drach wrote: > > I?ve put up a new webrev that addresses the issue of having spaces before (and after) the value ?true? in the Multi-Release attribute. > Is some or all of that really necessary? since the we can specify domain of values. For example, the Sealed attribute can take on a value of ?true? or ?false? (case ignored), but there is no white space trimming. Paul. >> Hi, >> Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of ?true" in order to be effective, i.e. to assert the jar is a multi-release jar. >> issue: https://bugs.openjdk.java.net/browse/JDK-8153213 >> webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html >> Thanks >> Steve From paul.sandoz at oracle.com Fri Apr 8 08:41:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 10:41:47 +0200 Subject: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory In-Reply-To: <7809D2A6-9665-458F-B9DB-37A3FD1451EB@intel.com> References: <484C3956-9D94-4686-BDDE-03F821D58A33@intel.com> <7809D2A6-9665-458F-B9DB-37A3FD1451EB@intel.com> Message-ID: <5B9F9ACA-BCA9-455A-9EA5-59ECEFBFAF7F@oracle.com> Hi Steve, > On 8 Apr 2016, at 00:03, Dohrmann, Steve wrote: > > Hi Paul, > > We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9. As you suggest, we will participate in the Panama discussions in this area. Any additional guidance you have would be appreciated. > e.g. clone/build the panama forest, join the pamana-dev email list, and start asking questions :-) I can send you links etc. off-line if need be. > Just to clarify, it is incidental that the proposed Memory interface has only one method. We see the value of the interface as nominative; a new type that can be passed around to abstract various sources of ByteBuffer memory. > I suspected as much, but would prefer that we gain more experience on what this interface should be, and how it intersects with other efforts, rather than introducing a skeletal version now. I suppose it?s possible for such an interface to extend from IntFunction for compatibility if existing 8 or 9 dependent libraries use IntFunction for abstracting buffer allocation. FWIW at one point i did postulate and prototyped a MemoryRegion class but after some thought and feedback made a hasty retreat :-) > Regarding construction and allocation, our current Memory implementation allocates ByteBuffers by calling the NewDirectByteBuffer JNI function with a pointer to 3D XPoint memory allocated via a supporting native library. Ok, that?s what we thought when some of us had an off-line discussion about this. It slots in quite nicely, and can be easily abstracted by IntFunction i.e. i don?t think there is anything fundamentally stopping you providing something that would work on Java 8 or 9. Is there any documentation on the memory ordering properties of 3D XPoint memory? how would it differ from say normal memory? can one access the memory using AVX instructions? does it support unaligned loads/stores? (i am guessing the latter is yes). (Separately there is also the question of whether this kind of memory is something HotSpot itself could leverage.) > The Linux libraries we have worked with are NVML (https://github.com/pmem/nvml/) and memkind (https://github.com/memkind/memkind). We recently also became aware of the NVM-Direct library (https://github.com/oracle/NVM-Direct). So do you create JNI bindings to NVML? Opportunistically perhaps this is also somewhere Panama might be able to help with, since it will provide good improvements over the current JNI experience. Paul. > We currently don't need our own subclass and return the ByteBuffer returned by the JNI call. > > Thanks, > Steve > From paul.sandoz at oracle.com Fri Apr 8 09:56:05 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 11:56:05 +0200 Subject: RFR 8151706: Update VarHandle implementation to use @Stable arrays Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/webrev/ Now that @Stable arrays are supported by C1 (thanks Vladimir!) we can switch from the explicit use of MemberName fields in VarForm to a @Stable MemberName[] array. I also took the opportunity to simplify the linking from a VarHandle impl to MemberName[] array, now that the implementation has settled down. This will reduce initialization costs and memory churn. I held off making further improvements for now. For example, VarForm can probably go away (also removing the dependency on ClassValue). A VarHandle instance can directly hold a MemberName[] array whose source reference is statically held on the associated VarHandle implementation. It should also be possible to lazily create MemberName instances as required, rather than aggressively doing so, which may further reduce initialization costs and memory usage in common cases. Paul. From paul.sandoz at oracle.com Fri Apr 8 10:24:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 12:24:08 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: > On 7 Apr 2016, at 19:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > And in the modular world it?s necessary to explicitly declare a requirement on idk.unsupported. > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 > +1 An important milestone. Paul. From amy.lu at oracle.com Fri Apr 8 10:40:25 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 8 Apr 2016 18:40:25 +0800 Subject: JDK 9 RFR of JDK-8153722: Mark java/nio/channels/Selector/SelectAndClose.java as intermittently failing Message-ID: <57078A99.2000904@oracle.com> java/nio/channels/Selector/SelectAndClose.java This test is known to fail intermittently (JDK-8152814). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8153722 webrev: http://cr.openjdk.java.net/~amlu/8153722/webrev.00/ Thanks, Amy --- old/test/java/nio/channels/Selector/SelectAndClose.java 2016-04-08 18:36:17.000000000 +0800 +++ new/test/java/nio/channels/Selector/SelectAndClose.java 2016-04-08 18:36:17.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,6 +23,7 @@ /* @test * @bug 5004077 + * @key intermittent * @summary Check blocking of select and close */ From peter.levart at gmail.com Fri Apr 8 10:41:01 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 8 Apr 2016 12:41:01 +0200 Subject: RFR: JDK-8152115 (proxy) Examine performance of dynamic proxy creation Message-ID: <57078ABD.2020906@gmail.com> Hi, With Mandy we have prepared the following patch to restore performance of java.lanf.reflect.Proxy class caching that has regressed with introduction of additional checks that have to be performed due to modules: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/webrev.05/ Jigsaw changed caching of proxy classes from ClassLoader+interfaces to Module+interfaces to accommodate possible future extension of the API that might take given Module as a parameter. Additional validation of constraints and derivation of dynamic module to host proxy class was performed on the fast path, degrading performance. This change restores the caching back to ClassLoader+interfaces, but also introduces new caching mechanism that allows simple derivation of other coexisting caching schemes that can support possible additions to the Proxy API. The new mechanism also simplifies caching by avoiding the need to reference ClassLoader and interfaces through WeakReference objects. Instead it uses a single ConcurrentHashMap per ClassLoader instance referenced directly from ClassLoader object. The caching API - ClassLoaderValue - is general enough to be used for other purposes where caching per ClassLoader is desired. Currently it is encapsulated as a java.lang.reflect package-private API, but could simply be promoted to a public API in an internal concealed package if desired. Performance of Proxy class caching is back to pre-jigsaw state and even better: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/ProxyBench.java @Mandy I haven't yet removed the superfluous checking and providing access from dynamic module to the modules/packages of transitive closure of interfaces implemented by proxy class. I think this should be done in a separate issue so that this change doesn't change the semantics of implementation. Regards, Peter From kubota.yuji at gmail.com Fri Apr 8 11:04:49 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Fri, 8 Apr 2016 20:04:49 +0900 Subject: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries In-Reply-To: <56F9A4F4.6040108@oracle.com> References: <56F9A4F4.6040108@oracle.com> Message-ID: Hi Sherman and all, Thank you for all comments about this proposal! Thank Tomoyuki and Stephen for sharing your needs. Thank Bernd for sharing your information. However, I am afraid that AE1 and AE2 may have a risk of patent issue, while "Traditional PKWare encryption" is explicitly free from the risk according to the PKWare documents. Therefore, I think this proposed implementation to support legacy zip specification is meaningful as Tomoyuki said. We got some positive opinions / needs. I am glad if you consider the proposal acceptable for JDK. If this proposed implementation is acceptable, I and Yasumasa will improve it by corresponding to comments which given by Sherman and Stephen. Thanks! Yuji 2016-03-29 6:41 GMT+09:00 Xueming Shen : > Yasumasa > > It's a tricky call. To be honest, as I said at the very beginning, I'm not > sure whether > or not it's a good idea and worth the efffort to push this into the j.u.zip > package to > support the "traditional PKWare encryption", which is known to be "seriously > flawed, > and in particular is vulnerable to known-plaintext attacks" (from wiki), > while I fully > understood it is not a concern in your "problem-free" use scenario. Just > wonder > if there is anyone else on the list that has/had the need for such > encryption feature > in the past. It would be preferred to have more input (agree, disagree) to > make the > final decision. > > Here are some comments regarding the proposed implementation, > > (1) The changes in native code are probably no longer needed. The native > path is > left there for vm directly access. > (2) I'm concerned about the footprint increase for the ZipEntry class (the > proposed > change is adding 3 more fields into the entry class). Given this is > something rarely > needed/used, and we might have hundreds and thousands of zip/jar > entries during > startup/runtime, it might be desired to avoid adding these fields into > ZipEntry class. > A possible alternative to have a dedicated entry class extended from > the ZipEntry > to hold those extra fields and methods, EncryptionZipEntry for example. > So the > proposed encryption support code will not have any impact to the > existing use of > ZipInput/OutputStream/File. > (3) I'm also not comfortable to add the "encryption engine" logic into the > in/deflater > stream classes, while it might be convenient to do so from > implementation point > of view. Given the encryption is something between the raw bites in the > zip file > and the in/deflating layer, it might need an extra layer there, though > I'm not sure > if it's easy to do so. > > The webrev below is what I think might be better for the ZipFile and > ZipOutputStream > to have an extra layer in between to handle the encryption. Not try to test > if it really > works, just throw in the idea for discussion. > > http://cr.openjdk.java.net/~sherman/zencrypt/webrev/ > > No, I did not try the ZIS, the "pushback" stream there might be a little > tricky:-) > > -Sherman > > > On 03/28/2016 02:34 AM, Yasumasa Suenaga wrote: >> >> PING: Could you review it? >> We want to move forward this enhancement. >> >> Thanks, >> >> Yasumasa >> 2016/03/19 22:01 "Yasumasa Suenaga": >> >>> Hi Alan, >>> >>>> I think the main issue here is to decide whether the API >>>> should be extended for encryption or not. >>> >>> We've discussed on the premise that we add the API for supporting ZIP >>> encryption. >>> In this context, Sherman tried to implement AES encryption extending >>> current API. [1] >>> >>> IMHO, ZIP encryption should be implemented as extention of current ZIP >>> API >>> because encryption/decryption will process for each ZIP entries. >>> >>> According to Developers' Guide, guideline for adding new API is TBD. [2] >>> What should I do next? >>> >>> >>> Thanks, >>> >>> Yasumsa >>> >>> >>> [1] >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037903.html >>> [2] http://openjdk.java.net/guide/changePlanning.html#api >>> >>> >>> On 2016/03/19 0:25, Alan Bateman wrote: >>>> >>>> On 18/03/2016 15:02, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We (including me and Yuji Kubota (ykubota: OpenJDK jdk9 Author)) >>> >>> discussed >>>>> >>>>> about this issue from Nov. 2015. [1] >>>>> We heard several comments and we applied them to our patch. >>>>> >>>>> I have not heard new comment for our latest patch. >>>>> So I send review request for it. Could you review it? >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/ >>>>> >>>>> Usage of new API: >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java >>>> >>>> Yasumasa - I think the main issue here is to decide whether the API >>>> should be extended for encryption or not. If exposing it in the API make >>>> sense then I assume that alternative names to java.util.zip.ZipCryption >>>> needs to be explored. >>>> >>>> -Alan. >>>> > From paul.sandoz at oracle.com Fri Apr 8 12:51:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 14:51:14 +0200 Subject: RFR 8151198: VarHandle factory-specific exceptions Message-ID: <42A7827C-7C5E-4EF1-993F-E0CEF2A99DC2@oracle.com> Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151198-VH-factory-exceptions/webrev/ The patch tweaks the specification: 1) noting that factory methods may document additional undeclared exceptions that may be thrown by access methods e.g. IllegalSateException for VarHandles to ByteBuffer for misaligned access. 2) add the throwing of ClassCastException to each method, which i neglected to add when switching from invokeExact to invoke semantics. Paul. From michael.haupt at oracle.com Fri Apr 8 13:37:10 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 8 Apr 2016 15:37:10 +0200 Subject: RFR 8152645 VarHandle lookup access control tests In-Reply-To: <81AC210F-C0C7-4DAA-BAA9-FCCCF89699FB@oracle.com> References: <81AC210F-C0C7-4DAA-BAA9-FCCCF89699FB@oracle.com> Message-ID: