¿Por qué Ada no tiene un recolector de basura?

Question

Sé que GC no era popular en los días en que se desarrolló Ada y para el caso de uso principal de la programación integrada todavía no es una buena opción.

Pero teniendo en cuenta que Ada es un lenguaje de programación de propósito general, no fue un recolector de basura parcial y opcional (solo objetos de memoria etiquetados explícitamente) introducido en revisiones posteriores del lenguaje y las implementaciones del compilador.

Simplemente no puedo pensar en desarrollar una aplicación de escritorio normal sin un recolector de basura.

Answer 1

Ada fue diseñado con aplicaciones militares en mente. Una de las principales prioridades en su diseño fue el determinismo. es decir, uno quería que un programa Ada siempre funcionara exactamente de la misma manera todas las veces, en cualquier entorno, bajo todos los sistemas operativos ... algo así.

Un recolector de basura convierte una aplicación en dos, trabajando una contra la otra. Los programas Java desarrollan contratiempos a intervalos aleatorios cuando el GC decide ir a trabajar, y si es demasiado lento, existe la posibilidad de que una aplicación se quede sin montón algunas veces y otras no.

Simplificado: Un recolector de basura introduce cierta variabilidad en un programa que los diseñadores no querían. ¡Haces un desastre, lo limpias! Mismo código, el mismo comportamiento cada vez.

No es que Ada se haya convertido en un gran éxito en todo el mundo, no importa.

Answer 2

Porque Ada se diseñó para su uso en sistemas de defensa que controlan armas en tiempo real, y la recolección de basura interfiere con el tiempo de su aplicación. Esto es peligroso y por eso, durante muchos años, Java recibió una advertencia de que no se utilizaría para sistemas de control sanitario y militar.

Creo que la razón por la que ya no existe tal descargo de responsabilidad con Java es porque el hardware subyacente se ha vuelto mucho más rápido, así como el hecho de que Java tiene mejores algoritmos GC y un mejor control de GC.

Recuerde que Ada se desarrolló en las décadas de 1970 y 1980, cuando las computadoras eran mucho menos poderosas de lo que son hoy en día, y en aplicaciones de control, los problemas de sincronización eran primordiales.

Answer 3

la respuesta es más complicada: Ada no requiere un recolector de basura, debido a las restricciones en tiempo real y tal. sin embargo, el lenguaje ha sido inteligentemente diseñado para permitir la implementación de un recolector de basura.

aunque, muchos (casi todos) los compiladores no incluyen un recolector de basura, hay alguna aplicación notable:

• a patch for GNAT
• compiladores Ada dirigidos a la máquina virtual de Java (que no sé si los los proyectos todavía son compatibles). Usó el recolector de basura de la JVM.

hay muchas otras fuentes sobre la recolección de basura en Ada en la web. este tema ha sido discutido ampliamente, principalmente debido a la feroz competencia con Java a mediados de los 90 (eche un vistazo a this page: "Ada 95 is what the Java language should have been"), cuando Java era "The Next Big Thing" antes de que Microsoft dibujara C#.

Answer 4

En primer lugar, no hay nada en el lenguaje realmente que prohíbe recolección de basura.

En segundo lugar algunas implementaciones realizan recolección de basura. En particular, todas las implementaciones que se dirigen a la recolección de basura JVM.

En tercer lugar, hay una manera de obtener una cierta cantidad de recolección de basura con todos los compiladores. Verá, cuando un acceso tipo sale del alcance, si especificamente le dijo al lenguaje que reserve una cantidad de espacio para el almacenamiento de sus objetos, ese espacio se destruirá en ese punto. Lo he usado en el pasado para obtener un poquito de recolección de basura. La declaración voodo que se utiliza es:

type Foo is access Blah; 
for Foo'storage_size use 100_000_000; --// 100K 

Si lo hace, entonces todo (100K de) memoria asignada a los objetos Blah apuntado por punteros Foo será limpiado cuando el tipo de Foo sale del ámbito. Como Ada le permite anidar subrutinas dentro de otras subrutinas, esto es particularmente poderoso.

