Tại sao Khối Đối tượng Lớn và tại sao chúng ta quan tâm?

Tôi đã đọc về Generations và Large object heap. Nhưng tôi vẫn không hiểu ý nghĩa (hoặc lợi ích) của việc có đống đối tượng Lớn là gì?

Điều gì có thể đã xảy ra (về hiệu suất hoặc bộ nhớ) nếu CLR chỉ dựa vào Thế hệ 2 (Xem xét rằng ngưỡng cho Gen0 và Gen1 là nhỏ để xử lý các đối tượng lớn) để lưu trữ các đối tượng lớn?

Một bộ sưu tập rác không chỉ loại bỏ các đối tượng không được tham chiếu, nó còn thu gọn đống. Đó là một tối ưu hóa rất quan trọng. Nó không chỉ làm cho việc sử dụng bộ nhớ hiệu quả hơn (không có lỗ không sử dụng) mà còn làm cho bộ nhớ cache của CPU hiệu quả hơn nhiều. Bộ nhớ đệm thực sự là một vấn đề lớn trên các bộ vi xử lý hiện đại, chúng nhanh hơn so với bus bộ nhớ.

Việc thu gọn được thực hiện đơn giản bằng cách sao chép các byte. Tuy nhiên điều đó cần có thời gian. Đối tượng càng lớn, càng có nhiều khả năng chi phí sao chép nó cao hơn các cải tiến khả năng sử dụng bộ đệm CPU.

Vì vậy, họ đã chạy một loạt các điểm chuẩn để xác định điểm hòa vốn. Và đạt 85.000 byte là điểm giới hạn mà việc sao chép không còn cải thiện hiệu suất. Với một ngoại lệ đặc biệt đối với mảng kép, chúng được coi là 'lớn' khi mảng có hơn 1000 phần tử. Đó là một cách tối ưu hóa khác cho mã 32-bit, bộ phân bổ heap đối tượng lớn có thuộc tính đặc biệt là nó phân bổ bộ nhớ tại các địa chỉ được căn chỉnh thành 8, không giống như bộ cấp phát thế hệ thông thường chỉ phân bổ căn chỉnh cho 4. Việc căn chỉnh đó là một vấn đề lớn đối với , đọc hoặc viết một đôi không căn chỉnh rất tốn kém. Điều kỳ lạ là thông tin Microsoft thưa thớt không bao giờ đề cập đến các mảng dài, không chắc chắn về điều đó.

Fwiw, có rất nhiều lập trình viên lo lắng về việc đống đối tượng lớn không được nén chặt. Điều này luôn được kích hoạt khi họ viết các chương trình sử dụng hơn một nửa toàn bộ không gian địa chỉ có sẵn. Tiếp theo là sử dụng một công cụ như trình biên dịch bộ nhớ để tìm hiểu lý do tại sao chương trình bị đánh bom mặc dù vẫn còn rất nhiều bộ nhớ ảo chưa sử dụng. Một công cụ như vậy cho thấy các lỗ hổng trong LOH, các phần bộ nhớ không được sử dụng, nơi trước đây có một vật thể lớn sống nhưng đã bị thu gom rác. Đó là cái giá không thể tránh khỏi của LOH, lỗ chỉ có thể được sử dụng lại bằng cách phân bổ cho một đối tượng có kích thước bằng hoặc nhỏ hơn. Vấn đề thực sự là giả định rằng một chương trình nên được phép sử dụng tất cả bộ nhớ ảo bất kỳ lúc nào.

Nếu không, một vấn đề sẽ biến mất hoàn toàn bằng cách chỉ chạy mã trên hệ điều hành 64 bit. Quá trình 64 bit có sẵn 8 terabyte không gian địa chỉ bộ nhớ ảo, nhiều hơn 3 bậc so với quy trình 32 bit. Bạn chỉ không thể chạy ra khỏi lỗ.

Tóm lại, LOH làm cho mã chạy hiệu quả hơn. Với chi phí sử dụng không gian địa chỉ bộ nhớ ảo có sẵn kém hiệu quả hơn.

UPDATE, .NET 4.5.1 hiện hỗ trợ nén thuộc tính LOH , GCSettings.LargeObjectHeapCompactionMode . Vui lòng coi chừng hậu quả.

Nếu kích thước của đối tượng lớn hơn một số giá trị được ghim (85000 byte trong .NET 1), thì CLR sẽ đặt nó trong Large Object Heap. Điều này tối ưu hóa:

1. Phân bổ đối tượng (đối tượng nhỏ không bị trộn lẫn với đối tượng lớn)
2. Thu gom rác (chỉ thu gom LOH trên GC đầy đủ)
3. Chống phân mảnh bộ nhớ (LOH không bao giờ hiếm khi bị nén)

Sự khác biệt cơ bản của đống đối tượng nhỏ (SOH) và đống đối tượng lớn (LOH) là, bộ nhớ trong SOH được nén lại khi được thu thập, trong khi LOH thì không, như bài viết này minh họa. Việc nén các vật lớn sẽ tốn rất nhiều chi phí. Tương tự với các ví dụ trong bài viết, giả sử di chuyển một byte trong bộ nhớ cần 2 chu kỳ, sau đó nén một đối tượng 8MB trong máy tính 2GHz cần 8ms, đây là một chi phí lớn. Xem xét các đối tượng lớn (mảng trong hầu hết các trường hợp) là khá phổ biến trong thực tế, tôi cho rằng đó là lý do tại sao Microsoft ghim các đối tượng lớn trong bộ nhớ và đề xuất LOH.

BTW, theo bài đăng này , LOH thường không tạo ra các vấn đề về phân mảnh bộ nhớ.

Nguyên nhân chính là không có khả năng xảy ra (và có thể là thiết kế tồi) rằng một quy trình sẽ tạo ra nhiều đối tượng lớn có tuổi thọ ngắn để CLR phân bổ các đối tượng lớn vào một đống riêng biệt mà trên đó nó chạy GC theo một lịch trình khác với đống thông thường. http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

Tôi không phải là chuyên gia về CLR, nhưng tôi sẽ tưởng tượng rằng việc có một heap chuyên dụng cho các đối tượng lớn có thể ngăn chặn việc quét GC không cần thiết đối với các heap thế hệ hiện có. Việc phân bổ một đối tượng lớn yêu cầu một lượng lớn bộ nhớ trống liền kề . Để cung cấp điều đó từ các "lỗ hổng" nằm rải rác trong đống thế hệ, bạn cần các giao dịch thường xuyên (chỉ được thực hiện với các chu kỳ GC).