When, in a programming language, you say
b = a
one of two things can happen:
1. a and b are the same object, so changing one changes the other, or
2. b is an independent copy of a.
1 uses less memory, but can lead to surprising behavior.
If I understand correctly, R does something stranger: a and b are the same object, but a copy is made *later* if either of them is modified.
Is this a clever way to get the best of both worlds, or is it perilous?
@peterdrake now thati think about it, maybe even the JVM does this... I seen to recall it does the just in time copy as well, if it gets too 80% of the max allocated memory for the process? Could be wrong about the triggering conditions though.
@goeland86 I don't know if it happens at a different level (e.g., GC), but within the language, I can't see a parallel to:
b = a
b == a -> true
a.x++
b == a -> false
@peterdrake Right, what I meant is that in the JVM, internally, if you have b = a, until you modify a or b, both pointers link to the same object. As soon as one of the instances gets modified, the JVM will actually duplicate them and create the new one. You would never have case 1. in Java. It's all part of the internal optimizations of the JVM. I ran into that during HPC computing optimizations for the Gaia data processing back in 2014-2015. Memory's a bit fuzzy on the details.
@goeland86 That doesn't sound right, but you may know something I don't. In Java, if I say
b = a
then I *expect* them to be the same object. Modifying one *should* modify the other.
@peterdrake oof, now I need to dig into an ide and test this again. I may be confusing instances of objects with primitives.
@peterdrake unless I'm completely off the mark, it's a behavior inspired by filesystems to imitate the memory savings of 1. while preserving the behavior you expect in 2. Ext3/4 has implemented this under the name "lazy copy" iirc.