RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

[Andrew Dinn]

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 files, also it aligns with the MAP_SYNC flag to mmap. I don't
> recall if the discussion on isPersistent concluded, that was more of a
> naming issue and whether you include an isXXX method or not is not
> critical to the proposal. The overload of the force method to specify a
> range is a good addition, irrespective of the JEP.

Ok, thanks. At least sync is now being used consistently in the public
API. I will look at renaming internal vars/methods to use sync when I
publish the next webrev.

> One thing to clarify is the heading "Proposed Restricted Public JDK API
> Changes". The proposal (and the early webrevs) exposed writebackMemory
> in the internal Unsafe, not sun.misc.Unsafe, which I think is right.
> This makes it a JDK internal API so it doesn't need to be in JEP.


I am happy to remove it from the JEP if needed. Does it do any harm to
leave it?

> Did you get any feedback on the Testing section? Given that the feature
> needs special hardware then it will need commitment to test is on a
> regular basis. It's a similar issue to the draft "JEP 337: RDMA Network
> Sockets" where special hardware is needed to full test the feature. In
> the case of JEP 337 then some testing with emulation is possible.

I believe I received no specific feedback on that topic.

Some of the other Red Hat dev teams (i.e. not OpenJDK) and also dev
staff at Intel are very keen to base some of their future work on this
feature. So, it will certainly get tested /after/ JDK release :-)

Red Hat does have the Intel hardware needed to test this feature but, so
far, nothing that can be used to test on AArch64. Our OpenJDK team can
access this kit for one-off testing but it is not currently available
for continuous integration testing.

I will propose to my manager that we acquire the relevant kit and ensure
that all JDKs which implement this JEP are tested prior to release. We
should also be able to test AArch64 using volatile memory to simulate a
non-volatile memory device up to the point where the requisite
AArch64-based NVM hardware becomes available. I am fairly confident this
plan will be agreeable to the overlords whom I humbly serve.

Perhaps Intel also could provide help with testing? [Sadhya, is this an
option?]

My bigger concern was that crash recovery tests may never be 100%
reliable. A 100% guarantee requires the ability to engineer a machine
crash at a precisely defined critical point of execution and some of the
relevant critical locations will be embedded in the middle of JITted
code making it hard to provoke the crash. So, the situations where a
crash /can/ be engineered may not fully reflect those that occur in live
deployments. That said, a dash of artificiality in test code is,
perhaps, not so worthy of remark . . .

> 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? :-).

regards,


Andrew Dinn
-----------