Hi,
> On Jun 21, 2018, at 9:32 AM, Andrew Dinn wrote:
>
> Hi Paul,
>
> Sorry for the delay in responding to this -- holiday and then an urgent
> bug fix intervened . . .
>
> On 08/06/18 01:42, Paul Sandoz wrote:
>> Sandhya gave an overview to a few of us Oracle folks. I agree with
>> what
Hi Paul,
Sorry for the delay in responding to this -- holiday and then an urgent
bug fix intervened . . .
On 08/06/18 01:42, Paul Sandoz wrote:
> Sandhya gave an overview to a few of us Oracle folks. I agree with
> what Sandhya says regarding the API, a small surface, and on pursuing
> an unsafe
On 06/12/2018 06:12 PM, Paul Sandoz wrote:
>
>> We may also want to look at related enhancements like unmapping
>> buffers. I think those pieces are sufficient decoupled that they
>> won't be dependencies for the pmem API though, unlike other factors
>> such as the availability of test hardware.
Hi Jonathan,
> On Jun 8, 2018, at 3:59 AM, Jonathan Halliday
> wrote:
>
>
> Hi Paul
>
> Looks like we're all on the same page regarding the basic approach of using a
> small API and making the critical bits intrinsic. We perhaps have some way to
> go on exactly what that API looks like in
vs pure C native.
Best Regards,
Sandhya
RFC: Experiment in accessing/managing persistent memory from Java
Andrew Dinn adinn at redhat.com
Mon May 21 09:47:46 UTC 2018
I have been helping one of my Red Hat colleagues, Jonathan Halliday, to
investigate provision of a Java equivalent
or some of performance that you saw with
> compiler intrinsic vs pure C native.
>
> Best Regards,
> Sandhya
>
>
>
> RFC: Experiment in accessing/managing persistent memory from Java
> Andrew Dinn adinn at redhat.com
> Mon May 21 09:47:46 UTC 2018
>
>
/cpu/x86/globalDefinitions_x86.hpp whereas actual cache line on the
hardware is 64 bytes.
This could be the cause for some of performance that you saw with compiler
intrinsic vs pure C native.
Best Regards,
Sandhya
RFC: Experiment in accessing/managing persistent memory from Java
Andrew Dinn
I have been helping one of my Red Hat colleagues, Jonathan Halliday, to
investigate provision of a Java equivalent to Intel's libpmem suite of C
libraries [1]. This approach avoids the significant cost of using the
Intel libraries from Java via JNI (or, worse, as a virtual driver for a
persistent
