Интерпретированные языки с ручным управлением памятью?

Question

Какие языки Языки перевода Языки без указателей (IE: Python, Java, Perl, PHP, Ruby, Javascript и т. Д.) Имеют ручное управление памятью? Я не помню, чтобы когда-либо слышал об этом.

Не является ли серьезная проблема для интерпретируемых языков недетерминированными задержками (или сложностью пространства, когда не хватает задержки) сбора мусора? Так почему бы просто не написать что-то точно, как Java, но заставляет вас освобождать память вручную?

EDIT

Что я имею в виду ручного управления памятью, что язык будет иметь ссылки на объекты, и вы можете удалить объект, используя ссылку.

Пример:

Object a = new Object(); // a is a reference to the object 
Object b = a; // b is a reference to the same object 
a.method(); // fine 
delete b; // delete the object referenced by b 
a.method(); // null dereference exception 

Так что предостережения (кроме утечек памяти), может ли быть в таком языке, как этот пример?

Answer 1

Причина - круговые ссылки, исключения из нулевого указателя и множественные ссылки. Простой пример:

var a = new Object(); 
var b = a; 
a = null;//or delete a or free a or whatever; 
print(b);//what now? is b null? or is b still new Object()? 

Если в приведенном выше примере, b теперь нуль, вы в конечном итоге с некоторыми основными проблемами при переопределение переменных. Например, вместо того, чтобы установить a в значение null, что, если вы установите его на c? будет b тоже be c?

Вы можете прочитать о других проблемах, таких как circular references, on wikipedia.

Answer 2

Интерпретировано не обязательно означает сбор мусора. Perl, Tcl, Python и т. Д. И т. Д. Я считаю, что все используют простой подсчет ссылок, поэтому восстановление памяти детерминировано, хотя и вовсе не прозрачно (когда-либо пробовали strace на Perl-программе?).

Answer 3

В некоторых высокопроизводительных интерпретируемых языках, таких как Lua, вы можете вручную обрабатывать сборку мусора. См. lua_gc.

Answer 4

Forth имеет штабелированные области памяти, которые могут быть освобождены с помощью FORGET.

Answer 5

Доступны некоторые интерпретаторы C/C++, например this one.

Не пробовал самостоятельно, но я думаю, что, поскольку он утверждает, что совместим с компилируемым C/C++, он должен иметь «ручное» управление памятью.

Answer 6

API Пайтона oficially позволяет включить или выключить с задержкой сбора мусора - Проверьте документацию на модуле «ой» стандартной библиотеки:

http://docs.python.org/library/gc.html

Но это не то, что делает это медленно по сравнению со статическими языками - динамическая природа самих данных является основной причиной разницы в скорости.

Answer 7

Так отвечая на эту часть вопроса:

не является главной заботой о интерпретируемых языков в недетерминированных задержек (или пространство сложность, когда не хватает задержки) от мусора коллекция? Итак, почему не просто написать что-то точно так же, как Java, но заставляет вас освобождать память вручную?

Это может быть проблемой для некоторых систем. Не проблема для других систем. Программное обеспечение, запущенное с сборкой мусора, может выделять память быстрее, чем системы, которые просто называют malloc. Конечно, вы в конечном итоге оплачиваете время позже в GC время.

Возьмите, например, веб-систему. Вы можете выделить всю память во время обработки запроса, после чего GC может собираться. Возможно, это не закончится так, но вы получите эту идею.

Существует множество различных стратегий сбора мусора. Какая стратегия лучше всего подходит для системы, будет зависеть от требований. Но даже если вам нужен абсолютный детерминизм, вы можете использовать что-то вроде: Realtime Java

Answer 8

В каких интерпретируемых языках имеется ручное управление памятью? Я не помню, чтобы когда-либо слышал об этом.

Нет такой вещи, как язык . Язык не компилируется и не интерпретируется. Язык только is. Язык - это совокупность абстрактных математических правил. Интерпретация или компиляция являются признаками языка осуществления, они имеют ничего, чтобы сделать с языком. Каждый язык может быть реализован либо компилятором, либо интерпретатором; самые современные высокопроизводительные языковые реализации фактически используют как, так и переключаться между ними, в зависимости от того, какой из них быстрее в конкретном контексте.

Есть ли скомпилированный язык? Там есть переводчики С. Является ли Python интерпретированным языком? Все 8 текущих реализаций Python используют компилятор.

Итак, поскольку каждый язык может иметь интерпретируемую реализацию, C и C++ - примеры интерпретируемых языков с ручным управлением памятью. (И это не просто теоретический конкурс по расщеплению волос, там - это на самом деле интерпретаторы C и C++. Операционная система VxWorks в реальном времени даже содержит одно прямое ядро, и NASA когда-то использовало этот интерпретатор для исправления ошибок модуль ядра на космическом корабле.)

