Máy ảo Java có di chuyển các đối tượng trong bộ nhớ và nếu như vậy - như thế nào?

Question

Máy ảo Java có bao giờ di chuyển các đối tượng trong bộ nhớ hay không, và nếu như vậy, nó xử lý việc cập nhật các tham chiếu đến đối tượng được di chuyển như thế nào?

Tôi hỏi vì tôi đang khám phá ý tưởng lưu trữ các đối tượng theo kiểu phân phối (nghĩa là trên nhiều máy chủ), nhưng tôi cần khả năng di chuyển đối tượng giữa các máy chủ vì lý do hiệu quả. Các đối tượng cần có khả năng chứa các con trỏ đến nhau, ngay cả đối tượng trên các máy chủ từ xa. Tôi đang cố gắng nghĩ cách tốt nhất để cập nhật các tham chiếu đến các đối tượng được di chuyển.

hai ý tưởng của tôi cho đến nay là:

1. Duy trì một nơi tham khảo gián tiếp mà không di chuyển cho các đời của đối tượng, mà chúng tôi cập nhật nếu di chuyển đối tượng. Nhưng - những indirections này được quản lý như thế nào?
2. Giữ một danh sách các tham chiếu ngược với từng đối tượng, vì vậy chúng tôi biết những gì phải được cập nhật nếu đối tượng được di chuyển. Tất nhiên, điều này tạo ra một chi phí hiệu suất.

Tôi muốn được quan tâm đến phản hồi về các phương pháp này và mọi đề xuất cho các phương pháp thay thế khác.

Answer 1

Trong tham chiếu đến nhận xét ở trên về việc đi bộ vùng heap.

Các GC khác nhau thực hiện theo các cách khác nhau.

Thường sao chép người thu thập khi họ đi bộ đống, họ không đi bộ tất cả các đối tượng trong heap. Thay vào đó họ đi bộ các đối tượng LIVE trong heap. Hàm ý là nếu nó có thể truy cập được từ đối tượng "root", thì đối tượng đó đang hoạt động.

Vì vậy, ở giai đoạn này là phải chạm vào tất cả các đối tượng trực tiếp, vì nó sao chép chúng từ đống cũ sang vùng mới. Một khi bản sao của các đối tượng trực tiếp được thực hiện, tất cả những gì còn lại trong heap cũ là một trong hai đối tượng đã được sao chép, hoặc rác. Tại thời điểm đó, đống cũ có thể được loại bỏ hoàn toàn.

Hai lợi ích chính của loại nhà sưu tập này là nó thu gọn heap trong giai đoạn sao chép và chỉ sao chép các đối tượng sống. Điều này rất quan trọng đối với nhiều hệ thống vì với kiểu thu gom này, phân bổ đối tượng là rẻ tiền, nghĩa đen ít hơn là tăng thêm một con trỏ heap. Khi GC xảy ra, không có đối tượng "chết" nào được sao chép, vì vậy chúng không làm chậm bộ thu thập. Nó cũng hóa ra trong các hệ thống năng động mà có rất nhiều, ít rác thải tạm thời, hơn là có rác thải đứng lâu.

Ngoài ra, bằng cách đi biểu đồ đối tượng trực tiếp, bạn có thể xem cách GC có thể "biết" về mọi đối tượng và theo dõi chúng cho bất kỳ mục đích điều chỉnh địa chỉ nào được thực hiện trong bản sao.

Đây không phải là diễn đàn để nói sâu về cơ khí GC, vì nó là một vấn đề không tầm thường, nhưng đó là những điều cơ bản về cách thức hoạt động của một nhà sưu tập sao chép.

GC sao chép thế hệ sẽ đặt các đối tượng "cũ hơn" trong các vùng khác nhau và những kết quả được thu thập ít thường xuyên hơn các vùng "mới hơn". Lý thuyết là các đối tượng lâu dài được thăng chức cho các thế hệ cũ hơn và được thu thập ít hơn, ít hơn, cải thiện hiệu suất tổng thể của GC.

Answer 2

(Thực tế) Bất kỳ hệ thống thu gom rác nào cũng phải di chuyển các vật thể xung quanh trong bộ nhớ để đóng gói chúng nhiều hơn và tránh các vấn đề phân mảnh.

