Khi một trình thu gom rác nén các đối tượng trong heap, nó có thay đổi các tham chiếu trên ngăn xếp không?


18

Đây có vẻ là một câu hỏi đơn giản, nhưng sau khi đọc rất nhiều về chủ đề này, tôi vẫn không tìm thấy câu trả lời dứt khoát (có lẽ vì nó quá đơn giản).

Câu hỏi của tôi là: khi một trình thu gom rác thu gọn các đối tượng trong heap, các tham chiếu đến các đối tượng đó trong ngăn xếp được cập nhật như thế nào? Tôi có thể nghĩ về hai giải pháp khả thi:

  1. Đi qua ngăn xếp (và các tham chiếu trong heap) và cập nhật tham chiếu để trỏ đến vị trí mới của đối tượng. Tương tự như việc di chuyển, điều này sẽ giống như gửi thư cho bất kỳ ai có địa chỉ của bạn và yêu cầu họ cập nhật sổ địa chỉ của họ với địa chỉ mới của bạn.
  2. Cung cấp một số loại tra cứu bảng. Điều này sẽ giống như để lại một địa chỉ chuyển tiếp với bưu điện địa phương.

Do người thu gom rác chủ yếu sử dụng một trong hai phương pháp này? Một số phương pháp khác? Cả hai?



@StevenBurnap sửa tôi nếu tôi sai, nhưng tôi tin rằng chủ đề bạn liên kết đến không có bất kỳ câu trả lời dứt khoát nào. Họ dường như cũng đang suy đoán về câu hỏi chính xác này. Tôi có thể đã đọc sai. Nếu họ đã cung cấp câu trả lời cho câu hỏi, nếu bạn không phiền, tôi nghĩ sẽ rất hữu ích khi tóm tắt câu trả lời ở đây cho người dùng SE tương lai (và bản thân tôi!)
todorojo

Thuật ngữ cho điều bạn đang nói đến là "trình thu gom rác di chuyển". Tôi thực sự không biết chúng thường được sử dụng như thế nào.
Gort Robot

Câu trả lời:


9

Tôi không có chuyên môn cụ thể về điều này, nhưng sự hiểu biết của tôi là phương pháp đầu tiên thường được sử dụng.

Trình thu gom rác phải phân tích các ngăn xếp ngăn xếp để tìm ra những thứ trong đống được đề cập đến từ ngăn xếp. Một khi nó quyết định di chuyển một cái gì đó, nó phải sửa các tham chiếu đến nó bằng mọi cách, và không có lý do gì để phân biệt giữa heap và stack tại thời điểm đó.

Cách tiếp cận bảng tra cứu về nguyên tắc có thể làm việc. Tuy nhiên, điều đó sẽ làm cho tất cả các truy cập con trỏ cần phải thực hiện 2 bước. Đó sẽ là một tác động hiệu suất rất lớn trong thời gian chạy bình thường. Riêng đối với trường hợp sử dụng của nhiều đối tượng nhỏ. (Đó là trường hợp các chương trình GC hiện đại thường đánh bại việc đếm tham chiếu.)


3
Tôi sẽ nói thêm rằng tôi nghĩ có lẽ cố gắng không di chuyển mọi thứ trên đống trừ khi họ phải làm vậy. Trong thế giới đa bộ xử lý ngày nay, đó phải là một cơn ác mộng đồng bộ hóa khi họ cần cập nhật tất cả các tham chiếu đến một cái gì đó trong heap trong khi một chương trình sử dụng các tham chiếu đó đang chạy. Bảng tra cứu sẽ đơn giản hóa việc này, nhưng tôi nghĩ đó là ngoại lệ chứ không phải là tiêu chuẩn, vì vậy hầu hết các GC có thể phải khóa một số tài liệu tham khảo, di chuyển bộ nhớ, sau đó cập nhật các tài liệu tham khảo. +1 Câu hỏi thú vị, +1 câu trả lời hay.
GlenPeterson

3
@GlenPeterson Nhiều GC thực sự không di chuyển mọi thứ trên đống, và không phải đối mặt với vấn đề này. Nhưng một định nghĩa nén của GC theo định nghĩa sẽ di chuyển các đối tượng sống xung quanh để chống phân mảnh bộ nhớ.
btilly

@GlenPeterson đó là một quan sát tốt rằng việc di chuyển các công cụ trên heap là một nỗi đau đồng bộ hóa rất lớn, điều này bị bỏ qua mặc dù việc nén GC có hiệu ứng gợn lớn trong quá trình chạy do điều này. Đó là lý do lớn nhất mà mọi người được yêu cầu làm mọi thứ có thể để giữ cho các vật thể tồn tại trong thời gian ngắn nhất có thể, để tránh các bản cập nhật heap lớn gây ra sự nén chặt giữ một cuộc đột biến dài. Sự thiếu hiểu biết về cách thức hoạt động của công cụ này có thể dẫn đến cái được gọi một cách đáng yêu là Chế độ Freakout của GC.
Jimmy Hoffa

2
Cả Macintosh và Palm OS ban đầu đều sử dụng cách tiếp cận bảng tra cứu để quản lý bộ nhớ. Con trỏ vào bảng được gọi là tay cầm. Một GC di dời phải biết nơi ở hoàn toàn tích cực mọi tham chiếu đến bất kỳ đối tượng nào mà nó di chuyển; sử dụng một bảng duy nhất cho các mục đích như vậy đơn giản hóa mọi thứ rất nhiều.
supercat
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.