Quantcast

Could NIFs keep pointers to Erlang terms without copying them?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Could NIFs keep pointers to Erlang terms without copying them?

Jean Rougé
Hi,

If NIFs want to keep an erlang term around, they currently have to copy them to their own, process-independent environment, using enif_make_copy.

That can be a pretty big performance issue if dabbling with big terms: imagine for example a NIF storing a complicated data structure, e.g. a gb_tree; now say we want to keep adding/deleting items from that gb_tree in our erlang code: we now have to copy the entire thing back and forth.

How hard/conceivable would it be to give NIFs a way to keep a pointer to an erlang term that they could pass back and forth with the process' environments without having to copy everything?

I imagine that would mean that it would be the NIF's programmer responsibility to:
  • ensure that they never keep a pointer to an erlang term that's no longer referenced in erlang land (and hence is going to get garbage collected)
  • ensure thread-safety
But the erlang VM would still have to somehow let the NIF know when an erlang term it has a pointer to has been moved somewhere else.

Is that something that could maybe, in theory, be possible to add to the current VM?

Thanks a lot,

Jean

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Could NIFs keep pointers to Erlang terms without copying them?

Dmytro Lytovchenko
Modifying the way how garbage collect algorithm calculates the root set will do what you want. Now the trick is that GC runs per process and nifs are organized independently. There must be a way for a process to know which nif holds something from its heap.

On Feb 8, 2017 05:22, "Jean Rougé" <[hidden email]> wrote:
Hi,

If NIFs want to keep an erlang term around, they currently have to copy them to their own, process-independent environment, using enif_make_copy.

That can be a pretty big performance issue if dabbling with big terms: imagine for example a NIF storing a complicated data structure, e.g. a gb_tree; now say we want to keep adding/deleting items from that gb_tree in our erlang code: we now have to copy the entire thing back and forth.

How hard/conceivable would it be to give NIFs a way to keep a pointer to an erlang term that they could pass back and forth with the process' environments without having to copy everything?

I imagine that would mean that it would be the NIF's programmer responsibility to:
  • ensure that they never keep a pointer to an erlang term that's no longer referenced in erlang land (and hence is going to get garbage collected)
  • ensure thread-safety
But the erlang VM would still have to somehow let the NIF know when an erlang term it has a pointer to has been moved somewhere else.

Is that something that could maybe, in theory, be possible to add to the current VM?

Thanks a lot,

Jean

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Could NIFs keep pointers to Erlang terms without copying them?

zxq9-2
On 2017年2月8日 水曜日 08:23:54 Dmytro Lytovchenko wrote:
> Modifying the way how garbage collect algorithm calculates the root set
> will do what you want. Now the trick is that GC runs per process and nifs
> are organized independently. There must be a way for a process to know
> which nif holds something from its heap.

...which seems to hint that the underlying problem would be better handled
by a non-NIF solution.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Could NIFs keep pointers to Erlang terms without copying them?

Mikael Pettersson-5
In reply to this post by Jean Rougé
Jean Rougé writes:
 > Hi,
 >
 > If NIFs want to keep an erlang term around, they currently have to copy
 > them to their own, process-independent environment, using enif_make_copy.
 >
 > That can be a pretty big performance issue if dabbling with big terms:
 > imagine for example a NIF storing a complicated data structure, e.g. a
 > gb_tree; now say we want to keep adding/deleting items from that gb_tree in
 > our erlang code: we now have to copy the entire thing back and forth.
 >
 > How hard/conceivable would it be to give NIFs a way to keep a pointer to an
 > erlang term that they could pass back and forth with the process'
 > environments without having to copy everything?
 >
 > I imagine that would mean that it would be the NIF's programmer
 > responsibility to:
 >
 >    - ensure that they never keep a pointer to an erlang term that's no
 >    longer referenced in erlang land (and hence is going to get garbage
 >    collected)
 >    - ensure thread-safety
 >
 > But the erlang VM would still have to somehow let the NIF know when an
 > erlang term it has a pointer to has been moved somewhere else.
 >
 > Is that something that could maybe, in theory, be possible to add to the
 > current VM?

What you're describing is similar to "wrong-way pointers" in generational GCs.

The current Erlang/OTP VM does not support that.

In theory all you'd need is an additional set of "external references" into
an Erlang process' heap.  These could be hard, as in keeping terms live even
if the process itself doesn't reference them, or weak as in classical weak
pointers.

Certainly doable.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...