Если вызвать сборку мусора принудительно, то у классов где определен деструктор вручную он вызывается. Но только у простых классов (от System.Object). Взяв к примеру класс System.Windows.Forms.Form унаследовавшись от него и определив деструктор, вызова последнего не наблюдаем. С чем это связано? и как тогда отследить "уход" из памяти обьектов формы?

Здравствуйте, nauro, Вы писали:

N>Если вызвать сборку мусора принудительно, то у классов где определен деструктор вручную он вызывается. Но только у простых классов (от System.Object). Взяв к примеру класс System.Windows.Forms.Form унаследовавшись от него и определив деструктор, вызова последнего не наблюдаем. С чем это связано? и как тогда отследить "уход" из памяти обьектов формы?

Речь идет о finalizer'е ?
Если да, то описанного вами эффекта не наблюдаю (что, в общем-то, и ожидалось)

  public class Program
  {
    static void Main(string[] args)
    {
      Form f = new MyForm();
      f = null;
      GC.Collect();
      GC.WaitForPendingFinalizers();
      GC.Collect();
    }
  }
  
  class MyForm : Form
  {
    ~MyForm()
    {
      Console.WriteLine("Finalizer");
    }
  }

Finalizer

Здравствуйте, desco, Вы писали:
D>Речь идет о finalizer'е ?
D>Если да, то описанного вами эффекта не наблюдаю (что, в общем-то, и ожидалось)

Хорошо как тогда обяснить такую ситуацию:
есть class Form2:

...
public Form2()
{
   InitializeComponent();
}
~Form2()
{
   MessageBox.Show("hello world!");
}
...

есть класс Form1:

private void button1_Click(object sender, System.EventArgs e)
{
   new Form2().Show();
}

private void button2_Click(object sender, System.EventArgs e)
{
   GC.Collect();
   GC.WaitForPendingFinalizers();
   GC.Collect();
}

После нажатия на кнопку 2 ничего не происходит. но как только выделенный код заменить на

new Form2();

Все, работает деструктор вызывается.

Здравствуйте, nauro, Вы писали:

N>Хорошо как тогда обяснить такую ситуацию:
<skipped>

Ну логично предположить, что при вызове Show создается ссылка, не дающая GC собрать форму. При ближайшем рассмотрении рефлектором были выявлены следующие вещи:

1. Вызов Show эквивалент вызову Visible = true;
2. Visible вызывает внутри себя метод SetVisibleCore

protected virtual void SetVisibleCore(bool value)
{
      try
      {
            HandleCollector.SuspendCollect();
            if (this.GetVisibleCore() != value)
            {
                  // skipped
                  this.UpdateRoot();
            }
            else
            {
                 // skipped
            }
      }
      finally
      {
            HandleCollector.ResumeCollect();
      }
}

 
private void UpdateRoot()
{
      this.window.LockReference(this.GetTopLevel() && this.Visible);
}

 
public void LockReference(bool locked)
{
      if (locked)
      {
            if (!this.rootRef.IsAllocated)
            {
                  this.rootRef = GCHandle.Alloc(this.GetControl(), GCHandleType.Normal);
            }
      }
      else if (this.rootRef.IsAllocated)
      {
            this.rootRef.Free();
      }
}

таким образом видно, что после вызова Show в поле window.rootRef будет находится GCHandle хранящий ссылку на форму и предотвращающий ее сборку Garbage Collector'ом

Здравствуйте, desco, Вы писали:

Очень познавательно. Спасибо. Но вопрос остается открытым. Как мне узнать что форма освобождается из памяти?

Hello, "nauro"
> Если вызвать сборку мусора принудительно, то у классов где определен
> деструктор вручную он вызывается. Но только у простых классов (от
> System.Object). Взяв к примеру класс System.Windows.Forms.Form
> унаследовавшись от него и определив деструктор, вызова последнего не
> наблюдаем. С чем это связано? и как тогда отследить "уход" из памяти
> обьектов формы?

Если у объекта обределен метод Dispose(disposing) то, надо использовать
именно его. Что касается финализатора то, из них надо вызывать только
Dispose(false); Размещать же какую-либо логику в финализаторе идея плохая —
многие объекты после вызова Dispose удаляют себя из очереди финализации.
Лучшая идея враппить все unmanaged ресурсы в одним из XXXHandle классов. В
этом случае, использвовать деструктор в формах не понадобится.

Здравствуйте, TK, Вы писали:

TK>Если у объекта обределен метод Dispose(disposing) то, надо использовать
TK>именно его. Что касается финализатора то, из них надо вызывать только
TK>Dispose(false); Размещать же какую-либо логику в финализаторе идея плохая —
TK>многие объекты после вызова Dispose удаляют себя из очереди финализации.
TK>Лучшая идея враппить все unmanaged ресурсы в одним из XXXHandle классов. В
TK>этом случае, использвовать деструктор в формах не понадобится.
Дело не в ресурсах. Я хочу сделать что-то на подобии анализатора наличия обьектов в памяти. Идея такова: Есть корпоративное приложение, есть базовые классы как для бизнес логики (entities), так и для визуальной части (базовый view — BaseForm : Form). В этих базовых классах в конструкторах регистрируется информация что такой то тип породил еще один обьект. Соответсвенно в деструкторах, т.е. при том как обьект очищается из памяти, нужно дэрегистрировать его. Вся логика этого как бы обьектного мини-профайлера собрана в одном классе — синглтоне, который собственно проводит регистрацию и дэнрегистрацию. И эту инфу в дальнейшем данный синглтон может передать посредством сокетов в ответ на соответсвующий запрос. Но вся загвоздка стала именно, как видно из раннее написанных постов, в формах.

