Làm thế nào để thu gom rác hoạt động trong các ngôn ngữ được biên dịch nguyên bản?

Sau khi duyệt một số câu trả lời Stack Overflow, rõ ràng một số ngôn ngữ được biên dịch nguyên bản có bộ sưu tập rác . Nhưng tôi không rõ chính xác nó sẽ hoạt động như thế nào.

Tôi hiểu làm thế nào bộ sưu tập rác có thể làm việc với một ngôn ngữ diễn giải. Trình thu gom rác đơn giản sẽ chạy cùng với trình thông dịch và xóa các đối tượng không sử dụng và không thể truy cập khỏi bộ nhớ của chương trình. Cả hai đang chạy cùng nhau.

Làm thế nào điều này sẽ làm việc với các ngôn ngữ biên dịch mặc dù? Tôi hiểu rằng một khi trình biên dịch đã biên dịch mã nguồn thành mã đích - cụ thể là mã máy gốc - nó đã được thực hiện. Công việc của nó đã kết thúc. Vì vậy, làm thế nào chương trình biên dịch có thể được thu thập rác?

Trình biên dịch có hoạt động với CPU theo một cách nào đó trong khi chương trình được thực thi để xóa các đối tượng "rác" không? Hoặc trình biên dịch có bao gồm một số trình thu gom rác tối thiểu trong tệp thực thi của chương trình đã biên dịch.

Tôi tin rằng tuyên bố sau của tôi sẽ có giá trị hơn so với tuyên bố trước do đoạn trích này từ câu trả lời này trên Stack Overflow :

Một ngôn ngữ lập trình như vậy là Eiffel. Hầu hết các trình biên dịch Eiffel tạo mã C vì lý do tính di động. Mã C này được sử dụng để sản xuất mã máy bằng trình biên dịch C tiêu chuẩn. Việc triển khai Eiffel cung cấp GC (và đôi khi thậm chí là chính xác) cho mã được biên dịch này và không cần VM. Cụ thể, trình biên dịch VisualEiffel đã tạo mã máy x86 riêng trực tiếp với sự hỗ trợ đầy đủ của GC .

Câu lệnh cuối cùng dường như ngụ ý rằng trình biên dịch bao gồm một số chương trình trong tệp thực thi cuối cùng hoạt động như một trình thu gom rác trong khi chương trình đang chạy.

Trang trên trang web của ngôn ngữ D về bộ sưu tập rác - được biên soạn nguyên bản và có trình thu gom rác tùy chọn - dường như cũng gợi ý rằng một số chương trình nền chạy cùng với chương trình thực thi ban đầu để thực hiện thu gom rác.

D là ngôn ngữ lập trình hệ thống có hỗ trợ thu gom rác. Thông thường không cần thiết phải giải phóng bộ nhớ rõ ràng. Chỉ cần phân bổ khi cần và trình thu gom rác sẽ định kỳ trả lại tất cả bộ nhớ chưa sử dụng cho nhóm bộ nhớ khả dụng.

Nếu phương pháp được đề cập ở trên được sử dụng, chính xác thì nó sẽ hoạt động như thế nào? Trình biên dịch có lưu một bản sao của một số chương trình thu gom rác và dán nó vào mỗi tệp thực thi mà nó tạo ra không?

Hay tôi là thiếu sót trong suy nghĩ của tôi? Nếu vậy, phương pháp nào được sử dụng để thực hiện thu gom rác cho các ngôn ngữ được biên dịch và chính xác chúng sẽ hoạt động như thế nào?

Bộ sưu tập rác trong một ngôn ngữ được biên dịch hoạt động giống như trong một ngôn ngữ được giải thích. Các ngôn ngữ như Go sử dụng theo dõi bộ thu gom rác mặc dù mã của chúng thường được biên dịch theo mã máy trước thời hạn.

(Truy tìm) bộ sưu tập rác thường bắt đầu bằng cách đi bộ ngăn xếp cuộc gọi của tất cả các luồng hiện đang chạy. Các đối tượng trên các ngăn xếp luôn luôn sống. Sau đó, trình thu gom rác đi qua tất cả các đối tượng được chỉ ra bởi các đối tượng sống, cho đến khi toàn bộ biểu đồ đối tượng sống được phát hiện.

Rõ ràng là làm điều này đòi hỏi thêm thông tin mà các ngôn ngữ như C không cung cấp. Cụ thể, nó yêu cầu một bản đồ của khung ngăn xếp của từng hàm chứa phần bù của tất cả các con trỏ (và có thể là kiểu dữ liệu của chúng) cũng như bản đồ của tất cả các bố cục đối tượng có cùng thông tin.

