Cờ UseCompressedOops JVM làm gì và khi nào tôi nên sử dụng nó?

Cờ HotSpot JVM -XX:+UseCompressedOopslàm gì và tôi nên sử dụng nó khi nào? Tôi sẽ thấy sự khác biệt về hiệu suất và mức sử dụng bộ nhớ nào khi sử dụng nó trên phiên bản Java 64-bit (so với không sử dụng nó)?

— noahlz
nguồn

Nó nén các con trỏ 64-bit. Bạn sẽ thấy bộ nhớ phình ra giảm do kích thước con trỏ tăng lên, thời gian dành cho GC ít hơn, hiệu suất có thể giảm một chút. jdk1.6.0_22 là CN JVM cuối cùng tắt cờ này theo mặc định.

— sjr

Xem blog.juma.me.uk/2008/10/14/…

— Vadzim

Hầu hết các HotSpot JVM trong năm ngoái đều đã bật tính năng này theo mặc định. Tùy chọn này cho phép các tham chiếu là 32 bit trong JVM 64 bit và truy cập gần 32 GB của heap. (hơn 32-bit con trỏ có thể) (Bạn cũng có thể có gần như không giới hạn bộ nhớ heap). Điều này có thể tiết kiệm một lượng bộ nhớ đáng kể và có khả năng cải thiện hiệu suất.

Nếu bạn muốn sử dụng tùy chọn này, tôi khuyên bạn nên cập nhật lên phiên bản có tính năng này theo mặc định vì có thể có lý do chính đáng, chẳng hạn như lỗi, tại sao nó không được bật trước đây. Hãy thử Java 6 cập nhật 23 hoặc Java 7 cập nhật 5.

Nói tóm lại, đừng bật nó lên, hãy sử dụng một phiên bản được bật theo mặc định.

Cập nhật:

Trong Java 8, bạn có tùy chọn để đặt -XX:ObjectAlignmentInBytes=và trên thực tế, nếu kích thước heap của bạn thành 64 GB, nó sẽ sử dụng -XX:ObjectAlignmentInBytes=16và vẫn sử dụng tham chiếu 32 bit.

— Peter Lawrey
nguồn

Tôi đã đọc bài viết này: community.oracle.com/message/10019916 nói rằng chúng ta nên luôn sử dụng cờ này theo cách thủ công ngay cả khi nó được bật theo mặc định. Có suy nghĩ gì không?

— vanval

@vanval Điều đó được khuyến nghị nếu bạn đang sử dụng JE cache Điều này là do nó không thể giải quyết được liệu bạn có đang sử dụng nén hay không vì một số lý do. Tôi có thể nghĩ ra một vài phương pháp có thể cho bạn biết điều này btw. Bạn không cần chỉ định nó trên dòng lệnh IMHO trừ khi bạn muốn JVM không thành công nếu nó không được kích hoạt. ví dụ như bạn có một đống GB 64 trên Java 8.

— Peter Lawrey

Tôi vừa chạy một số thử nghiệm trên Win8 x64 i7-4702MQ JDK 8 u40 với 7 GB xms và xmx, Trong số 7 GB, 5,4 GB được sử dụng bởi một cây lớn được tải từ db Access. Quan điểm của tôi là: chỉ định thủ công cờ -XX: + UseCompressedOops dẫn đến hiệu suất giảm 20% (khi tạo cây lớn) và thêm 1 lần nữa (từ 3 đến 4) tạm dừng GC dài (với GC mặc định). Bạn có thể coi đó là sự giảm sút hiệu suất hoặc là sự gia tăng trong thời gian tạm dừng GC. Dù bằng cách nào, nó cũng chậm hơn 20%.

— zmirc

Mỗi ứng dụng có bộ nhớ và cấu hình sử dụng riêng. Trong trường hợp của chúng tôi, một ứng dụng dành cho máy tính để bàn đến từ 32bits jvm, cờ + UseCompressedOops tiết kiệm thời gian, vì nó giữ mức sử dụng bộ nhớ đủ thấp để phù hợp với máy 4gb cũ của khách hàng và tăng hiệu suất lên 30% khi so với 32bits jvm.

— Alex Byrth,