Green Tea GC เป็น default ใน Go 1.26 — ต้อง benchmark ใหม่ไหม
Go 1.26 เปิด Green Tea garbage collector เป็นค่าเริ่มต้นและเพิ่มโอกาสวาง backing store ของ slice บน stack ผลจริงขึ้นกับ allocation shape; ตัวเลขจาก release note แทน heap profile ของระบบเราไม่ได้
มีเหตุผลที่เรื่องนี้น่าตื่นเต้น และมีเหตุผลพอ ๆ กันที่ไม่ควรรีบทำตาม ผลจริงขึ้นกับ allocation shape; ตัวเลขจาก release note แทน heap profile ของระบบเราไม่ได้ ข้อมูลที่ทำให้เราต้องคิดเรื่องนี้ตอนนี้คือ Go 1.26 เปิด Green Tea garbage collector เป็นค่าเริ่มต้นและเพิ่มโอกาสวาง backing store ของ slice บน stack
## ด้านที่มักไม่ถูกพูดถึง
ในกรณีของ “Green Tea GC เป็น default ใน Go 1.26” ความเป็นไปได้กับความพร้อมใช้งานเป็นคนละเรื่องกัน ของใหม่อาจน่าสนใจและยังไม่เหมาะกับระบบของเราในวันนี้ได้พร้อมกัน
จุดชั่งใจของเรื่องนี้คือการได้ความสามารถใหม่โดยไม่สร้าง migration surface ใหญ่เกินประโยชน์ ถ้า เก็บ p95 latency, CPU และ heap ก่อนอัปเกรด แล้วรัน load เดิมหลังเปลี่ยน compiler ทำแยกเป็นขอบเขตเล็กไม่ได้ นั่นเป็นสัญญาณว่าควรออกแบบ boundary ก่อนอัปเกรด
ถอยกลับมาดูว่าข้อมูลเรื่อง Green Tea GC เป็น default ใน Go 1.26 มาจากไหน
รายละเอียดของ “Green Tea GC เป็น default ใน Go 1.26” ควรตรวจกลับไปที่ Go 1.26 release โดยตรง โดยเฉพาะถ้อยคำ สเปก และขอบเขตที่ประกาศไว้ ส่วนข้อจำกัดของระบบ งบ และความเสี่ยงที่รับได้ยังเป็นคำถามของคนใช้งาน
ผลของ “Green Tea GC เป็น default ใน Go 1.26” ไม่ได้หยุดที่ syntax หรือเลขเวอร์ชัน แต่วิ่งต่อไปถึง dependency, CI, observability และคนที่ต้องรับช่วงระบบในคืนที่มันมีปัญหา
## เริ่มตรงไหนดี
การทดลองรอบแรกทำเพียงอย่างเดียว: เก็บ p95 latency, CPU และ heap ก่อนอัปเกรด แล้วรัน load เดิมหลังเปลี่ยน compiler กำหนดเวลาเริ่ม–จบ เก็บสภาพเดิมไว้เทียบ และเขียนทางถอยก่อนลงมือ
หลักฐานสำหรับตัดสินใจเรื่อง Green Tea GC เป็น default ใน Go 1.26 ควรเป็น diff ที่รีวิวได้ test ที่จับ behavior เดิม และตัวเลขก่อน–หลังจาก workload เดียวกัน
## เก็บหรือถอย
หลังทดลอง Green Tea GC เป็น default ใน Go 1.26 เราควรตอบได้ว่าปัญหาเดิมดีขึ้นหรือไม่ ภาระใหม่คืออะไร และถ้าขยายผลแล้วใครจะดูแล ถ้ายังตอบไม่ได้ การหยุดไว้ก่อนก็เป็นผลลัพธ์ที่ดี