On 01/03/2019 11:05, Andrew Dinn wrote:
:
Having dealt with the above issues (including removing the isSync
method) I have reclassified the scope of the JEP to JDK.
I would like now to submit this JEP and begin review of the
implementation patches. In particular, I'd like to proceed with the
Hi Alan,
On 17/02/2019 17:37, Alan Bateman wrote:
> On 15/02/2019 17:13, Chris Hegarty wrote:
>> :
>> I see that there are changes to the Java SE Platform, namely to the
>> MapMode constructor and an overload of MappedByteBuffer::force. I see
>> these more as "enablers" in support of this feature
The latest JEP and draft implementation now address the 3 outstanding
issues:
1) 2-arg force method now uses integer start offset and length
force(int from, int length)
2) length is checked against buffer limit rather than capacity
3) start position and length checks are implemented using
On 20/02/2019 11:33, Andrew Haley wrote:
> On 2/20/19 11:28 AM, Andrew Dinn wrote:
>> So, in the next webrev when force() with no args is called on a non-SYNC
>> mode buffer I will ensure it continues to call
>>
>> force0(fd, mappingAddress(offset), mappingLength(offset))
>>
>> For a SYNC
On 2/20/19 11:28 AM, Andrew Dinn wrote:
> So, in the next webrev when force() with no args is called on a non-SYNC
> mode buffer I will ensure it continues to call
>
> force0(fd, mappingAddress(offset), mappingLength(offset))
>
> For a SYNC buffer I'll redirect to call
>
> force(0, limit())
On 20/02/2019 11:11, Alan Bateman wrote:
> On 19/02/2019 18:01, Andrew Dinn wrote:
>> :
>> My reason for using capacity() was that I was swayed by the original
>> implementation of force(). It calls
>>
>> force0(fd, mappingAddress(offset), mappingLength(offset))
>>
>> :
>>
>> I'm wondering if
On 19/02/2019 18:01, Andrew Dinn wrote:
:
My reason for using capacity() was that I was swayed by the original
implementation of force(). It calls
force0(fd, mappingAddress(offset), mappingLength(offset))
:
I'm wondering if this ought to remain as is or ought to change to
specify limit()?
Hi Alan,
Thanks for following this up.
On 19/02/2019 16:55, Alan Bateman wrote:
> The issues with the 2-arg force method that I think need discussion are:
>
> 1. long from/to vs. from/length vs int index/length. Elements in
> buffers, or the starting index of a region, are addressed by an int
On 18/02/2019 11:15, Andrew Dinn wrote:
:
Alan, I'll wait for your follow-up note before responding regarding the
arguments to force. I'll just note that the latest JEP draft accepts
start position and length [i.e. force(from, length)] rather than start
position and end position [i.e.
Hi Chris/Alan,
On 17/02/2019 17:37, Alan Bateman wrote:
> On 15/02/2019 17:13, Chris Hegarty wrote:
>> :
>> I see that there are changes to the Java SE Platform, namely to the
>> MapMode constructor and an overload of MappedByteBuffer::force. I see
>> these more as "enablers" in support of this
On 15/02/2019 17:13, Chris Hegarty wrote:
:
I see that there are changes to the Java SE Platform, namely to the
MapMode constructor and an overload of MappedByteBuffer::force. I see
these more as "enablers" in support of this feature ( rather than the
core of the feature itself ). They can
Hi Andrew,
> On 15 Feb 2019, at 16:51, Andrew Dinn wrote:
>
> The latest round of changes to the JEP and draft implementation are now
> available for review:
>
> JEP:http://openjdk.java.net/jeps/8207851
> webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/
I'm only following this
The latest round of changes to the JEP and draft implementation are now
available for review:
JEP:http://openjdk.java.net/jeps/8207851
webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/
Latest Changes:
After a very helpful discussion with Alan at FOSDEM I borrowed some
hints from him
; Jonathan Halliday
Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
non-volatile memory
On 28/01/2019 18:39, Viswanathan, Sandhya wrote:
> Hi Alan,
>
> Could you please let us know more on what does it mean to be a jdk-specific
> feature? How it is to be implemented
On 28/01/2019 18:39, Viswanathan, Sandhya wrote:
Hi Alan,
Could you please let us know more on what does it mean to be a jdk-specific
feature? How it is to be implemented? An example would be very helpful.
ByteBuffer is a widely used API and deprecating ByteBuffer any time would make
it
, Sandhya
Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
non-volatile memory
On 17/01/2019 14:27, Andrew Dinn wrote:
> :
>> Vladimir and I have reviewed the JEP, it will need an area lead to
>> endorse, I think it can be Brian or Mikael in this case.
> Ok, th
On 18/01/2019 14:28, Peter Levart wrote:
...unless you actually want users to construct their own MapMode(s),
like you mentioned is the case with FileChannel.open() and
FileAttribute interface. But there this makes sense because the
backend (FileSystem) is also pluggable, so users can define
> Hi Alan/Brian,
My apologies for having missed this the first time around; messages to lists
get swept into folders, and staying on top of many lists is not an exact
science.
> I believe I have addressed all outstanding comments on the JEP per se,
> including those made by Alan. Is it now
Hi Alan,
On 18/01/2019 13:32, Alan Bateman wrote:
> I had a brief discussion with Brian about this yesterday. He brought up
> the same concern about using MBB as it's not the right API for this in
> the longer term. So this JEP is very much about a short term/tactical
> solution as we've
On 1/18/19 3:11 PM, Peter Levart wrote:
You meant package-private constructor, right? Protected constructor
would allow subclassing MapMode by arbitrary user class which is not
what would be desirable.
...unless you actually want users to construct their own MapMode(s),
like you mentioned
Hi Alan,
On 1/18/19 2:32 PM, Alan Bateman wrote:
On 17/01/2019 14:27, Andrew Dinn wrote:
:
Vladimir and I have reviewed the JEP, it will need an area lead to
endorse, I think it can be Brian or Mikael in this case.
Ok, thanks for the above answers. Looking forward to hearing further
from
On 17/01/2019 14:27, Andrew Dinn wrote:
:
Vladimir and I have reviewed the JEP, it will need an area lead to
endorse, I think it can be Brian or Mikael in this case.
Ok, thanks for the above answers. Looking forward to hearing further
from Brian and/or Mikael (Vidstedt, I assume? :-).
I had a
y 17, 2019 6:28 AM
To: Alan Bateman ; Brian Goetz
Cc: core-libs-dev@openjdk.java.net; hotspot compiler
; Jonathan Halliday
; Viswanathan, Sandhya
; Mikael Vidstedt
Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
non-volatile memory
Hi Alan,
Thanks for your response.
On 17/0
Hi Alan,
Thanks for your response.
On 17/01/2019 12:53, Alan Bateman wrote:
> I skimmed through the current draft. In the most recent discussion then
> I think we had converged on "SYNC" rather than "PERSISTENT", the
> reasoning being that there is persistence already with regular file
> mapped
On 16/01/2019 11:23, Andrew Dinn wrote:
Hi Alan/Brian,
I have finally been able to shelve other commitments and return to this
JEP (apologies for the hiatus).
https://openjdk.java.net/jeps/8207851
The JEP has been reviewed positively by Stuart Marks (core libs) and
Vladimir Kozlov
Draft: Support ByteBuffer mapped over
non-volatile memory
Hi Alan/Brian,
I have finally been able to shelve other commitments and return to this JEP
(apologies for the hiatus).
https://openjdk.java.net/jeps/8207851
The JEP has been reviewed positively by Stuart Marks (core libs) and Vladimir
Hi Alan/Brian,
I have finally been able to shelve other commitments and return to this
JEP (apologies for the hiatus).
https://openjdk.java.net/jeps/8207851
The JEP has been reviewed positively by Stuart Marks (core libs) and
Vladimir Kozlov (intrinsics). It has also been warmly welcomed by
dk.java.net
> Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-
> volatile memory
>
> External Email
>
> Hi Derek,
>
> On 08/11/18 15:49, White, Derek wrote:
>
> > Given that there is platform-specific code, it would be good to be
&g
hotspot-compiler-
> d...@openjdk.java.net; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-
> volatile memory
>
> On 07/11/18 17:12, Vladimir Kozlov wrote:
> > I am Lead for Hotspot [1]. Alan is Group Lead for core libs and he
> &
On 11/9/18 9:01 AM, Andrew Dinn wrote:
Hi Vladimir,
On 08/11/18 18:07, Vladimir Kozlov wrote:
Thank you, Andrew, for sending changes
I am fine with intrinsics general wording in JEP. I 'reviewed' JEP.
Excellent. Thank you very much. On to the next step . . .
I have several questions and
Hi Vladimir,
On 08/11/18 18:07, Vladimir Kozlov wrote:
> Thank you, Andrew, for sending changes
>
> I am fine with intrinsics general wording in JEP. I 'reviewed' JEP.
Excellent. Thank you very much. On to the next step . . .
> I have several questions and issues with proposed changes in
Thank you, Andrew, for sending changes
I am fine with intrinsics general wording in JEP. I 'reviewed' JEP.
I have several questions and issues with proposed changes in Hotspot which needs to be discussed
during changes review. My main question is - should new nodes be treated as global memory
Hi Roger,
On 08/11/18 14:51, Roger Riggs wrote:
> If to achieve the performance or functional goals of the JEP hotspot
> changes are needed
> they should be mentioned (no details needed) in the JEP.
> It helps the reader understand the scope and impact of the change.
Thanks. I have added a brief
Hi Derek,
On 08/11/18 15:49, White, Derek wrote:
> Given that there is platform-specific code, it would be good to be
> clear which platforms you are intending to implement as part of this
> JEP, and which platforms will need others to step in to support.
>
> I'm quite happy with your plan, but
Hi Andrew,
If to achieve the performance or functional goals of the JEP hotspot
changes are needed
they should be mentioned (no details needed) in the JEP.
It helps the reader understand the scope and impact of the change.
Regards, Roger
On 11/08/2018 04:10 AM, Andrew Dinn wrote:
On
On 07/11/18 17:12, Vladimir Kozlov wrote:
> I am Lead for Hotspot [1]. Alan is Group Lead for core libs and he gave
> review already.
>
> I don't see any reference to Hotspot in JEP so I am not sure what to
> review. Do you need any new optimizations/intrinsics in Hotspot for this
> JEP?
Yes I
Hi Andrew,
I am Lead for Hotspot [1]. Alan is Group Lead for core libs and he gave review
already.
I don't see any reference to Hotspot in JEP so I am not sure what to review. Do you need any new
optimizations/intrinsics in Hotspot for this JEP?
You need to ask Alan or Brian Goetz (as Area
On 06/11/18 10:17, Andrew Dinn wrote:
> Ping!
>
> Is it possible to get a response on this.
>
> To summarise: I am happy to rename isPersistent to isSync and/or make it
> private as well as change the enum tags to use SYNC instyead of
> PERSISTENT if that is what is needed to get the JEP
Ping!
Is it possible to get a response on this.
To summarise: I am happy to rename isPersistent to isSync and/or make it
private as well as change the enum tags to use SYNC instyead of
PERSISTENT if that is what is needed to get the JEP approved.
I'd really like to see this progress towards a
Hi Alan,
Apologies for the 2 week+ delay in replying -- I was away on holiday.
On 03/10/18 15:24, Alan Bateman wrote:
> On 03/10/2018 10:14, Andrew Dinn wrote:
>> :
>> Sure, I'd be happy to change this.
>>
>> Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do
>> you have
On 03/10/2018 10:14, Andrew Dinn wrote:
:
Sure, I'd be happy to change this.
Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do
you have something else in mind?
I think that works but it means looking at the proposed
MappedByteBuffer::isPersistent too. MappedByteBuffer
On 30/09/18 16:31, Alan Bateman wrote:
> On 26/09/2018 14:27, Andrew Dinn wrote:
>> :
>> I'm not clear why we should only use one flag. The two flags I specified
>> reflect two independent use cases, one where data stored in an NVM
>> device is accessed read-only and another where it is accessed
Hi guys!
I'm one of the mentioned devs (like many others) that are using external
(and unsafe) APIs to concurrent access ByteBuffer's content and a developer
of a messaging broker's journal
that would benefit by this JEP :)
Re concurrent access API, how it looks
On 26/09/2018 14:27, Andrew Dinn wrote:
:
I'm not clear why we should only use one flag. The two flags I specified
reflect two independent use cases, one where data stored in an NVM
device is accessed read-only and another where it is accessed
read-write. Are you suggesting that the read-only
Hi Francesco,
Thanks for the pointer to AtomicBuffer stuff. It's quite interesting.
I don't know how directly relevant this JEP is your work. I guess that's really
up to you and possibly Andrew Dinn. However, in my thinking, if you have useful
comments and relevant questions, you're certainly
On 9/28/18 12:21 AM, Peter Levart wrote:
I mostly agree with your assessment about the suitability of the ByteBuffer API
for nice multithreaded use. What would such API look like? I think pretty much
like ByteBuffer but without things that mutate mark/position/limit/ByteOrder. A
On 9/28/18 2:16 AM, Andrew Dinn wrote:
Thanks for clarifying that point. I have already added a note to that
effect to the JEP. I take your other point that these limitations make
this JEP a less useful addition than it could be. However, it's hard to
see what else might usefully be provided
Hi Stuart,
On 28/09/18 06:51, Stuart Marks wrote:
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think
> the JEP should proceed forward using MBB with the API that you and Alan
> had discussed previously.
Hi Stuart,
I mostly agree with your assessment about the suitability of the
ByteBuffer API for nice multithreaded use. What would such API look
like? I think pretty much like ByteBuffer but without things that mutate
mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore.
Hi Andrew,
Let me first stay that this issue of "ByteBuffer might not be the right answer"
is something of a digression from the JEP discussion. I think the JEP should
proceed forward using MBB with the API that you and Alan had discussed
previously. At most, the discussion of the "right
Hi Peter,
On 27/09/18 11:28, Peter Levart wrote:
> May I just note that multithreaded bulk operations are kind of possible
> without external synchronization (i.e. locks) if you follow a simple
> protocol:
>
> - never use relative operations on the shared ByteBuffer instance
> - never use
Hi Andrew,
On 09/27/2018 11:23 AM, Andrew Dinn wrote:
On 26/09/18 17:00, Alan Bateman wrote:
The reason that we've mentioned it a few times is because it's a
significant issue. If you have a byte buffer then you can't have
different threads accessing different parts of the buffer at the same
On 26/09/18 17:00, Alan Bateman wrote:
> The reason that we've mentioned it a few times is because it's a
> significant issue. If you have a byte buffer then you can't have
> different threads accessing different parts of the buffer at the same
> time, at least not with any of the relative get/put
On 26/09/2018 14:27, Andrew Dinn wrote:
:
I really don't understand how thread safety comes into the argument
here. How is some other mechanism going to avoid the need for client
threads -- or, rather, the applications which create them them -- to
manage concurrent updates of NVM? Are you
Hi Andrew,
I've been starting to look at some of the buffer-related issues and I've been
discussing this issue with Alan.
On 9/25/18 2:01 AM, Andrew Haley wrote:
On 09/24/2018 09:14 AM, Alan Bateman wrote:
I'm not questioning the need to support NVM, instead I'm trying to
see whether
Hi Stuart,
On 26/09/18 03:19, Stuart Marks wrote:
> I've been starting to look at some of the buffer-related issues and I've
> been discussing this issue with Alan.
I'd be interested to hear more details if the discussion has gone far
enough for any of it to be aired online.
> On 9/25/18 2:01
, Vivek R
; Jonathan Halliday
Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
non-volatile memory
On 21/09/2018 16:44, Andrew Dinn wrote:
> Hi Alan,
>
> Thanks for the response and apologies for failing to notice you had
> posted it some days ago (doh!).
>
> Jon
On 09/26/2018 09:44 AM, Andrew Dinn wrote:
> As regards the latter issue, I am not really sure what you are
> suggesting would be a better alternative to using ByteBuffer get and put
> methods? Are you perhaps thinking of some way of overlaying a record (or
> object?) structure over the mapped
Hi Alan,
On 26/09/18 11:35, Alan Bateman wrote:
> I'm reasonably happy with the approach that we converged on to introduce
> new map modes and use the existing FileChannel.map method. Ideally new
> map modes wouldn't need to be exposed but you've looked into that (to my
> satisfaction at least).
On 26/09/2018 09:44, Andrew Dinn wrote:
:
If you (collectively) are aware of this and other limitations, then
sure, let's proceed with this JEP.
Well, I'm very happy to proceed if Alan is in agreement. One thing he
suggested in an earlier post was splitting off the functionality to
create a
On 09/24/2018 09:14 AM, Alan Bateman wrote:
> I'm not questioning the need to support NVM, instead I'm trying to
> see whether MappedByteBuffer is the right way to expose this in the
> standard API. Buffers were designed in JSR-51 with specific
> use-cases in mind but they are problematic for
On 21/09/2018 16:44, Andrew Dinn wrote:
Hi Alan,
Thanks for the response and apologies for failing to notice you had
posted it some days ago (doh!).
Jonathan Halliday has already explained how Red Hat might want to use
this API. Well, what he said, essentially! In particular, this model
Hi Alan,
Thanks for the response and apologies for failing to notice you had
posted it some days ago (doh!).
Jonathan Halliday has already explained how Red Hat might want to use
this API. Well, what he said, essentially! In particular, this model
provides a way of ensuring that raw byte data is
Hi Alan
I'm a middleware engineer (transaction engine, message queues, etc) and
I evolved the current API design whilst making some of Red Hat's Jakarta
EE stack work with persistent memory. It's a good fit for our needs
because it pretty much matches they way we currently do off-heap and
Ping!
Could I please get a review of this latest version of the JEP?
This includes responses to all previous comments with changes made both
to the JEP and the draft implementation.
I would like to get this into JDK12 if at all possible
regards,
Andrew Dinn
---
Senior Principal
On 20/08/2018 16:18, Andrew Dinn wrote:
Hi Alan,
Round 4:
I have redrafted the JEP and updated the implementation in the light of
your last feedback:
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev:
Hi Alan,
Round 4:
I have redrafted the JEP and updated the implementation in the light of
your last feedback:
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.04/
Hi Alan,
Just a quick follow-up regarding the BufferPoolMXBean.
On 14/08/18 12:34, Andrew Dinn wrote:
> On 06/08/18 10:29, Alan Bateman wrote:
>
>> Are you familiar with BufferPoolMXBean which can be used by management
>> tools to monitor pool of buffers? I'm wondering if we should introduce a
Hi Alan,
Thanks for looking at this and apologies for the delayed response (c/o
our annual Red Hat OpenJDK team meeting taking place all last week).
On 06/08/18 10:29, Alan Bateman wrote:
> The current iteration, to introduce new MapMode values, is not too bad
> but it makes me wonder if we
On 25/07/2018 12:44, Andrew Dinn wrote:
Round 2
---
I have updated the JEP and uploaded a revised webrev in the light of
existing feedback
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev:
Round 3:
This week Jonathan Halliday was able to access a machine which has both
an NVM DIMM and CPU that implements the clflush and clwb instructions.
He is currently preparing some benchmark figures for running
transactions using a log stored in NVM. However, in order to get to that
point we
Hi Vladimir,
Thank you for the very helpful explanation. I will happily wait for
further feedback (Alan contacted me offline with similar advice).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No.
Hi Andrew,
I think most people are concentrating on JVMLS/OJW currently. That could
explain a lack of comments.
But from the discussion on this thread I see that your proposal is well
received.
On 7/31/18 4:01 AM, Andrew Dinn wrote:
Well, given the lack of any further input I am left
Hi Andrew,
The JEP is clear on the concept and has many more details than are necessary
to submit it. Supplying so much detail at the earliest stage invites more
discussion about the implementation than the concept.
Usually, the details of API and implementation are added as the JEP
Well, given the lack of any further input I am left wondering, JEP
neophyte that I am, whether:
i) said happy lacuna implies that it is appropriate to submit this JEP
(as prompted by both the process blurb provided in JEP 1 and the
accordingly labelled button in the JEP JIRA interface)
or
* Andrew Dinn:
>> +// TODO - remove the following defines
>> +// for testing we need to define the extra MAP_XXX flags used for
>> +// persistent memory. they will eventually get defined by the
>> +// system and included via sys/mman.h
>>
>> Do you really want to change
On 26/07/18 20:05, Florian Weimer wrote:
> * Andrew Dinn:
>
>>> +// TODO - remove the following defines
>>> +// for testing we need to define the extra MAP_XXX flags used for
>>> +// persistent memory. they will eventually get defined by the
>>> +// system and included via
Round 2
---
I have updated the JEP and uploaded a revised webrev in the light of
existing feedback
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.02/
I would
On 07/24/2018 01:17 PM, Andrew Dinn wrote:
> I'm also now unsure that a DMB(ISHST)is actually adequate. The relevant
> text from the ARM ARM is at the end of the text I previously cited.
>
> "In all cases, where the text in this section refers to a DMB or a DSB ,
> this means a DMB or DSB whose
On 23/07/18 12:01, Andrew Dinn wrote:
> Hi Florian,
>
> Thank you for the feedback. Comments inline below (extensive comments in
> the case of the memory model question - it is complex).
Having written up what I assumed was needed, of course I then went back
to have another look at the Intel code
Hi Florian,
Thank you for the feedback. Comments inline below (extensive comments in
the case of the memory model question - it is complex).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
* Andrew Dinn:
> Comments and suggestions for improvement would be very welcome.
There are a bunch of typos in the JEP (“susbet”, “Rntime”).
Formatting of the headlines looks wrong to me, too.
On the implementation side, I find this a bit concerning:
+// TODO - remove the following defines
On 20/07/18 15:05, Alan Bateman wrote:
> On 20/07/2018 14:50, Andrew Dinn wrote:
>> I have finally managed to draft a JEP to formally present the proposal I
>> circulated a month or two back regarding support for MappedByteBuffer
>> access to non-volatile memory.
>>
>> JEP JIRA:
>>
On 20/07/2018 14:50, Andrew Dinn wrote:
I have finally managed to draft a JEP to formally present the proposal I
circulated a month or two back regarding support for MappedByteBuffer
access to non-volatile memory.
JEP JIRA:
https://bugs.openjdk.java.net/browse/JDK-8207851
The JEP references
84 matches
Mail list logo
