5

Can optimizations done by the C# compiler or the JITter have visible side effects?

One example I've though off.

var x = new Something(); A(x); B(x);

When calling A(x) x is guaranteed to be kept alive to the end of A - because B uses the same parameter. But if B is defined as

public void B(Something x) { }

Then the B(x) can be eliminated by the optimizer and then a GC.KeepAlive(x) call might be necessary instead.

Can this optimization actually be done by the JITter?

Are there other optimizations that might have visible side effects, except stack trace changes?

Improve this question
6
  • 2
    Why in the world would you need to keep x alive if it's not being used any more? Commented Jan 19, 2011 at 19:07
  • For a good article on JIT optimizations check out codeproject.com/KB/dotnet/JITOptimizations.aspx - the JITer might optimize away empty method calls, but will keep the methods themselves Commented Jan 19, 2011 at 19:09
  • 1
    @JSBangs: The reason you might want to keep something alive is because its destruction triggers unmanaged code to run in an undesired place. For example, there are COM storage objects which require "inner" storages (think nested directories) to be closed before "outer" storages which contain them. The garbage collector could determine that a managed object which represents an outer storage is no longer being used, and decide to clean it up before an inner storage that is still alive is cleaned up. I have in practice had to write code to deal with this situation and it is a real pain. Commented Jan 19, 2011 at 20:53
  • @Eric, but isn't that what IDisposable is for? The outer storage holds a reference to the inner storages, and calls Dispose on them before releasing its own resources. Hopefully you'd never have to care about when the garbage collector claims something. Unless the class in question is a 3rd party library you can't modify and it's poorly designed, in which case.... <shudder>. Commented Jan 19, 2011 at 21:06
  • I was referring to cases that have to do with unmanaged code like Eric mentioned. I don't know the specifics, since I only heard about them from Eric, but that's what I was thinking of in my example. Commented Jan 19, 2011 at 23:30

4 Answers 4

Reset to default
8

If your function B does not use the parameter x, then eliminating it and collecting x early does not have any visible side effects.

To be "visible side effects", they have to be visible to the program, not to an external tool like a debugger or object viewer.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

7

When calling A(x) x is guaranteed to be kept alive to the end of A - because B uses the same parameter.

This statement is false. Suppose method A always throws an exception. The jitter could know that B will never be reached, and therefore x can be released immediately. Suppose method A goes into an unconditional infinite loop after its last reference to x; again, the jitter could know that via static analysis, determine that x will never be referenced again, and schedule it to be cleaned up. I do not know if the jitter actually performs these optimization; they seem dodgy, but they are legal.

Can this optimization (namely, doing early cleanup of a reference that is not used anywhere) actually be done by the JITter?

Yes, and in practice, it is done. That is not an observable side effect.

This is justified by section 3.9 of the specification, which I quote for your convenience:

If the object, or any part of it, cannot be accessed by any possible continuation of execution, other than the running of destructors, the object is considered no longer in use, and it becomes eligible for destruction. The C# compiler and the garbage collector may choose to analyze code to determine which references to an object may be used in the future. For instance, if a local variable that is in scope is the only existing reference to an object, but that local variable is never referred to in any possible continuation of execution from the current execution point in the procedure, the garbage collector may (but is not required to) treat the object as no longer in use.

Can optimizations done by the C# compiler or the JITter have visible side effects?

Your question is answered in section 3.10 of the specification, which I quote here for your convenience:

Execution of a C# program proceeds such that the side effects of each executing thread are preserved at critical execution points.

A side effect is defined as a read or write of a volatile field, a write to a non-volatile variable, a write to an external resource, and the throwing of an exception.

The critical execution points at which the order of these side effects must be preserved are references to volatile fields, lock statements, and thread creation and termination.

The execution environment is free to change the order of execution of a C# program, subject to the following constraints:

Data dependence is preserved within a thread of execution. That is, the value of each variable is computed as if all statements in the thread were executed in original program order.

Initialization ordering rules are preserved.

The ordering of side effects is preserved with respect to volatile reads and writes.

Additionally, the execution environment need not evaluate part of an expression if it can deduce that that expression’s value is not used and that no needed side effects are produced (including any caused by calling a method or accessing a volatile field).

When program execution is interrupted by an asynchronous event (such as an exception thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order.

The second-to-last paragraph is I believe the one you are most concerned about; that is, what optimizations is the runtime allowed to perform with respect to affecting observable side effects? The runtime is permitted to perform any optimization which does not affect an observable side effect.

Note that in particular data dependence is only preserved within a thread of execution. Data dependence is not guaranteed to be preserved when observed from another thread of execution.

If that doesn't answer your question, ask a more specific question. In particular, a careful and precise definition of "observable side effect" will be necessary to answer your question in more detail, if you do not consider the definition given above to match your definition of "observable side effect".

Improve this answer

4 Comments

Since I'm passing the argument to B, even though it is not used inside that method, I though that x would be considered live at least until B is entered. Was I mistaken?
@configurator I'm guessing the JIT can see that the method does nothing and eliminate the method and all calls to it entirely.
@configurator: As section 3.9 clearly states, the jitter is under no obligation to consider the contents of x alive if x is provably never read from past a certain point. The jitter is under no obligation to consider it dead, either. It's an implementation-defined optimization.
I understand now where I had misread that originally. Thanks for the insights here.
0

Including B in your question just confuses the matter. Given this code:

var x = new Something(); A(x);

Assuming that A(x) is managed code, then calling A(x) maintains a reference to x, so the garbage collector can't collect x until after A returns. Or at least until A no longer needs it. The optimizations done by the JITer (absent bugs) will not prematurely collect x.

You should define what you mean by "visible side effects." One would hope that JITer optimizations at least have the side effect of making your code smaller or faster. Are those "visible?" Or do you mean "undesireable?"

Improve this answer

Comments

0

Eric Lippert has started a great series about refactoring which leads me to believe that the C# Compiler and JITter makes sure not to introduce side effects. Part 1 and Part 2 are currently online.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.