Tại sao Ada không có bộ thu gom rác?

Question

Tôi biết GC không phổ biến trong những ngày khi Ada được phát triển và cho trường hợp sử dụng chính của chương trình nhúng, nó vẫn không phải là một lựa chọn tốt. Tuy nhiên, xem xét rằng Ada là một ngôn ngữ lập trình mục đích chung tại sao không phải là một bộ sưu tập rác một phần và tùy chọn (dấu vết chỉ được gắn thẻ rõ ràng đối tượng bộ nhớ) được giới thiệu trong các phiên bản sau của ngôn ngữ và triển khai trình biên dịch.

Tôi chỉ đơn giản là không thể nghĩ đến việc phát triển một ứng dụng máy tính để bàn bình thường mà không có bộ thu gom rác nữa.

Answer 1

Ada được thiết kế với các ứng dụng quân sự. Một trong những ưu tiên lớn trong thiết kế của nó là quyết định. tức là người ta muốn một chương trình Ada luôn thực hiện chính xác theo cách giống nhau mọi lúc, trong mọi môi trường, dưới mọi hệ điều hành ... điều đó.

Trình thu thập rác biến một ứng dụng thành hai, hoạt động với nhau. Các chương trình Java phát triển trục trặc trong khoảng thời gian ngẫu nhiên khi GC quyết định đi làm, và nếu nó quá chậm về nó có một cơ hội mà một ứng dụng sẽ chạy ra khỏi đống đôi khi và không phải những người khác.

Đơn giản hóa: Bộ thu gom rác giới thiệu một số thay đổi trong chương trình mà nhà thiết kế không muốn. Bạn làm cho một mớ hỗn độn - bạn làm sạch nó lên! Cùng một mã, cùng một hành vi mỗi lần.

Không phải Ada đã trở thành một thành công trên toàn thế giới hoành hành, hãy nhớ bạn.

Answer 2

Vì Ada được thiết kế để sử dụng trong các hệ thống phòng thủ kiểm soát vũ khí trong thời gian thực và thu gom rác thải ảnh hưởng đến thời gian của ứng dụng của bạn. Điều này là nguy hiểm, đó là lý do tại sao, trong nhiều năm, Java đã đưa ra một cảnh báo rằng nó không được sử dụng cho các hệ thống kiểm soát y tế và quân sự.

Tôi tin rằng lý do không còn tuyên bố từ chối trách nhiệm với Java là vì phần cứng cơ bản đã trở nên nhanh hơn nhiều so với thực tế là Java có các thuật toán GC tốt hơn và kiểm soát tốt hơn GC.

Hãy nhớ rằng Ada đã được phát triển vào những năm 1970 và 1980 tại thời điểm máy tính kém hiệu quả hơn ngày nay, và trong các ứng dụng điều khiển thời gian là rất quan trọng.

Answer 3

câu trả lời phức tạp hơn: Ada không yêu cầu bộ thu gom rác, vì các ràng buộc thời gian thực và như vậy. tuy nhiên, ngôn ngữ đã được thiết kế khéo léo để cho phép thực hiện bộ thu gom rác.

mặc dù, nhiều (hầu hết) các trình biên dịch không bao gồm một bộ thu rác, có một số thực hiện đáng chú ý:

• a patch for GNAT
• Ada trình biên dịch nhắm mục tiêu Java Virtual Machine (tôi không biết nếu những dự án vẫn được hỗ trợ). Nó sử dụng bộ thu gom rác của JVM.

có rất nhiều nguồn khác về thu thập rác trong Ada trên web. chủ đề này đã được thảo luận về chiều dài, chủ yếu là do sự cạnh tranh khốc liệt với Java vào giữa những năm 90 (có một cái nhìn tại this page: "Ada 95 is what the Java language should have been"), khi Java là "Next Big Thing" trước khi Microsoft vẽ C#.

Answer 4

Trước hết, không có gì trong ngôn ngữ thực sự là cấm thu gom rác thải.

Thứ hai, một số triển khai thực hiện thu thập rác. Cụ thể, tất cả các triển khai nhắm mục tiêu thu thập rác JVM.

Thứ ba, có cách lấy một số lượng thu gom rác với tất cả trình biên dịch. Bạn thấy, khi truy cập loại vượt quá phạm vi, nếu bạn chỉ định một cách cụ thể ngôn ngữ để dành một lượng không gian đủ để lưu trữ các đối tượng của nó, thì không gian đó sẽ bị hủy tại thời điểm đó. Tôi đã sử dụng điều này trong quá khứ để có được một số modicum của bộ sưu tập rác. Việc kê khai voodo bạn sử dụng là:

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

