ReservedCodeCacheSize và InitialCodeCacheSize là gì?

86

Ai đó có thể vui lòng giải thích tùy chọn JVM là gì ReservedCodeCacheSizevà InitialCodeCacheSizelà gì không? Cụ thể là khi nào / tại sao tôi muốn thay đổi nó? Làm thế nào để tôi quyết định kích thước phù hợp là gì?

Đây là những gì tài liệu nói:

-XX: ReservedCodeCacheSize = 32m Kích thước bộ đệm mã dự trữ (tính bằng byte) - kích thước bộ đệm mã tối đa. [Solaris 64-bit, amd64 và -server x86: 2048m; trong 1.5.0_06 trở về trước, Solaris 64-bit và và64: 1024m.]

java  jvm  jvm-hotspot 
— Raghu
nguồn
2
OP của bài viết này đã viết:> -XX: ReservedCodeCacheSize = 32m Kích thước bộ đệm mã dự trữ (tính bằng byte) - kích thước bộ đệm mã tối đa. [Solaris 64-bit, amd64 và -server x86: 48m; trong 1.5.0_06 trở về trước, Solaris 64-bit và và64: 1024m.] Tôi chỉ muốn sửa lại rằng giới hạn trên được đề cập ở 48m phải là lỗi đánh máy. Nó là 2048m.
— Lasse Aagren

Câu trả lời:

73

ReservedCodeCacheSize(và InitialCodeCacheSize) là một tùy chọn cho trình biên dịch (chỉ trong thời gian) của Java Hotspot VM. Về cơ bản, nó đặt kích thước tối đa cho bộ đệm mã của trình biên dịch.

Bộ nhớ đệm có thể đầy, dẫn đến các cảnh báo như sau:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

Nó tồi tệ hơn nhiều khi theo sau Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

Khi nào đặt tùy chọn này?

  1. khi gặp lỗi trình biên dịch Hotspot
  2. để giảm bộ nhớ cần thiết của JVM (và do đó có nguy cơ gây ra lỗi trình biên dịch JIT)

Thông thường bạn sẽ không thay đổi giá trị này. Tôi nghĩ rằng các giá trị mặc định được cân bằng khá tốt vì vấn đề này chỉ xảy ra trong những trường hợp rất hiếm hoi (theo kinh nghiệm của tôi).

— jeha
nguồn
1
Đẹp. Các giá trị mặc định là gì và chúng nên được tăng lên đến mức nào nếu chúng ta thấy thông báo "CodeCache đã đầy". cảnh báo?
— axel22
3
@ axel22: Các giá trị thực sự phụ thuộc vào nền tảng và phiên bản JVM; giá trị từ tài liệu cho Sun JVM: Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and amd64: 1024m.]Không biết giá trị OpenJDK. Mức tăng vừa phải là đủ (thiết lập trước đó là 1024m không phải là thiện cũng là ác).
— jeha
12

@jeha trả lời mọi thứ tôi muốn biết từ câu hỏi này, ngoài giá trị cần đặt các tham số. Vì tôi không viết mã mà tôi đang triển khai, tôi không có nhiều khả năng hiển thị vào vùng bộ nhớ mà nó có.

Tuy nhiên, bạn có thể sử dụng jconsole để đính kèm vào quy trình java đang chạy của mình, sau đó sử dụng tab 'Bộ nhớ' để tìm ra kích thước Bộ đệm mã. Để hoàn thiện, các bước là (môi trường Linux VM, mặc dù tôi chắc chắn rằng các môi trường khác cũng tương tự):

  1. Khởi động jconsole trên máy của bạn
  2. Tìm ID quy trình phù hợp và đính kèm jconsole vào nó (quá trình này sẽ mất vài phút)
  3. Điều hướng đến tab 'Bộ nhớ'
  4. Từ danh sách thả xuống 'Biểu đồ:', hãy chọn 'Nhóm bộ nhớ "Bộ đệm mã" "

  5. Một lần nữa, điều này có thể mất một vài phút để màn hình làm mới và sau đó bạn sẽ thấy một cái gì đó như: hình ảnh bộ nhớ cache mã jconsole

    Như bạn có thể thấy, bộ nhớ cache mã của tôi đang sử dụng khoảng 49 MB. Tại thời điểm này, tôi vẫn có mặc định mà tài liệu (và @jeha) nói là 48 MB. Chắc chắn là động lực lớn để tôi tăng thiết lập!

    Ben.

    1024 MB theo mặc định có thể đã làm quá mức, nhưng 48 MB theo mặc định dường như đang làm quá mức ...

— Động vật451
nguồn
Đề xuất tốt .... Tôi đang thử với -J-XX: ReservedCodeCacheSize = 512m
— MarcoZen
Netbeans sẽ không bắt đầu với 512m, đã làm với 256m
— MarcoZen
Và sau khi thử nghiệm trong khoảng 2 ngày, tôi có thể nói rằng cài đặt không cho thấy bất kỳ / cải tiến đáng chú ý nào và thay vào đó khiến netbeans trở nên mệt mỏi. Tôi đã kết thúc việc loại bỏ nó.
— MarcoZen
3

Một kinh nghiệm học hỏi tốt từ nhóm kỹ sư Indeed và những thách thức họ phải đối mặt khi chuyển sang jdk 8.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

Kết luận: Jdk 8 cần thêm bộ đệm mã han JDK 7

Kích thước bộ nhớ đệm mặc định cho JRE 8 là khoảng 250MB, lớn hơn khoảng năm lần so với 48MB mặc định cho JRE 7. Kinh nghiệm của chúng tôi là JRE 8 cần bộ đệm bổ sung đó. Cho đến nay, chúng tôi đã chuyển khoảng mười dịch vụ sang JRE 8 và tất cả chúng đều sử dụng bộ nhớ mã nhiều hơn khoảng bốn lần so với trước đây.

— vsingh
nguồn
0

từ https://blogs.oracle.com/poonam/entry/why_do_i_get_message :

Sau đây là hai sự cố đã biết trong jdk7u4 + liên quan đến việc xả bộ nhớ đệm CodeCache:

  1. Trình biên dịch có thể không được khởi động lại ngay cả sau khi tỷ lệ sử dụng CodeCache giảm xuống gần một nửa sau khi xả khẩn cấp.
  2. Việc xả khẩn cấp có thể gây ra việc sử dụng CPU cao bởi các luồng trình biên dịch dẫn đến việc giảm hiệu suất tổng thể.

Sự cố hiệu suất này và sự cố trình biên dịch không được kích hoạt lại lần nữa đã được giải quyết trong JDK8. Để giải quyết những vấn đề này trong JDK7u4 +, chúng ta có thể tăng kích thước bộ đệm mã bằng cách sử dụng tùy chọn ReservedCodeCacheSize bằng cách đặt nó thành một giá trị lớn hơn dấu chân mã đã biên dịch để CodeCache không bao giờ bị đầy. Một giải pháp khác cho điều này là vô hiệu hóa CodeCache Flushing bằng tùy chọn -XX: -UseCodeCacheFlushing JVM.

Các vấn đề được đề cập ở trên đã được khắc phục trong JDK8 và các bản cập nhật của nó.

Vì vậy, thông tin đó có thể đáng được nhắc đến đối với các hệ thống chạy trên JDK 6 (đã tắt tính năng xả mã) và 7.

— Andre Steingress
nguồn
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 cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.