Điều bạn đang xem là một chủ đề rất lớn và phức tạp. Tôi khuyên bạn nên đọc về các API kiểu đối tượng từ xa hiện có: .NET remoting và tiếp tục công nghệ trở lại như CORBA

Bất kỳ giải pháp nào để theo dõi các tham chiếu sẽ phức tạp bằng cách xử lý tất cả các chế độ lỗi tồn tại trong phân phối hệ thống. Các JVM không phải lo lắng về việc đột nhiên tìm thấy nó không thể nhìn thấy một nửa đống của nó bởi vì một chuyển đổi mạng bị trục trặc.

Khi bạn đi sâu vào thiết kế, tôi nghĩ rằng rất nhiều nó sẽ đi xuống đến cách bạn muốn xử lý các trường hợp lỗi khác nhau.

Response to comments:

cuộc đàm phán Câu hỏi của bạn về việc lưu trữ các đối tượng trong một thời trang phân phối, đó là chính xác những gì .NET Remoting và CORBA địa chỉ. Phải thừa nhận rằng cả hai công nghệ đều không hỗ trợ di chuyển các đối tượng này (AFAIK). Nhưng cả hai đều đối phó rộng rãi với các khái niệm về nhận dạng đối tượng mà là một phần quan trọng của bất kỳ hệ thống đối tượng phân tán nào: làm thế nào để các phần khác nhau của hệ thống biết chúng đang nói về những đối tượng nào.

Tôi không quá quen thuộc với các chi tiết của bộ thu gom rác Java và tôi chắc chắn rằng các bộ thu gom rác Java và .NET có rất nhiều sự phức tạp trong chúng để đạt được hiệu suất tối đa với tác động tối thiểu trên ứng dụng.

Tuy nhiên, ý tưởng cơ bản cho thu gom rác thải là:

• Các VM dừng tất cả các chủ đề từ chạy quản lý mã
• Nó thực hiện một phân tích reachability từ tập các 'rễ' nổi tiếng: các biến tĩnh, địa phương biến trên tất cả các chủ đề. Đối với mỗi đối tượng, nó tìm thấy nó theo tất cả các tham chiếu trong đối tượng.
• Bất kỳ đối tượng nào không được xác định bởi phân tích khả năng hiển thị là rác.
• Đối tượng vẫn còn sống sau đó có thể được di chuyển xuống trong bộ nhớ để đóng gói chúng dày đặc. Điều này có nghĩa rằng bất kỳ tham chiếu đến các đối tượng này cũng phải được cập nhật với địa chỉ mới. Bằng cách kiểm soát khi nào việc thu thập rác có thể xảy ra, VM có thể đảm bảo rằng không có tham chiếu đối tượng 'trong không trung' (tức là được giữ trong máy đăng ký) có thể gây ra vấn đề.
• Khi quá trình hoàn tất, VM sẽ khởi động lại các luồng thực thi.

Khi tinh chỉnh quy trình này, VM có thể thực hiện bộ sưu tập rác sinh học, nơi các vùng riêng biệt được duy trì dựa trên 'tuổi' của một đối tượng. Các đối tượng bắt đầu trong heap 0 và nếu chúng tồn tại trong vài GC thì di chuyển đến heap 1 và cuối cùng là đống 2 (và vân vân. .NET hỗ trợ 3 thế hệ). Ưu điểm của điều này là GC có thể chạy bộ sưu tập heap 0 rất thường xuyên, và không phải lo lắng về việc thực hiện công việc để chứng minh các đối tượng sống lâu (đã kết thúc trong heap 2) vẫn còn sống (chúng gần như chắc chắn là) .

Có các cải tiến khác để hỗ trợ thu gom rác đồng thời và chi tiết xung quanh các chủ đề thực sự thực thi mã không được quản lý khi GC được lên lịch thêm độ phức tạp hơn cho khu vực này.

Answer 3

