พื้นที่หน่วยความจำ Java และตัวรวบรวมขยะ

YoungGen/OldGen & PermGen คือสามพื้นที่ที่มี Java Heap อาศัยอยู่ JVM มีความรอบรู้เกี่ยวกับขอบเขตของแต่ละรายการ

1. ในขณะที่รวบรวมขยะ GC จะตัดสินใจว่าจะรันพื้นที่ใดก่อน จากนั้นจึงระบุรากของ GC ของแต่ละวัตถุในพื้นที่นั้น ไม่ว่าวัตถุจะอายุน้อยหรือเก่าก็ตามจะถูกระบุโดย Space ที่วัตถุนั้นอยู่ในฮีป GC รักษาสถานะของออบเจ็กต์แต่ละรายการเช่นเดียวกับจำนวนรอบ GC ที่แต่ละออบเจ็กต์รอดชีวิตมาได้ ซึ่งทำให้ GC สามารถประมาณได้ว่าเวลาเหมาะสมที่จะย้ายออบเจ็กต์จากรุ่นเล็กไปรุ่นเก่าหรือไม่

2. กราฟวัตถุจะตัดสินว่าวัตถุ Gen รุ่นเยาว์ถูกอ้างอิงโดยการอ้างอิงรุ่นเก่าหรือไม่

3. หากวัตถุถูกบีบอัด ข้อมูลอ้างอิงก็จะได้รับการอัปเดตด้วย สิ่งนี้จะเกิดขึ้นเช่นกันเมื่อวัตถุย้ายจาก Young > Old Gen

คำตอบขึ้นอยู่กับอัลกอริธึม GC ดังนั้นคุณจะพบคำตอบที่หลากหลาย

GC รู้ได้อย่างไรว่าวัตถุไหนอายุน้อย และวัตถุไหนเก่า? จะรู้ได้อย่างไรว่าวัตถุพื้นที่หน่วยความจำใดอยู่ใน?

ที่อยู่หน่วยความจำของวัตถุจะตอบว่าเนื่องจากแต่ละภูมิภาคมีแนวโน้มที่จะได้รับการแก้ไขในตำแหน่ง การปรับขนาดสามารถทำได้ แต่จะเกิดขึ้นเฉพาะเมื่อ JVM หยุดเธรดงานทั้งหมดชั่วคราวเท่านั้น โปรดจำไว้ว่าตัวรวบรวม G1 ไม่มีรุ่น ดังนั้นคำตอบจึงแตกต่างกันไปตามอัลกอริทึมที่ใช้

gc รู้ได้อย่างไรว่าวัตถุในรุ่นใหม่ไม่ได้อ้างอิงโดยวัตถุในรุ่นเก่าหรือโดยการอ้างอิงแบบคงที่จากพื้นที่วิธีการ

อัลกอริธึม GC บางตัวจะทำการสแกนออบเจ็กต์ทั้งหมดในฮีปโดยสมบูรณ์ คนอื่นๆ อาศัยการสังเกตว่าจำนวนผู้อ้างอิงตั้งแต่รุ่นเก๋าไปจนถึงรุ่นเยาว์นั้นค่อนข้างต่ำ ดังนั้น JVM จึงติดตามพวกเขาและใช้เป็นรากฐานในการทำเครื่องหมาย กลไกนี้มักจะเป็นระบบบัตรคะแนน และเป็นเหตุผลว่าทำไมอัลกอริธึม GC บางตัวที่มีพื้นที่บรรพบุรุษขนาดใหญ่มากอาจทำให้ GC ของพื้นที่อายุน้อยช้าลง เพราะทุกบัตรคะแนนของทุกวัตถุจะต้องได้รับการตรวจสอบเพื่อดูว่าจะสามารถชี้กลับไปยังคนรุ่นใหม่ได้หรือไม่

สิ่งสุดท้ายคือหลังจากทำเครื่องหมายและกวาดบางครั้งการบดอัดก็เสร็จสิ้น gc รู้ได้อย่างไรว่าการอ้างอิงถึงวัตถุที่ถูกย้ายใดที่ต้องได้รับการอัปเดต

ขอย้ำอีกครั้งว่าคำตอบจะแตกต่างกันไปเนื่องจาก JVM ได้รับอนุญาตให้เปลี่ยนแปลงรายละเอียดเหล่านี้ อัลกอริธึมบางตัวใช้การอ้อมสองครั้งเพื่อให้พอยน์เตอร์ค้นหาและอัปเดตได้ง่ายมาก ที่เกี่ยวข้องกับการจัดเก็บดัชนีขนาดใหญ่สำหรับทุกวัตถุ อย่างไรก็ตาม สิ่งนี้แสดงให้เห็นว่าทำให้โค้ดผู้ใช้ช้าลงเมื่อ GC ไม่ทำงาน เนื่องจากโค้ดที่รันอยู่จะต้องค้นหาว่าวัตถุนั้นอยู่ที่ไหนจริง ๆ ดังนั้นใช่แล้ว อัลกอริธึม GC บางตัวติดตามการอ้างอิง

Azul ใช้กลไกที่ชาญฉลาดมากซึ่งทำให้เพจของหน่วยความจำใช้งานไม่ได้และจัดเก็บแผนที่การเปลี่ยนเส้นทางที่เข้าถึงได้ในโค้ดตัวจัดการกับดัก ดังนั้นจึงจำเป็นต้องจัดเก็บที่อยู่ของวัตถุที่ถูกย้ายเท่านั้น ในขณะที่อัลกอริธึม GC อื่นๆ ติดตามข้อมูลขณะสแกนออบเจ็กต์ที่มีชีวิต ท้ายที่สุดแล้ว เราไม่ต้องการข้อมูลของผู้ตาย

1. ทุกครั้งที่ GC ตรวจสอบว่าสามารถรวบรวมวัตถุได้หรือไม่ มันจะเพิ่มตัวนับในวัตถุ ซึ่งจะบอกว่า GC เยี่ยมชมวัตถุนั้นกี่ครั้ง นั่นเป็นวิธีที่ง่ายที่สุดในการบอกได้ว่าเมื่อใดที่จำเป็นต้องย้ายวัตถุจากรุ่นเยาว์ไปสู่รุ่นที่ดำรงตำแหน่ง แต่สำหรับการรู้ว่าวัตถุนั้นอยู่ในพื้นที่ใด ก็สามารถใช้ที่อยู่ของวัตถุนั้นมาคำนวณได้ (เช่น JVM จะบอกว่าที่อยู่หน่วยความจำระหว่าง 0-100 คือคนรุ่นใหม่ 101+ คือรุ่นที่ดำรงตำแหน่ง)
2. แม้ในระหว่างการรวบรวมเล็กน้อย กราฟวัตถุทั้งหมดจะถูกสำรวจเพื่อตรวจสอบการอ้างอิง อย่างน้อยในทางทฤษฎีนั่นคือสิ่งที่เกิดขึ้น จะมีการเพิ่มประสิทธิภาพในทางปฏิบัติ แต่แนวคิดทั่วไปก็คือสิ่งนี้
3. เนื่องจากขั้นตอนแรกคือการสร้างกราฟของข้อมูลอ้างอิง ข้อมูลดังกล่าวจึงยังคงอยู่ในขั้นตอนการบดอัด แต่ใช่แล้ว การอัดฮีปขนาดกิกะไบต์ใช้เวลานาน