Tuy nhiên, thật dễ dàng để thấy rằng các ngôn ngữ có bảo đảm loại mạnh (ví dụ: nếu các con trỏ chuyển sang các kiểu dữ liệu khác nhau không được phép) thực sự có thể tính toán các bản đồ đó trong thời gian biên dịch. Họ chỉ đơn giản là lưu trữ một liên kết giữa các địa chỉ lệnh và các bản đồ khung ngăn xếp và một liên kết giữa các kiểu dữ liệu và bản đồ bố trí đối tượng bên trong nhị phân. Thông tin này sau đó cho phép họ thực hiện duyệt đồ thị đối tượng.

Bản thân trình thu gom rác không gì khác hơn là một thư viện được liên kết với chương trình, tương tự như thư viện chuẩn C. Ví dụ, thư viện này có thể cung cấp một hàm tương tự như malloc()chạy thuật toán thu thập nếu áp suất bộ nhớ cao.

Trình biên dịch có lưu một bản sao của một số chương trình thu gom rác và dán nó vào mỗi tệp thực thi mà nó tạo ra không?

Nghe có vẻ không hợp lý và kỳ lạ, nhưng có. Trình biên dịch có toàn bộ thư viện tiện ích, chứa nhiều hơn cả mã bộ sưu tập rác và các lệnh gọi đến thư viện này sẽ được chèn vào mỗi tệp thực thi mà nó tạo ra. Đây được gọi là thư viện thời gian chạy và bạn sẽ ngạc nhiên về số lượng nhiệm vụ khác nhau mà nó thường phục vụ.

Hoặc trình biên dịch có bao gồm một số trình thu gom rác tối thiểu trong mã của chương trình được biên dịch.

Đó là một cách kỳ quặc để nói rằng trình biên dịch liên kết chương trình với một thư viện thực hiện bộ sưu tập rác. Nhưng vâng, đó là những gì đang xảy ra.

Điều này không có gì đặc biệt: trình biên dịch thường liên kết hàng tấn thư viện vào các chương trình họ biên dịch; mặt khác, các chương trình được biên dịch không thể làm được gì nhiều mà không thực hiện lại nhiều thứ từ đầu: thậm chí viết văn bản lên màn hình / một tệp / cảm biến yêu cầu một thư viện.

Nhưng có lẽ GC khác với các thư viện khác, nơi cung cấp các API rõ ràng mà người dùng gọi?

Không: trong hầu hết các ngôn ngữ, các thư viện thời gian chạy thực hiện rất nhiều công việc hậu trường mà không cần API công khai, ngoài GC. Hãy xem xét ba ví dụ sau:

1. Tuyên truyền ngoại lệ và ngăn xếp gọi / hủy bỏ cuộc gọi.
2. Cấp phát bộ nhớ động (thường không chỉ gọi một hàm, như trong C, ngay cả khi không có bộ sưu tập rác).
3. Theo dõi thông tin loại động (đối với phôi vv).

Vì vậy, một thư viện thu gom rác hoàn toàn không có gì đặc biệt, và một tiên nghiệm không liên quan gì đến việc liệu một chương trình có được biên soạn trước thời hạn hay không.

Làm thế nào điều này sẽ làm việc với các ngôn ngữ biên dịch mặc dù?

Từ ngữ của bạn là sai. Một ngôn ngữ lập trình là một đặc điểm kỹ thuật bằng văn bản trong một số báo cáo kỹ thuật (đối với một ví dụ tốt, xem R5RS ). Trên thực tế, bạn đang đề cập đến một số thực hiện ngôn ngữ cụ thể (đó là một phần mềm).

^{(một số ngôn ngữ lập trình có thông số kỹ thuật xấu hoặc thậm chí thiếu ngôn ngữ hoặc chỉ tuân thủ một số triển khai mẫu; ngôn ngữ lập trình xác định hành vi - ví dụ: nó có cú pháp và ngữ nghĩa -, nó không phải là sản phẩm phần mềm, nhưng có thể là được triển khai bởi một số sản phẩm phần mềm, nhiều ngôn ngữ lập trình có một số triển khai, đặc biệt, "được biên dịch" là một tính từ áp dụng cho việc triển khai - ngay cả khi một số ngôn ngữ lập trình được trình thông dịch thực hiện dễ dàng hơn so với trình biên dịch.)}

Tôi hiểu rằng một khi trình biên dịch đã biên dịch mã nguồn thành mã đích - cụ thể là mã máy gốc - nó đã được thực hiện. Công việc của nó đã kết thúc.

