5 ms·

You can get everything you want with weak references.

daeken 17y ago
Weak references can be used for the base of this, but it doesn't handle the actual recreation of the objects, nor is it an automatic thing. My goal with this idea is to reduce the cost of implementing such schemes, and shifting them into the compiler/runtime.
- herdrick 17y ago
  True. But I think the smarter thing would be to build this using weak references than to hope someone puts this into their GC or to write your own. At least your first version should be done so.
  - daeken 17y ago
    Agreed. I actually plan on building it on top of .NET initially, as it's quite flexible in this respect. Thanks for your feedback.
- barrkel 17y ago
  A GC wouldn't be able to auto-recreate the object without either an indirection (and thus no better than using a weak reference in a kind of smart pointer), or rather costly logic. Suppose an instantiated object is 512K in size. You've got a reference to it from 50 places. The GC decides to evict it but still has the construction logic which, say, takes up 128 bytes. All the 50 references now need to be updated, but what will they point to? Presumably some kind of proxy or stub which, when touched, inflates to the size of the original object. The problem is that this thing can't inflate in-place, otherwise it wouldn't actually be saving any address space. So, the re-instantiation must occur somewhere else, and 50 locations need to be updated. Since a GC isn't currently in flight, finding those 50 locations is going to be very expensive. It's going to have a similar cost to the mark phase of a GC. The best approach for the GC would be to use an indirection, to treat all references to evictable objects as smart pointers of some kind, with an extra indirection between the reference and the object which may or may not have to be re-instantiated. But this is easily implementable using weak references in runtimes like JVM or CLR.
  - daeken 17y ago
    I see this as being very difficult to implement well, but I think it's interesting enough to warrant further research. I really don't know if it'll end up working out, but I'm planning on prototyping it on top of .NET.
- jganetsk 17y ago
  It may not be a good idea to shift such unpredictable costs to the compiler/runtime. Your program could potentially become much harder to profile.

Weak references can be used for the base of this, but it doesn't handle the actual recreation of the objects, nor is it an automatic thing. My goal with this idea is to reduce the cost of implementing such schemes, and shifting them into the compiler/runtime.

herdrick 17y ago
True. But I think the smarter thing would be to build this using weak references than to hope someone puts this into their GC or to write your own. At least your first version should be done so.
- daeken 17y ago
  Agreed. I actually plan on building it on top of .NET initially, as it's quite flexible in this respect. Thanks for your feedback.
barrkel 17y ago
A GC wouldn't be able to auto-recreate the object without either an indirection (and thus no better than using a weak reference in a kind of smart pointer), or rather costly logic. Suppose an instantiated object is 512K in size. You've got a reference to it from 50 places. The GC decides to evict it but still has the construction logic which, say, takes up 128 bytes. All the 50 references now need to be updated, but what will they point to? Presumably some kind of proxy or stub which, when touched, inflates to the size of the original object. The problem is that this thing can't inflate in-place, otherwise it wouldn't actually be saving any address space. So, the re-instantiation must occur somewhere else, and 50 locations need to be updated. Since a GC isn't currently in flight, finding those 50 locations is going to be very expensive. It's going to have a similar cost to the mark phase of a GC. The best approach for the GC would be to use an indirection, to treat all references to evictable objects as smart pointers of some kind, with an extra indirection between the reference and the object which may or may not have to be re-instantiated. But this is easily implementable using weak references in runtimes like JVM or CLR.
- daeken 17y ago
  I see this as being very difficult to implement well, but I think it's interesting enough to warrant further research. I really don't know if it'll end up working out, but I'm planning on prototyping it on top of .NET.
jganetsk 17y ago
It may not be a good idea to shift such unpredictable costs to the compiler/runtime. Your program could potentially become much harder to profile.