>
> From: Robert Engels
> Date: Wednesday, April 3, 2019 at 4:00 PM
> To: Jerrin Shaji George
> Cc: "golang-nuts@googlegroups.com" , Mohit
> Verma , Pratap Subrahmanyam , Rajesh
> Venkatasubramanian
> Subject: Re: [go-nuts] Persistent memory support for Go
t memory accessible to Go developers.
Thanks!
Mohit
From: Robert Engels
Date: Wednesday, April 3, 2019 at 4:00 PM
To: Jerrin Shaji George
Cc: "golang-nuts@googlegroups.com" , Mohit Verma
, Pratap Subrahmanyam , Rajesh
Venkatasubramanian
Subject: Re: [go-nuts] Persistent memory
il 3, 2019 at 4:00 PM
> To: Jerrin Shaji George
> Cc: "golang-nuts@googlegroups.com" , Mohit
> Verma , Pratap Subrahmanyam , Rajesh
> Venkatasubramanian
> Subject: Re: [go-nuts] Persistent memory support for Go
>
> Also, I’ve used pmem for a very long time (I hav
Also, I’ve used pmem for a very long time (I have a bg in retail point of sale
systems where it is very common) and we always had a driver/library on top of
the physical device to multiplex across consumers, and we used it from Java,
and never needed specialized JVM to use it efficiently.
Never mind on the “what is pmem” as I found the VMware docs.
I am curious though why you need specialized runtime support rather than mmap
on a block device? I am assuming that the api is slightly easier to use from a
standard Go perspective but given the variable performance characteristics
I think the project needs to be distributed as a patch to the Go codebase - too
much to review/maintain for security controls.
Also, I’m curious about the Api. In reviewing the example, it looks no
different than any ORM - just flatter -and these don’t need a customized
runtime.
What would
Hi,
I am part of a small team at VMware working on projects related to persistent
memory (others in CC). We have recently been working on adding persistent memory
support to the Go programming language, and I wanted to spread the word about
couple of these projects.
1) Go-pmem-transaction
The