Lưu ý rằng trình thông dịch và trình biên dịch có nghĩa lỏng lẻo và một số triển khai ngôn ngữ có thể được coi là cả hai. Nói cách khác, có một sự liên tục ở giữa. Đọc Sách Rồng mới nhất và suy nghĩ về mã byte , biên dịch JIT , mã động phát ra mã C được biên dịch thành một số "plugin" sau đó dlopen (3) -ed theo cùng một quy trình (và trên các máy hiện tại, điều này đủ nhanh để tương thích với một REPL tương tác , xem cái này )

Tôi thực sự khuyên bạn nên đọc cẩm nang GC . Toàn bộ cuốn sách là cần thiết để trả lời . Trước đó, hãy đọc wiki của Bộ sưu tập Rác (mà tôi cho rằng bạn đã đọc trước khi đọc bên dưới).

Các hệ thống thời gian chạy của việc thực hiện ngôn ngữ biên dịch chứa thu gom rác, và trình biên dịch được tạo mã đó là phù hợp với hệ thống thời gian chạy cụ thể. Cụ thể, các nguyên hàm cấp phát (được biên dịch theo mã máy) sẽ (hoặc có thể) gọi hệ thống thời gian chạy.

Vì vậy, làm thế nào chương trình biên dịch có thể được thu thập rác?

Chỉ bằng cách phát ra mã máy sử dụng (và "thân thiện" và "tương thích với") hệ thống thời gian chạy.

Lưu ý rằng bạn có thể tìm thấy một số thư viện thu gom rác, đặc biệt là Boehm GC , Ravenbrook's MPS hoặc thậm chí là Qish (không rõ ràng) của tôi . Và mã hóa một GC đơn giản không phải là rất khó (tuy nhiên, việc gỡ lỗi nó khó hơn và mã hóa một GC cạnh tranh là khó khăn ).

Trong một số trường hợp, trình biên dịch sẽ sử dụng một GC bảo thủ (như Boehm GC ). Sau đó, không có nhiều để mã. GC bảo thủ sẽ (khi trình biên dịch gọi thủ tục cấp phát của nó hoặc toàn bộ thường trình GC) đôi khi quét toàn bộ ngăn xếp cuộc gọi và cho rằng mọi vùng nhớ (gián tiếp) có thể truy cập được từ ngăn xếp cuộc gọi đều hoạt động. Đây được gọi là một GC bảo thủ vì thông tin gõ bị mất: nếu một số nguyên trên ngăn xếp cuộc gọi xảy ra trông giống như một số địa chỉ, nó sẽ được theo dõi, v.v.

Trong các trường hợp khác (khó khăn hơn), bộ thực thi cung cấp một bộ sưu tập rác sao chép thế hệ (một ví dụ điển hình là trình biên dịch Ocaml, biên dịch mã Ocaml thành mã máy bằng cách sử dụng một GC như vậy). Sau đó, vấn đề là tìm chính xác trên ngăn xếp cuộc gọi tất cả các con trỏ và một số trong số chúng được di chuyển bởi GC. Sau đó, trình biên dịch tạo ra siêu dữ liệu mô tả các khung ngăn xếp cuộc gọi mà thời gian chạy sử dụng. Vì vậy, các quy ước gọi và ABI đang trở nên cụ thể cho việc thực hiện đó (tức là trình biên dịch) & hệ thống thời gian chạy.

Trong một số trường hợp, mã máy được tạo bởi trình biên dịch (thực tế thậm chí đóng chỉ vào nó) chính là rác được thu thập . Đây là trường hợp đáng chú ý đối với SBCL (một triển khai Lisp thông thường tốt) tạo mã máy cho mỗi tương tác REPL . Điều này cũng yêu cầu một số dữ liệu meta mô tả mã và các khung cuộc gọi được sử dụng bên trong nó.

Trình biên dịch có lưu một bản sao của một số chương trình thu gom rác và dán nó vào mỗi tệp thực thi mà nó tạo ra không?

Sắp xếp Tuy nhiên, hệ thống thời gian chạy có thể là một thư viện dùng chung, v.v. Đôi khi (trên Linux và một số hệ thống POSIX khác), nó thậm chí có thể là một trình thông dịch kịch bản, ví dụ: được chuyển qua execve (2) với một shebang . Hoặc một thông dịch viên ELF , xem elf (5) và PT_INTERP, v.v.

BTW, hầu hết các trình biên dịch cho ngôn ngữ với bộ sưu tập rác (và hệ thống thời gian chạy của chúng) là phần mềm miễn phí ngày nay . Vì vậy, tải về mã nguồn và nghiên cứu nó.

Đã có một số câu trả lời hay, nhưng tôi muốn xóa một số hiểu lầm đằng sau câu hỏi này.

