Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

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?

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

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

AW: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

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

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

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

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

> On Mar 31, 2016, at 4:10 PM, Mandy Chung wrote: > > >> On Mar 30, 2016, at 9:17 AM, Claes Redestad >> wrote: >> >> Hi Peter, >> >> something like this, then: >> >> http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ >> > >

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

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

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

> On Mar 30, 2016, at 9:17 AM, Claes Redestad wrote: > > Hi Peter, > > something like this, then: > > http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ > BoundMethodHandle::generateConcreteBMHClassBytes It only allows “LIJFD” characters. But the default

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

> On Mar 29, 2016, at 4:03 PM, Claes Redestad wrote: > > Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere) which > has to be updated when adding a plugin like this. jdk/test/tools/jlink/JLinkTest.java This is the one I recalled. This is in

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

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Roger, On 03/31/2016 09:12 PM, Roger Riggs wrote: Hi Peter, It would be simpler to understand the changes if we solve the problems one at a time, at least for review purposes. Right. We can focus on one aspect at a time, but I'm still trying to keep the whole thing in a working

Re: RFR: 8134111: Unmarshaller unmarshalls XML element which doesn't have the expected namespace

Changes for 9 and 8u look fine > On Mar 31, 2016, at 3:39 PM, Aleksej Efimov wrote: > > Hi, > > Please, help to review the fix for JDK-8134111 [1]. This bug was already > resolved in standalone JAXB project and was integrated to JDK9 as part of > JAXWS/B sync

RFR: 8134111: Unmarshaller unmarshalls XML element which doesn't have the expected namespace

Hi, Please, help to review the fix for JDK-8134111 [1]. This bug was already resolved in standalone JAXB project and was integrated to JDK9 as part of JAXWS/B sync process [2]. The changes that fixed the incorrect unmarshalling behavior are located in StructureLoader class [3]. JDK9 change

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, It would be simpler to understand the changes if we solve the problems one at a time, at least for review purposes. To your question in the 2nd part about the Cleaner. (webrev.11.part2) I don't think the communication between the memory reserving thread and the unreserving thread

Re: JAXP default implementation and JDK-8152063

On 3/31/2016 8:48 AM, mark.reinh...@oracle.com wrote: 2016/3/29 0:21:05 -0700, alan.bate...@oracle.com: On 28/03/2016 23:46, huizhe wang wrote: Thanks David. So I understand the dynamic nature of the server configuration. There maybe two options to solve it: ... 2) Add a new type

RFR [9] 8153181: Examine sun.misc.VMSupport

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

Re: JAXP default implementation and JDK-8152063

2016/3/29 0:21:05 -0700, alan.bate...@oracle.com: > On 28/03/2016 23:46, huizhe wang wrote: >> Thanks David. So I understand the dynamic nature of the server >> configuration. There maybe two options to solve it: >> >> ... >> >> 2) Add a new type FinderDelegate for processes such as the

Re: SPARC Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

> On 31 Mar 2016, at 09:40, Peter Levart wrote: > > > > On 03/31/2016 08:33 AM, John Rose wrote: >> On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote: >>> When access is performed in loops this can cost, as the alignment checks >>> are not

Re: SPARC Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

Hi John, Thanks for the thoughts and advice. At this point i plan to proceed with the current patch (i will add tests for buffer views), and then follow up more more analysis and recommendations for SPARC. The situation is a little murky after some further performance analysis, non-optimal

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

> On 31 Mar 2016, at 07:59, Ivan Gerasimov wrote: > >> I think they are important, more so the test update. >> >> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan >> are you ok with that? >> > > Sure! > Thanks. > Here's the webrev,

Re: SPARC Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

On 03/31/2016 08:33 AM, John Rose wrote: On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote: When access is performed in loops this can cost, as the alignment checks are not hoisted out. Theoretically could for regular 2, 4, 8 strides through the buffer contents. For

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Hi Claes, On 03/30/2016 06:17 PM, Claes Redestad wrote: Hi Peter, something like this, then: http://cr.openjdk.java.net/~redestad/8152641/webrev.05/ Perfect. - Added a method only used by the plugin which validates input; added a comment about the dependency - Invalid types are logged

Re: SPARC Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors

On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote: > > When access is performed in loops this can cost, as the alignment checks are > not hoisted out. Theoretically could for regular 2, 4, 8 strides through the > buffer contents. For such cases alignment of the base

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

I like it too. Reviewed. A couple of comments: The default list of species in the plugin (List.of("LL", "L3", … "I", "LLILL")) should be commented with information for maintainers to reproduce the procedure you used to generate that list. Otherwise the list is just magic, and unmaintainable.

Re: Review request 8153035: GenModuleInfoSource strips away the API

> On Mar 30, 2016, at 11:05 PM, Alan Bateman wrote: > > On 30/03/2016 20:09, Mandy Chung wrote: >> GenModuleInfoSource is a build tool that augments module-info.java with >> platform-specific declaration such as exports, uses and provides and >> generates the

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Looks good for me, thank you! With best regards, Tagir Valeev. >> I think they are important, more so the test update. >> >> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan >> are you ok with that? >> IG> Sure! IG> Here's the webrev, updated with those changes: IG>

Re: 8153118 Remove sun.misc.resources

On 30/03/2016 21:57, Mandy Chung wrote: On Mar 30, 2016, at 1:35 PM, Chris Hegarty wrote: sun.misc.resources claims to contain a ResourceBundle for sun.misc, which has localized versions of messages for "bad" jar files, such as: "optpkg.versionerror", "ERROR:

Re: Review request 8153035: GenModuleInfoSource strips away the API

On 30/03/2016 20:09, Mandy Chung wrote: GenModuleInfoSource is a build tool that augments module-info.java with platform-specific declaration such as exports, uses and provides and generates the resulting module-info.java in gensrc directory. This utility should really be a simple one that

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

I think they are important, more so the test update. If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan are you ok with that? Sure! Here's the webrev, updated with those changes: http://cr.openjdk.java.net/~igerasim/8079136/10/webrev/ With kind regards, Ivan