Nếu bạn làm điều này, sau đó tất cả (100K của) bộ nhớ phân bổ cho các đối tượng Blah trỏ đến bởi con trỏ Foo sẽ được dọn dẹp khi loại Foo đi ra khỏi phạm vi. Vì Ada cho phép bạn lồng các chương trình con bên trong các chương trình con khác, điều này đặc biệt mạnh mẽ.

Để xem chi tiết về những gì STORAGE_SIZE và lưu trữ hồ có thể làm cho bạn, hãy xem LRM 13.11

Bốn là, các chương trình Ada tốt bằng văn bản không có xu hướng dựa trên cấp phát bộ nhớ động gần càng nhiều càng tốt các chương trình C làm. C có một số lỗ thiết kế mà những người thực hành đã học cách sử dụng con trỏ để tô màu. Rất nhiều thành ngữ đó không phải là không cần thiết ở Ada.

Answer 5

Trước hết, tôi muốn biết ai đang sử dụng Ada những ngày này. Tôi thực sự thích ngôn ngữ, và thậm chí còn có một thư viện GUI cho Linux/Ada, nhưng tôi đã không nghe bất cứ điều gì về hoạt động phát triển Ada trong nhiều năm. Nhờ vào các kết nối quân sự, tôi thực sự không chắc liệu lịch sử cổ đại hay thành công vang dội đến mức tất cả các đề cập đến việc sử dụng nó đều được phân loại.

Tôi nghĩ có một vài lý do không có GC trong Ada. Đầu tiên, và quan trọng nhất, nó ngày trở lại một kỷ nguyên mà hầu hết các ngôn ngữ biên dịch được sử dụng chủ yếu là ngăn xếp hoặc bộ nhớ tĩnh, hoặc trong một vài trường hợp, phân bổ heap rõ ràng/miễn phí. GC như một triết lý chung thực sự chỉ mất khoảng năm 1990 hoặc lâu hơn, khi OOP, các thuật toán và bộ xử lý quản lý bộ nhớ được cải thiện đủ mạnh để phụ tùng các chu kỳ chạy tất cả đều tự hoạt động. Điều đơn giản biên dịch Ada có thể làm cho một máy tính lớn IBM 4331 vào năm 1989 đơn giản là tàn nhẫn. Bây giờ tôi có một chiếc điện thoại di động có thể hoạt động tốt hơn CPU của máy.

Một lý do khác là có những người nghĩ rằng thiết kế chương trình nghiêm ngặt bao gồm kiểm soát chính xác tài nguyên bộ nhớ, và không nên có bất kỳ sự khoan dung nào khi cho phép các đối tượng động bị nổi. Đáng buồn thay, quá nhiều người đã bị rò rỉ bộ nhớ khi bộ nhớ động ngày càng trở nên thống trị hơn. Ngoài ra, giống như "hiệu quả" của ngôn ngữ lắp ráp trên các ngôn ngữ cấp cao và "hiệu quả" của JDBC thô trên các hệ thống ORM, "hiệu quả" của quản lý bộ nhớ thủ công có xu hướng đảo ngược khi nó tăng lên (tôi đã thấy các tiêu chuẩn ORM nơi tương đương JDBC chỉ bằng một nửa hiệu quả). Counter-online, tôi biết, nhưng những hệ thống này ngày càng tốt hơn ở việc tối ưu hóa toàn cầu các ứng dụng lớn, cộng với chúng có thể làm cho việc tối ưu hóa lại triệt để theo những thay đổi nhỏ bề ngoài. tải.

Tôi sợ rằng tôi sẽ phải khác với những người nói rằng hệ thống thời gian thực không thể đủ khả năng cho bộ nhớ GC. GC không còn là thứ bị đóng băng toàn bộ hệ thống sau mỗi vài phút. Chúng tôi có nhiều cách thông minh hơn để đòi lại bộ nhớ những ngày này.

Answer 6

Câu hỏi của bạn không đúng. Nó có. Xem ada.finalization gói xử lý GC cho bạn.

Answer 7

tôi nghĩ rằng tôi muốn chia sẻ một ví dụ thực sự đơn giản về cách để thực hiện một thủ tục miễn phí() (mà sẽ được sử dụng theo cách quen thuộc đối với tất cả các lập trình viên 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; 

Gọi miễn phí tại phần cuối của chương trình sẽ trả về Integer được cấp phát cho Storage Pool ("heap" trong C parlance). Bạn có thể sử dụng valgrind để chứng minh rằng điều này thực tế ngăn 4 byte bộ nhớ bị rò rỉ.

Ada.Unchecked_Deallocation (quy trình được xác định chung) có thể được sử dụng trên (tôi nghĩ) bất kỳ loại nào có thể được phân bổ bằng từ khóa "mới". Sách hướng dẫn tham khảo Ada ("13.11.2 Bỏ phiếu lưu trữ không được kiểm soát") có thêm chi tiết.