Цитата:
Сообщение от
mazzy
не надо лезть на уровень windbg
это уровень ядра и C++. все равно на этом уровне вы ничего сделать не сможете, только версию ядра обновить (обновите exe-шники по-любому)
Теоретически, если понять работу чего-то ниже уровнем, необязательно это изменять чтобы сделать что-то хорошее. Может быть достаточно использовать это по другому. Вот, например, описание того, как человек, используюя
инструменты отладки и оптимизации решил проблему в свой презентации powerpoint.
Цитата:
JVM в аксапте была форкнута очень давно.
Она там не форкнута - там свой сборщик мусора который работает по другим принципам - подсчет ссылок вместо mark and sweep. Из-за этого не надо явно финализировать объекты (они собираются сразу после пропадания последней ссылки), но в случае циклических ссылок может быть проблема с тем, что сборщик мусора работает слишком долго.
Еще есть сложность с распределенной сборкой мусора - клиент может хранить ссылку на объект на сервере и может быть распределенный цикл, который собирается как-то очень нетривиально и долго. В Ax2012, ЕМНИП, специально устраняли такие ссылки.
Я не очень знаю, как при помощи WinDBG исследовать unmanaged память, но я знаю что, по крайней мере, в Dyn365FO есть performance counters для количества объектов, сборок мусора и так далее. Может быть что-то такое есть и в 2009 и оно как-то поможет в исследовании проблемы. В
доке по 2012, впрочем, я их не вижу