Từ khóa bạn đang theo dõi là "nén bộ thu gom rác". Các JVM được phép sử dụng một, có nghĩa là các đối tượng có thể được di chuyển. Tham khảo tài liệu hướng dẫn sử dụng JVM của bạn để tìm hiểu xem máy của bạn có hoạt động không, và xem liệu có bất kỳ tùy chọn dòng lệnh nào có ảnh hưởng đến nó hay không. Cách đơn giản nhất để giải thích sự nén chặt là giả định rằng bộ gom rác đóng băng tất cả các chủ đề, di chuyển đối tượng, tìm kiếm đống và ngăn xếp cho tất cả các tham chiếu đến đối tượng đó và cập nhật chúng với địa chỉ mới. Trên thực tế nó phức tạp hơn thế, vì lý do hiệu suất bạn không muốn thực hiện một quét toàn bộ với các chủ đề bị trì hoãn, do đó, một bộ gom rác gia tăng sẽ làm việc để chuẩn bị cho việc nén bất cứ khi nào có thể.

Nếu bạn quan tâm đến các tham chiếu gián tiếp, bạn có thể bắt đầu bằng cách nghiên cứu các tham chiếu yếu và mềm trong Java, cũng như các tham chiếu từ xa được sử dụng bởi các hệ thống RPC khác nhau.

Answer 4

có vẻ như bạn đang tìm kiếm bộ nhớ cache được phân phối, một thứ gì đó giống như bộ nhớ cache objece java hoặc đất nung (trước đây là tangersol).

Answer 5

Tôi rất tò mò muốn biết thêm về các yêu cầu của bạn. Như một câu trả lời khác cho thấy, Đất nung có thể là chính xác những gì bạn đang tìm kiếm.

Tuy nhiên, có một sự khác biệt tinh tế giữa những gì mà Terracotta cung cấp và những gì bạn đang yêu cầu, do đó, yêu cầu của tôi.

Sự khác biệt ở đây là Terracotta không cung cấp các tham chiếu "từ xa" tới các đối tượng - trên thực tế toàn bộ khái niệm "từ xa" của RMI, JMS, vv hoàn toàn vắng mặt khi sử dụng đất nung.

Thay vào đó, trong Terracotta, tất cả các đối tượng đều nằm trong vùng heap ảo lớn. Chủ đề, cho dù trên nút 1, hoặc nút 2, nút 3, nút 4, vv tất cả đều có quyền truy cập vào bất kỳ đối tượng nào trong vùng heap ảo.

Không có chương trình đặc biệt để tìm hiểu hoặc API đặc biệt, đối tượng trong vùng "ảo" có chính xác hành vi giống như đối tượng trong vùng cục bộ.

Tóm lại, những gì Terracotta cung cấp là một mô hình lập trình cho nhiều JVM hoạt động chính xác giống như mô hình lập trình cho một JVM đơn lẻ. Các luồng trong các nút riêng biệt chỉ hoạt động giống như các luồng trong một nút đơn lẻ - các đột biến đối tượng, đồng bộ, chờ, thông báo cho tất cả các hành xử giống hệt nhau trên các nút như trên các luồng - không có sự khác biệt.

Hơn nữa, không giống như bất kỳ giải pháp nào đến trước nó, tham chiếu đối tượng được duy trì trên các nút - nghĩa là bạn có thể sử dụng ==. Đó là tất cả một phần của việc duy trì Mô hình bộ nhớ Java trên cụm là yêu cầu cơ bản để tạo Java "thông thường" (ví dụ: POJOs, đồng bộ hóa, chờ/thông báo) (không có tác vụ nào hoạt động nếu bạn không/không thể bảo toàn) nhận diện đối tượng trên cụm).

Vì vậy, câu hỏi sẽ trở lại với bạn để tinh chỉnh thêm các yêu cầu của bạn - cho mục đích nào bạn cần "con trỏ" từ xa?

Answer 6

Nếu bạn sẵn sàng đi sâu xuống dưới, bạn có thể xem tài liệu kiến ​​trúc JBoss Cache và lấy một số mã nguồn làm tài liệu tham khảo.

Đây không phải chính xác những gì bạn mô tả, nhưng nó hoạt động rất giống nhau.

Đây là liên kết.

http://www.jboss.org/jbosscache/

Tôi hy vọng điều này sẽ hữu ích.