3 ms·

Unreachable is not the same as unused It could still be reachable, just never read from. Static code analysis can detect some forms of this, but not all e.g.

Unreachable is not the same as unused It could still be reachable, just never read from. Static code analysis can detect some forms of this, but not all e.g. if (someUnknownCondition) { // access x }

umanwizard 8y ago
Well as the person I was replying to points out, this is uncomputeable in general (`someUnknownCondition` might be brute-forcing all possible mathematical proofs to see whether the Reimann hypothesis is true), and I would expect optimizing compilers to already handle this in the cases where it is feasibly computable. Is that not the case?
arghwhat 8y ago
In this case, you cannot free the memory manually either without making your program potentially invalid. It is unreasonable to expect a GC to do runtime control flow analysis, which is also more than you would do in a normal case of manual memory management. If you have tricky situations where you know that program flow dictates that an expensive but reachable variable is no longer needed, you would insert a "x = nil" or similar in the position where you would otherwise have made a free. However, this is solely a case of fine-tuned optimization, rather than a case of correctness.
- zamalek 8y ago
  > without making your program potentially invalid You'd only need the GC to disconnect that local from the stack frame, as anything that escapes would be rooted elsewhere. This can be done by having the compiler/JIT emit a liveness map: instruction pointer ranges indicating which variables uninitialized, live or dead. Otherwise, exactly. Rust could do this with zero runtime overhead (as the map would be used by borrowck). This is pretty simple to do but generally isn't, precisely because of this: "this is solely a case of fine-tuned optimization." If you are part of the 0.1% of the people who is actually solving one the of 0.001% problems where this level of control is _genuinely_ important, then use a language that supports this. Assuming that the method is executing for a very long time (>μs), because this the only time you'd probably care about memory management at this level, any FFI is virtually free. However, even if you are part of the 0.1% of people who have a legitimate concern for this, and you are working on a 0.001% problem, why on earth are you doing so many allocations and frees? Against your own better judgement? If you care enough to worry about when memory is freed, you should know enough that you should re-use memory as much as possible without involving the allocator.
  - arghwhat 8y ago
    > This can be done by having the compiler/JIT emit a liveness map: instruction pointer ranges indicating which variables uninitialized, live or dead. I do not see this as improving the situation. I certainly do not see it fix the case where a runtime condition mean that a variable is no longer needed, as branches touching it will no longer be hit. A JIT could theoretically deal with this, but only if the code is retraced and recompiled after the runtime condition changed, which is not generally something you want.

Unreachable is not the same as unused It could still be reachable, just never read from. Static code analysis can detect some forms of this, but not all e.g. if (someUnknownCondition) { // access x }

umanwizard 8y ago

Well as the person I was replying to points out, this is uncomputeable in general (`someUnknownCondition` might be brute-forcing all possible mathematical proofs to see whether the Reimann hypothesis is true), and I would expect optimizing compilers to already handle this in the cases where it is feasibly computable. Is that not the case?

arghwhat 8y ago

In this case, you cannot free the memory manually either without making your program potentially invalid. It is unreasonable to expect a GC to do runtime control flow analysis, which is also more than you would do in a normal case of manual memory management. If you have tricky situations where you know that program flow dictates that an expensive but reachable variable is no longer needed, you would insert a "x = nil" or similar in the position where you would otherwise have made a free. However, this is solely a case of fine-tuned optimization, rather than a case of correctness.

zamalek 8y ago
> without making your program potentially invalid You'd only need the GC to disconnect that local from the stack frame, as anything that escapes would be rooted elsewhere. This can be done by having the compiler/JIT emit a liveness map: instruction pointer ranges indicating which variables uninitialized, live or dead. Otherwise, exactly. Rust could do this with zero runtime overhead (as the map would be used by borrowck). This is pretty simple to do but generally isn't, precisely because of this: "this is solely a case of fine-tuned optimization." If you are part of the 0.1% of the people who is actually solving one the of 0.001% problems where this level of control is _genuinely_ important, then use a language that supports this. Assuming that the method is executing for a very long time (>μs), because this the only time you'd probably care about memory management at this level, any FFI is virtually free. However, even if you are part of the 0.1% of people who have a legitimate concern for this, and you are working on a 0.001% problem, why on earth are you doing so many allocations and frees? Against your own better judgement? If you care enough to worry about when memory is freed, you should know enough that you should re-use memory as much as possible without involving the allocator.
- arghwhat 8y ago
  > This can be done by having the compiler/JIT emit a liveness map: instruction pointer ranges indicating which variables uninitialized, live or dead. I do not see this as improving the situation. I certainly do not see it fix the case where a runtime condition mean that a variable is no longer needed, as branches touching it will no longer be hit. A JIT could theoretically deal with this, but only if the code is retraced and recompiled after the runtime condition changed, which is not generally something you want.