Здравствуйте, nauro, Вы писали:

Больше идей не будет?

Hello, "nauro"
>
> Больше идей не будет?

Так может просто использовать интерфейс профайлера для мониторинга
создания/сборки объектов? Лично мне кажется, что данная информация является
по большей части отладочной и заниматься ее непрерывным сбором имеет смысл
только на определенном этапе...

Здравствуйте, TK, Вы писали:

TK>Hello, "nauro"
>>
>> Больше идей не будет?

TK> Лично мне кажется, что данная информация является
TK>по большей части отладочной и заниматься ее непрерывным сбором имеет смысл
TK>только на определенном этапе...
именно! этот этап можно сказать настал. Так как я не нашел средств профайлинга для просмотра обьектов кучи удаленного процеса, решил создать вот тот механизм описанный мною выше.

TK>Так может просто использовать интерфейс профайлера для мониторинга создания/сборки объектов?
как? толкните в правильном направлении! буду оч благодарен.

http://memprofiler.com/ — and life is good again

Здравствуйте, bogucharovy, Вы писали:

B>http://memprofiler.com/ — and life is good again
Вы невнимательно читали мое первое сообщение, и не вникли в суть. Нужен профайлер обьектов кучи, да, но, http://memprofiler.com/ — этим нельзя подконектится к удаленному, да и даже локальному процесу, только изначальный запуск программы из-под него.

Hello, "nauro"
> Вы невнимательно читали мое первое сообщение, и не вникли в суть. Нужен
> профайлер обьектов кучи, да, но, http://memprofiler.com/ — этим нельзя
> подконектится к удаленному, да и даже локальному процесу, только
> изначальный запуск программы из-под него.

Да, тут никуда не денешься. Надо будет запускать приложение сразу из под
профайлера.

Здравствуйте, TK, Вы писали:

TK>Hello, "nauro"
>> Вы невнимательно читали мое первое сообщение, и не вникли в суть. Нужен
>> профайлер обьектов кучи, да, но, http://memprofiler.com/ — этим нельзя
>> подконектится к удаленному, да и даже локальному процесу, только
>> изначальный запуск программы из-под него.

TK>Да, тут никуда не денешься. Надо будет запускать приложение сразу из под
TK>профайлера.

Последняя версия поддерживает attach to process.
Но насчет удаленного процесса верно, он здесь не поможет.

Здравствуйте, bogucharovy, Вы писали:


B>Последняя версия поддерживает attach to process.
B>Но насчет удаленного процесса верно, он здесь не поможет.
вот это уже интерестно. посмотрим..

Здравствуйте, TK, Вы писали:

Так как на счет интерфейса профайлера. Я уже пару раз натыкаюсь именно на ваши посты где вы упоминаете сие. Но ни разу вразумительного "толчка" в направлении от вас не слышал. Я так понимаю, это можно реализовать своими руками, а не со помошью каких-то внешних профайлеров. Подскажите пожалйста если не в тягость, как подступится к этому, и как с помошью интерфейса профайлера отслежевать сбокру обьектов GC?

Здравствуйте, nauro, Вы писали:

N>Здравствуйте, TK, Вы писали:

N>Так как на счет интерфейса профайлера. Я уже пару раз натыкаюсь именно на ваши посты где вы упоминаете сие. Но ни разу вразумительного "толчка" в направлении от вас не слышал. Я так понимаю, это можно реализовать своими руками, а не со помошью каких-то внешних профайлеров. Подскажите пожалйста если не в тягость, как подступится к этому, и как с помошью интерфейса профайлера отслежевать сбокру обьектов GC?

ICorDebug + ICorDebug
Ы?

Hello, "nauro"
>
> Так как на счет интерфейса профайлера. Я уже пару раз натыкаюсь именно на
> ваши посты где вы упоминаете сие. Но ни разу вразумительного "толчка" в
> направлении от вас не слышал. Я так понимаю, это можно реализовать своими
> руками, а не со помошью каких-то внешних профайлеров. Подскажите пожалйста
> если не в тягость, как подступится к этому, и как с помошью интерфейса
> профайлера отслежевать сбокру обьектов GC?

У Microsoft есть пример профайлера. Там есть и исходный код и пример
взаимодействия с профайлером из профилируемого приложения. Про интерфейсы
рядом уже написано.

http://www.microsoft.com/downloads/details.aspx?familyid=A362781C-3870-43BE-8926-862B40AA0CD0&amp;displaylang=en