Para ver más sobre lo STORAGE_SIZE y almacenamiento piscinas pueden hacer por usted, ver LRM 13.11

En cuarto lugar, los programas de Ada bien escrito no tienden a depender de asignación de memoria dinámica casi tanto como los programas de C hacen. C tenía una serie de agujeros de diseño que los practicantes aprendieron a usar punteros para pintar. Muchos de esos modismos no son nessecary en Ada.

Answer 5

En primer lugar, me gustaría saber quién está usando Ada en estos días. De hecho, me gusta el lenguaje, e incluso hay una biblioteca de GUI para Linux/Ada, pero no he escuchado nada sobre el desarrollo activo de Ada durante años. Gracias a sus conexiones militares, realmente no estoy seguro si es historia antigua o tan exitosa que toda mención de su uso está clasificada.

Creo que hay un par de razones para no GC en Ada. En primer lugar, y sobre todo, se remonta a una época en la que la mayoría de los lenguajes compilados usaban principalmente memoria estática o apilada, o en algunos casos, asignación/asignación de pila explícita. GC como filosofía general realmente solo despegó aproximadamente en 1990, cuando OOP, algoritmos de administración de memoria mejorados y procesadores lo suficientemente potentes como para ahorrarle a los ciclos su funcionamiento, todo salió a la luz. Lo que simplemente compilar Ada podría hacer con un mainframe IBM 4331 en 1989 fue simplemente despiadado. Ahora tengo un teléfono celular que puede superar a la CPU de esa máquina.

Otra buena razón es que hay personas que piensan que un diseño de programa riguroso incluye un control preciso sobre los recursos de memoria, y que no debe haber tolerancia para dejar flotar los objetos adquiridos dinámicamente. Lamentablemente, demasiadas personas terminaron perdiendo memoria a medida que la memoria dinámica se convirtió cada vez más en la regla. Además, al igual que la "eficiencia" del lenguaje ensamblador en idiomas de alto nivel y la "eficiencia" de JDBC sin formato en sistemas ORM, la "eficiencia" de la gestión manual de la memoria tiende a invertirse a medida que aumenta (he visto los puntos de referencia de ORM donde el equivalente JDBC era solo la mitad de eficiente). Contra-intuitivo, lo sé, pero en la actualidad los sistemas son mucho mejores para la optimización global de grandes aplicaciones, además de que son capaces de realizar re-optimizaciones radicales en respuesta a cambios superficiales menores. Incluyendo dinámicamente algoritmos de reequilibrio sobre la marcha basados ​​en detectado carga.

Me temo que tendré que diferenciarme con aquellos que dicen que los sistemas en tiempo real no pueden pagar la memoria del GC. GC ya no es algo que congela todo el sistema cada dos minutos. Tenemos formas mucho más inteligentes de reclamar la memoria en estos días.

Answer 6

Tu pregunta es incorrecta. Lo hace. Consulte el paquete ada.finalization que maneja GC para usted.

Answer 7

pensé que me gustaría compartir un ejemplo muy simple de cómo poner en práctica un procedimiento gratuito() (que se utiliza de una manera familiar para todos los programadores C) ...

with Ada.Integer_Text_IO, Ada.Unchecked_Deallocation; 
use Ada.Integer_Text_IO; 

procedure Leak is 
    type Int_Ptr is access Integer; 
    procedure Free is new Ada.Unchecked_Deallocation (Integer, Int_Ptr); 

    Ptr : Int_Ptr := null; 
begin 
    Ptr := new Integer'(123); 
    Free (Ptr); 
end Leak; 

llamadas gratuitamente en el final del programa devolverá el entero asignado al grupo de almacenamiento ("montón" en el lenguaje C). Puede usar valgrind para demostrar que esto de hecho evita que se filtren 4 bytes de memoria.

La Ada.Unchecked_Deallocation (un procedimiento genéricamente definido) se puede utilizar en (creo) cualquier tipo que se pueda asignar utilizando la palabra clave "nueva". El Manual de referencia de Ada ("13.11.2 Desasignación de almacenamiento no verificado") tiene más detalles.