Есть ли другие языки программирования / платформы с сборщиком мусора, такие как JVM? - PullRequest
0 голосов
/ 11 апреля 2011

я просто хочу знать, имеют ли другие языки / платформы программирования, такие как PHP, Ruby, C # и т. Д. (Где вам не приходится вручную управлять памятью), такую ​​же проблему с GC, как Java на JVM, что приводит к длительной паузе , высокое время отклика, низкая пропускная способность и т. д. при большом размере кучи (> 5 ГБ)?

Или это общая проблема со всеми языками / платформами с GC-Ability, но в java-мире это тема горячих дискуссий только потому, что на Java написано много крупномасштабных систем, и с ними чаще приходится иметь дело. эта проблема тогда в другом месте?

Спасибо тебе большое!

Ответы [ 3 ]

1 голос
/ 11 апреля 2011

Да, все языки на основе GC будут иметь похожие проблемы с очень большими кучами.Это имеет очень мало общего с языком, и все с реализацией виртуальной машины (а также с опциями настройки GC и, конечно, кодом приложения).Поскольку приложения с очень большими кучами все еще встречаются довольно редко, но становятся все более распространенными, это становится основным преимуществом для поставщиков альтернативных реализаций виртуальных машин, таких как IBM или Azul Systems .

0 голосов
/ 11 апреля 2011

Это не имеет ничего общего с языком программирования. Это вопрос качества реализации сборщика мусора.

Сборщики мусора в реальном времени с предсказуемым и настраиваемым временем паузы известны с 1970-х годов. В настоящее время это становится еще проще: поскольку машины обычно имеют 1000 процессоров, просто отложите пару десятков или около того, чтобы сборщик мусора работал, и выполняйте сборку одновременно.

Например, Azul Jaca Compute Appliance делает именно это. Он специально разработан для очень больших приложений с очень большими кучами и требованиями, близкими к реальному времени (например, автоматизированные торговые системы для хедж-фондов). А поскольку JCA запускает JVM, а на JVM работают и Ruby, и PHP (а также Python, Smalltalk, Lisp, Scheme, JAvaScript и hellip;), они также получают доступ к этой технологии.

Текущая версия (JCA 7300) имеет до 864 процессоров и 768 ГБ оперативной памяти. Как правило, сборщик (-и) мусора будет использовать 20–30 процессоров, оставляя более 700 (JIT-компилятор также использует дюжину или три) для приложений. Это все еще намного больше, чем почти все приложения.

0 голосов
/ 11 апреля 2011

Говоря о .NET, нет. Сборка мусора происходит автоматически, и в большинстве случаев вам не о чем беспокоиться, поскольку управляемая куча постоянно контролируется, а сбор выполняется по мере необходимости.

Однако, если вам требуется некоторый контроль над сборкой мусора, вы можете контролировать режим задержки и иметь меру контроля над сборкой мусора .

В смежной теме у вас все еще могут быть утечки памяти, даже в управляемом коде. Если это так, то не имеет значения, как часто запускается сборщик мусора или насколько он эффективен ...

...