Другим примером будет первая версия Lisp с 1958 года: она имела ручное управление памятью (на основе подсчета ссылок), но она была заменена всего на пару месяцев позже версией с автоматическое управление памятью, которое оно использовало с тех пор. Хотя снова любой язык может быть реализован либо с помощью компилятора, либо с помощью интерпретатора, поэтому я не знаю, имела ли эта версия интерпретируемую реализацию или скомпилированную. (На самом деле, я не уверен, было ли это реализовано вообще.)

Если вы немного расслабите свои критерии и понимаете, что управление памятью является лишь частным случаем общего управления ресурсами, то вы найдете, что в значительной степени все языки, хотите ли вы называть их скомпилированными или интерпретированными или что-то совсем другое, имеет некоторую форму управления ресурсами вручную, по крайней мере, вид ресурсов (файловые дескрипторы, подключения к базе данных, сетевые подключения, кеши, ...).

Answer 9

помещения за вопрос немного хитроумный:

• Модель памяти является собственностью языка, а не ее реализация.

• Понятно, что это свойство реализации , а не язык.

Примеры:

• Язык программирования Схема имеет автоматическое управление памятью, и она имеет много десятков интерпретируемых реализаций, но и некоторые прекрасные компилятор с собственным кодом, включая воровству, Гамбит и PLT Scheme (который включает в себя и интерпретатор и JIT-компилятор, делающий плавные переходы).

• Язык программирования Haskell имеет автоматическое управление памятью; двумя наиболее известными реализациями являются интерпретатор HUGS и компилятор GHC. Существует несколько других почетных реализаций, разделенных равномерно между компиляцией на собственный код (yhc) и интерпретацией (Helium).

• Язык программирования C имеет ручное управление памятью, и, хотя мир полон компиляторов C, те из нас, кто достаточно взрослый, чтобы помнить славные 1980-е годы, могут помнить Sabre-C или C-terp, два очень полезных переводчика C для MS-DOS.

Тем не менее есть правдивое наблюдение за Ваш вопрос: языков с ручным управлением памятью, как правило, составляются. Зачем?

• Ручное управление памятью является устаревшей функцией, часто используемой для совместимости с устаревшим кодом. Устаревшие языки обычно достаточно зрелы, чтобы иметь компиляторы с собственным кодом.

• Многие новые языки определяются реализацией. Проще построить интерпретатор, чем создавать компилятор. Легче реализовать простое автоматическое управление памятью в интерпретаторе, чем реализовать высокопроизводительное автоматическое управление памятью в компиляторе собственного кода. Поэтому, если язык получает свое определение от его первой реализации, автоматическое управление памятью коррелирует с интерпретацией, потому что в интерпретируемой настройке реализация проще.

• Ручное управление памятью также (а иногда и оправданно) используется для повышения производительности. Отличные экспериментальные исследования Бен Зорна с 1990-х годов показывают, что автоматическое управление памятью так же быстро или быстро, как ручное управление памятью, но требует в два раза больше памяти.Поэтому ручное управление памятью часто используется на очень небольших устройствах, где памяти мало, а в очень больших центрах обработки данных, где удвоение памяти дорого. (Иногда это также используется людьми, которые мало знают об управлении памятью, но слышали, что сбор мусора медленный. Они были правы в 1980 году.) И когда есть проблема с производительностью, вы обычно находите компилятор с собственным кодом, чем переводчик.

  Некоторые из действительно интересных исключений также вытекают из этого принципа. Например, как FORTH, так и самые первые реализации PostScript были разработаны для работы на небольших встроенных устройствах (телескопы и принтеры), где ресурсы памяти были недостаточными, но время вычисления не было фактором. Оба языка были впервые реализованы с использованием байт-кодов, которые были более компактными, чем собственный код, и оба предназначались для управления ручной памятью. Итак: переводчики с ручным управлением памятью. (Более поздние версии PostScript добавлена ​​опция для сбора мусора.)

В итоге:

• Автоматический против ручного управления памятью является язык.

• Составитель против интерпретированы является реализация.

• В принципе два варианта может быть и сделаны ортогонально, но по прагматическим причинам инженерных автоматическое управление памятью часто коррелирует с интерпретацией.

Не является серьезной проблемой о интерпретируемых языках недетерминированных задержки (или пространство сложности, когда не хватает задержки) сбора мусора?

Я не знал, что там были серьезной озабоченности относительно интерпретируемых реализаций языков программирования. В алфавитном порядке Lua, Perl, PostScript, Python и Ruby все безумно успешны, а Icon, Scheme и Squeak Smalltalk умеренно успешны. Единственная область, в которой непредсказуемые задержки вызывают беспокойство, - это сложные вычисления в реальном времени, такие как система ABS, которая управляет тормозами вашего автомобиля (если вы управляете достаточно фантастическим автомобилем).

---

Примечание добавлено после того, как вопрос был отредактирован: Вы изменили «интерпретированы» в «указатель бесплатно». Но вы говорите в комментарии, что вы хотите спросить о языках с new и delete. Любой язык с new и delete имеет указатели: по определению, любые new возвращает указатель. (На некоторых языках могут быть и другие источники указателей.) Поэтому я думаю, что вы хотите сказать «языки без арифметики указателей и без адреса оператора».