Optixsoft Blog

Блог

Сборка мусора и локальные переменные


Если вы программируете на C#, то у меня для вас вопрос. Как вы думаете, сколько раз будет выводиться в консоль строка "GC called" при исполнении следующего кода:

using System;
using System.Threading;

class GarbageCollectorTest
{
   public static void Main()
   {
      Timer t = new Timer(CallGC, null, 1000, 1000);
      Console.ReadKey();
   }

   static void CallGC(object o)
   {
      GC.Collect();
      Console.WriteLine("GC called");
   }
}



Правильный ответ: зависит от параметров компиляции. В release-сборке строка выведется только один раз. В debug-сборке строка будет выводится до нажатия пользователем клавиши.

В C++ время жизни локальной (автоматической) переменной определяется областью ее видимости - переменная уничтожается в момент выхода потока исполнения из этой области.
В C# время жизни такой переменной определяется областью ее использования. Т.е., переменная может быть уничтожена до окончания области своей видимости, если сборщик мусора посчитает, что переменная больше не используется.
В debug-сборках для удобства отладки время жизни переменной искусственно удлиняется до окончания области видимости.

Что касается Java, то насколько мне известно спецификация JVM тоже допускает подобную реализацию сборщика мусора.

P.S.: Если вы программируете на C# и для вас этот пост оказался откровением, прочтите книгу Джеффри Рихтера "СLR via C#". Там вы сможете найти еще много интересного, а главное - полезного для серьезной разработки для .NET Framework.

Ярлыки: ,


Блиц-вопрос по C#


Сможете ли быстро назвать три преимущества, которые дает использование автоматических свойств (automatic properties) против использования открытых полей в классе?
То есть, чем следующее объявление
public string Foo{ get; set; }
лучше этого
public string Foo;

Ответ (как это часто бывает) на StackOverflow.

Ярлыки:


NOP-инструкции и отладка.


При отладке приложений часто бывает необходимо внести исправления в исходный код программы. Для того, чтобы эти исправления вступили в силу, обычно надо пересобрать приложение и заново запустить отладку. Однако, в Microsoft Visual Studio есть функция edit-and-continue (редактируй-и-продолжай), которая позволяет исправлять исходный код и применять эти исправления без перезапуска приложения. Когда-нибудь задумывались, как она работает?
Весь секрет в NOP-инструкциях, которые компилятор вставляет в определенные места исполняемого кода. Их-то как раз и можно заменить на вызов новых операторов.
Кроме того, NOP-инструкции позволяют ставить точки останова в те места исходного текста, для которых иначе не существовало бы соответствующего исполняемого кода. Например, на начало блока(открывающая фигурная скобка в C++ и C#). Или на оператор, который бы иcчез в результате оптимизации.

Кстати: Генерация NOP-инструкций может иметь смысл и при компиляции release-версии приложения. Например, при выравнивании блока кода для улучшения кэширования.

Ярлыки: , ,


Optixsoft - Разработка ПО для волоконной оптики. 2009. Все права сохранены.