April 2016 - core-libs-dev

toRealPath throws InternalError: Should not get here on Windows (paths with junctions)
by Dawid Weiss 05 Apr '16

05 Apr '16

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) at sun.nio.fs.WindowsLinkSupport.getFinalPath(Unknown Source) at sun.nio.fs.WindowsLinkSupport.getRealPath(Unknown Source) at sun.nio.fs.WindowsPath.toRealPath(Unknown Source) at sun.nio.fs.WindowsPath.toRealPath(Unknown Source) Is this just me? :) Dawid

3 7

RFR: 8153317: Two jimage tests have been failing since JDK-8152641 was fixed
by Claes Redestad 04 Apr '16

04 Apr '16

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

3 3

RFR [9] 8153181: Examine sun.misc.VMSupport
by Chris Hegarty 04 Apr '16

04 Apr '16

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.

3 6

RFR: 8153332 - Stream API: Fuse sorted().limit(n) into single operation
by Tagir F. Valeev 02 Apr '16

02 Apr '16

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.

1 0

https://bugs.openjdk.java.net/browse/JI-9032379
by Abhijit Roy 02 Apr '16

02 Apr '16

Hi, Need some suggestion for this issue (2nd part). Thanks Abhijit

1 1

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory
by Dohrmann, Steve 01 Apr '16

01 Apr '16

Hi everyone, The questions and suggestions regarding this proposal (JDK-8153111<https://bugs.openjdk.java.net/browse/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<https://bugs.openjdk.java.net/browse/JDK-8008240>) and ByteBuffer consistency (JDK-6476827<https://bugs.openjdk.java.net/browse/JDK-6476827>) in the context of this proposal 9. Connection between this proposal and VarHandles Best regards, Steve Dohrmann

1 0

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value
by Steve Drach 01 Apr '16

01 Apr '16

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 <https://bugs.openjdk.java.net/browse/JDK-8153213> webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8153213/webrev/index.html> Thanks Steve

2 1

JDK 9 proposal: allocating ByteBuffers on heterogeneous memory
by Dohrmann, Steve 01 Apr '16

01 Apr '16

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

10 12

RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time
by Claes Redestad 01 Apr '16

01 Apr '16

Hi, please review this patch which add an enabled-by-default plugin to generate a configurable list of BoundMethodHandle$Species_*-classes using jlink. Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ This plugin adds the --generate-bmh flag to jlink, which takes a comma-separated list of shortened species type strings. As an example: --generate-bmh LL,L3,L4 will generate BoundMethodHandle$Species_LL, ...$Species_L3 and ...$Species_L4 and add them to the java.base module. The Species class lookup in BoundMethodHandle will first check if there is a generated class, otherwise generate it as previously. Adding an exceptional path might seem problematic, but as the code generation is magnitudes more expensive than the exception it doesn't seem fruitful to go to lengths to avoid the CNFE. More notes along with some results can be found here: http://cr.openjdk.java.net/~redestad/scratch/bmh_species_gen.txt Thanks! /Claes

7 25

RFR: 8153262: javax/xml/bind/marshal/8134111/UnmarshalTest.java fails
by Aleksej Efimov 01 Apr '16

01 Apr '16

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

3 2