Không có thứ gọi là "ngôn ngữ được biên dịch tự nhiên" mỗi se. Ví dụ, cùng một mã Java đã được diễn giải (và sau đó được biên dịch một phần chỉ trong thời gian chạy) trên điện thoại cũ của tôi (Java Dalvik) và được biên dịch trước thời hạn trên điện thoại mới của tôi (ART).

Sự khác biệt giữa chạy mã nguyên bản và diễn giải ít nghiêm ngặt hơn nhiều so với vẻ ngoài của nó. Cả hai đều cần một số thư viện thời gian chạy và một số hệ điều hành để làm việc (*). Mã thông dịch cần một trình thông dịch, nhưng trình thông dịch chỉ là một phần của thời gian chạy. Nhưng ngay cả điều này không nghiêm ngặt, vì bạn có thể thay thế trình thông dịch bằng trình biên dịch (chỉ trong thời gian). Để có hiệu suất tối đa, bạn có thể muốn cả hai (thời gian chạy Java trên máy tính để bàn chứa trình thông dịch và hai trình biên dịch).

Bất kể làm thế nào để chạy mã, nó nên hành xử như nhau. Phân bổ và giải phóng bộ nhớ là một nhiệm vụ cho thời gian chạy (giống như mở tệp, bắt đầu các luồng, v.v.). Trong ngôn ngữ của bạn, bạn chỉ cần viết new X()hoặc như nhau. Đặc tả ngôn ngữ cho biết những gì sẽ xảy ra và thời gian chạy thực hiện nó.

Một số bộ nhớ trống được cấp phát, hàm tạo được gọi, v.v. Khi không có đủ bộ nhớ, thì trình thu gom rác sẽ được gọi. Vì bạn đã có trong thời gian chạy, là một đoạn mã riêng, sự tồn tại của một trình thông dịch hoàn toàn không thành vấn đề.

Thực sự không có kết nối trực tiếp giữa phiên dịch mã và thu gom rác. Chỉ có các ngôn ngữ cấp thấp như C được thiết kế để kiểm soát tốc độ và chi tiết tốt mọi thứ, không phù hợp với ý tưởng về mã không bản địa hoặc trình thu gom rác. Vì vậy, chỉ có một mối tương quan.

Điều này rất đúng trong thời xưa, trong đó, ví dụ trình thông dịch Java rất chậm và trình thu gom rác khá kém hiệu quả. Ngày nay, mọi thứ đã khác đi rất nhiều và việc nói về một ngôn ngữ được giải thích đã mất đi mọi ý nghĩa.

(*) Ít nhất là khi nói về mã mục đích chung, hãy bỏ qua các bộ tải khởi động và tương tự.

Các chi tiết khác nhau giữa các lần triển khai, nhưng nhìn chung một số kết hợp sau:

• Một thư viện thời gian chạy bao gồm một GC. Điều này sẽ xử lý cấp phát bộ nhớ và có một số điểm nhập khác, bao gồm chức năng "GC_now".
• Trình biên dịch sẽ tạo các bảng cho GC để nó biết các trường trong đó các kiểu dữ liệu được tham chiếu. Điều này cũng sẽ được thực hiện cho các khung ngăn xếp cho từng chức năng để GC có thể theo dõi từ ngăn xếp.
• Nếu GC tăng dần (hoạt động của GC được xen kẽ với chương trình) hoặc đồng thời (chạy trong một luồng riêng) thì trình biên dịch cũng sẽ bao gồm mã đối tượng đặc biệt để cập nhật cấu trúc dữ liệu GC khi các tham chiếu được cập nhật. Hai có vấn đề tương tự cho sự thống nhất dữ liệu.

Trong GC tăng dần và đồng thời, mã được biên dịch và GC cần hợp tác để duy trì một số bất biến. Ví dụ, trong trình thu thập sao chép, GC hoạt động bằng cách sao chép dữ liệu trực tiếp từ không gian A sang không gian B, để lại rác. Đối với chu kỳ tiếp theo, nó lật A và B và lặp lại. Vì vậy, một quy tắc có thể là đảm bảo rằng bất cứ khi nào chương trình người dùng cố gắng tham chiếu đến một đối tượng trong không gian A, điều này được phát hiện và đối tượng được sao chép ngay lập tức vào không gian B, nơi chương trình có thể tiếp tục truy cập vào nó. Một địa chỉ chuyển tiếp được để lại trong không gian A để chỉ ra cho GC rằng điều này đã xảy ra để mọi tham chiếu khác đến đối tượng được cập nhật khi chúng được theo dõi. Điều này được gọi là một "rào cản đọc".

Các thuật toán GC đã được nghiên cứu từ những năm 60, và có nhiều tài liệu về chủ đề này. Google nếu bạn muốn biết thêm thông tin.