JDK 16: Điều gì sẽ xảy ra trong Java 16 từ InfoWorld Java
JDK 16: Điều gì sẽ xảy ra trong Java 16 từ InfoWorld Java

Mặc dù chưa đến tháng 3 năm 2021, Bộ công cụ phát triển Java (JDK) 16 đã bắt đầu hình thành, với các tính năng được đề xuất bao gồm xử lý ngăn xếp luồng đồng thời để thu gom rác, hỗ trợ các tính năng ngôn ngữ C ++ 14 và khả năng “siêu không gian đàn hồi” để nhanh chóng trả lại bộ nhớ siêu dữ liệu lớp không sử dụng cho HĐH.



JDK 16 sẽ là bản triển khai tham chiếu của phiên bản Java tiêu chuẩn được đặt theo JDK 15 , có mặt vào ngày 15 tháng 9. Nhịp phát hành sáu tháng cho Java tiêu chuẩn sẽ có JDK 16 đến vào tháng Ba tới.

JDK 16: Điều gì sẽ xảy ra trong Java 16 từ InfoWorld Java
JDK 16: Điều gì sẽ xảy ra trong Java 16 từ InfoWorld Java


  • Di chuyển xử lý ngăn xếp luồng ZGC (Z Garbage Collector)từ các điểm an toàn đến một pha đồng thời. Các mục tiêu của kế hoạch này bao gồm loại bỏ quá trình xử lý ngăn xếp luồng khỏi các điểm an toàn ZGC; làm cho việc xử lý ngăn xếp trở nên lười biếng, hợp tác, đồng thời và gia tăng; loại bỏ tất cả các xử lý gốc cho mỗi luồng khác khỏi các điểm an toàn của ZGC; và cung cấp cơ chế để các hệ thống con HotSpot VM khác xử lý ngăn xếp một cách lười biếng. ZGC nhằm biến việc tạm dừng GC và các vấn đề về khả năng mở rộng trong HotSpot trở thành dĩ vãng. Cho đến nay, các hoạt động GC có quy mô với kích thước của heap và kích thước của metaspace đã được chuyển ra khỏi các hoạt động điểm an toàn và chuyển sang các giai đoạn đồng thời. Chúng bao gồm đánh dấu, di dời, xử lý tham chiếu, dỡ lớp và hầu hết xử lý gốc. Các hoạt động duy nhất vẫn được thực hiện trong các điểm an toàn GC là một tập hợp con của xử lý gốc và hoạt động chấm dứt đánh dấu có giới hạn thời gian. Các gốc này đã bao gồm các ngăn xếp luồng Java và các gốc luồng khác, với các gốc này có vấn đề vì chúng chia tỷ lệ với số lượng luồng. Để vượt ra ngoài tình huống hiện tại, xử lý theo từng luồng, bao gồm cả quét ngăn xếp, phải được chuyển sang một giai đoạn đồng thời. Với kế hoạch này, chi phí thông lượng của độ trễ được cải thiện sẽ không đáng kể và thời gian dành cho các điểm an toàn ZGC trên các máy thông thường sẽ ít hơn một phần nghìn giây.


  • Khả năng siêu không gian đàn hồi, trả về bộ nhớ siêu dữ liệu lớp HotSpot VM (siêu dữ liệu) không được sử dụng kịp thời hơn cho hệ điều hành, giảm dấu chân không gian siêu và đơn giản hóa mã không gian siêu dữ liệu để giảm chi phí bảo trì. Metaspace đã gặp vấn đề với việc sử dụng bộ nhớ off-heap cao. Kế hoạch này kêu gọi thay thế trình cấp phát bộ nhớ hiện có bằng một lược đồ cấp phát dựa trên bạn thân, cung cấp một thuật toán để chia bộ nhớ thành các phân vùng để đáp ứng các yêu cầu bộ nhớ. Cách tiếp cận này đã được sử dụng ở những nơi chẳng hạn như hạt nhân Linux và sẽ làm cho việc phân bổ bộ nhớ theo các phần nhỏ hơn trở nên thực tế hơn để giảm chi phí của trình tải lớp. Sự phân mảnh cũng sẽ được giảm bớt. Ngoài ra, cam kết của bộ nhớ từ hệ điều hành với các đấu trường quản lý bộ nhớ sẽ được thực hiện một cách lười biếng, theo yêu cầu, để giảm diện tích cho các bộ tải bắt đầu với đấu trường lớn nhưng không sử dụng chúng ngay lập tức hoặc có thể không sử dụng hết mức. Để khai thác triệt để tính đàn hồi được cung cấp bởi phân bổ bạn thân, bộ nhớ metaspace sẽ được sắp xếp thành các hạt có kích thước đồng nhất có thể được cam kết và không cam kết độc lập với nhau.


  • Kích hoạt các tính năng của ngôn ngữ C ++ 14 , để cho phép sử dụng các tính năng của C ++ 14 trong mã nguồn JDK C ++ và đưa ra hướng dẫn cụ thể về những tính năng nào trong số này có thể được sử dụng trong mã HotSpot VM. Thông qua JDK 15, các tính năng ngôn ngữ được sử dụng bởi mã C ++ trong JDK đã được giới hạn trong các tiêu chuẩn ngôn ngữ C ++ 98/3. Với JDK 11, mã nguồn đã được cập nhật để hỗ trợ xây dựng với các phiên bản mới hơn của tiêu chuẩn C ++. Điều này bao gồm việc có thể xây dựng với các phiên bản trình biên dịch gần đây hỗ trợ các tính năng ngôn ngữ C ++ 11/14. Đề xuất này không đề xuất bất kỳ thay đổi nào về kiểu hoặc cách sử dụng đối với mã C ++ được sử dụng bên ngoài HotSpot. Nhưng để tận dụng các tính năng của ngôn ngữ C ++, cần có một số thay đổi về thời gian xây dựng, tùy thuộc vào trình biên dịch nền tảng.


  • Một API vectơ trong giai đoạn lò ấp , trong đó JDK sẽ được lắp với một mô-đun máy ấp,jdk.incubator.vector, để thể hiện các phép tính vectơ biên dịch theo hướng dẫn phần cứng vectơ tối ưu trên các kiến ​​trúc CPU được hỗ trợ, nhằm đạt được hiệu suất vượt trội so với các phép tính vô hướng tương đương. API vectơ cung cấp một cơ chế để viết các thuật toán vectơ phức tạp trong Java, sử dụng hỗ trợ có sẵn trong HotSpot VM để vectơ hóa nhưng với mô hình người dùng giúp vectơ hóa dễ dự đoán và mạnh mẽ hơn. Các mục tiêu của đề xuất bao gồm cung cấp một API rõ ràng và ngắn gọn để thể hiện một loạt các phép tính vectơ, mang tính bất khả tri nền tảng bằng cách hỗ trợ nhiều kiến ​​trúc CPU và cung cấp hiệu suất và biên dịch thời gian chạy đáng tin cậy trên các kiến ​​trúc x64 và AArch64. Sự xuống cấp duyên dáng cũng là một mục tiêu
  • Chuyển JDK sang nền tảng Windows / AArch64 . Với việc phát hành phần cứng AArch64 (ARM64) cấp máy chủ và tiêu dùng mới, Windows / AArch64 đã trở thành một nền tảng quan trọng do nhu cầu. Mặc dù bản thân quá trình chuyển gần như đã hoàn thành, trọng tâm của đề xuất này liên quan đến việc tích hợp cổng vào kho lưu trữ JDK dòng chính.
  • Chuyển JDK sang Alpine Linux và các bản phân phối Linux khác sử dụng musl làm thư viện C chính của chúng, trên kiến ​​trúc x64 và AArch64. Musl là một triển khai Linux của chức năng thư viện tiêu chuẩn được mô tả trong tiêu chuẩn ISO C và Posix. Alpine Linux được áp dụng rộng rãi trong triển khai đám mây, dịch vụ vi mô và môi trường vùng chứa do kích thước hình ảnh nhỏ của nó. Hình ảnh Docker cho Linux nhỏ hơn 6MB. Để Java chạy ra khỏi hộp trong các cài đặt như vậy sẽ cho phép Tomcat, Jetty, Spring và các khuôn khổ phổ biến khác hoạt động trong các môi trường này. Bằng cách sử dụng jlink để giảm kích thước của thời gian chạy Java, người dùng có thể tạo một hình ảnh thậm chí còn nhỏ hơn được điều chỉnh để chạy một ứng dụng cụ thể.


  • Di chuyển kho mã nguồn OpenJDK từ Mercurial sang Git . Thúc đẩy nỗ lực này là lợi thế về kích thước siêu dữ liệu của hệ thống kiểm soát phiên bản cũng như các công cụ và dịch vụ lưu trữ có sẵn.
  • Di chuyển sang GitHub , liên quan đến quá trình di chuyển Mercurial-sang-Git, với kho mã nguồn JDK 16 nằm trên trang web chia sẻ mã phổ biến . Quá trình chuyển đổi sang Git, GitHub và Skara cho Mercurial JDK và JDK-sandbox đã được thực hiện vào ngày 5 tháng 9 và sẵn sàng đóng góp.  

Bạn có thể tìm thấy các bản dựng quyền truy cập sớm của JDK 16 cho Linux, Windows và MacOS tại jdk.java.net . Giống như JDK 15, JDK 16 sẽ là bản phát hành ngắn hạn, được hỗ trợ trong sáu tháng. JDK 17, sẽ ra mắt vào tháng 9 năm 2021, sẽ là bản phát hành hỗ trợ dài hạn (LTS) sẽ nhận được hỗ trợ trong vài năm. Bản phát hành LTS hiện tại, JDK 11 , được phát hành vào tháng 9 năm 2018.


LEAVE A REPLY

Please enter your comment!
Please enter your name here