โพสต์มอร์เท็มของ jemalloc

 (jasone.github.io)
9 คะแนน โดย GN⁺ 2025-06-14 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • บันทึกย้อนความที่เขียนโดย Jason Evans ผู้ขับเคลื่อนการพัฒนา jemalloc ด้วยตนเอง โดยย้อนดูเส้นทางการพัฒนา jemalloc ตลอดราว 20 ปี แบ่งเป็น 5 ช่วง พร้อมบันทึกทั้งความสำเร็จ ความล้มเหลว ข้อจำกัดของโครงการโอเพนซอร์ส และกระบวนการถดถอยจากการเปลี่ยนแปลงภายในองค์กรอย่างตรงไปตรงมา
  • ตัวจัดสรรหน่วยความจำ jemalloc เริ่มต้นตั้งแต่ปี 2004 และถูกใช้งานอย่างแพร่หลายราว 20 ปี แต่ล่าสุดการพัฒนาอย่างเป็นทางการได้ยุติลงจากการเปลี่ยนแปลงภายในของ Meta
  • มีการสั่งสม ประสบการณ์ด้านการปรับแต่งประสิทธิภาพและการพอร์ตระบบ ผ่านหลายช่วงสำคัญ เช่น การรวมเข้ากับ FreeBSD การแก้ปัญหาประสิทธิภาพของ Firefox และการนำไปใช้อย่างกว้างขวางใน Facebook
  • ระหว่างทางต้องเผชิญความท้าทายหลากหลาย เช่น ปัญหาการแตกกระจายของพื้นที่จัดเก็บ และปัญหาด้านการขยายตัว ส่งผลให้มีการเพิ่มฟีเจอร์ต่าง ๆ เช่น การปรับปรุงประสิทธิภาพ การเก็บ สถิติ และ โครงสร้างพื้นฐานสำหรับการทดสอบ
  • พร้อมกับการเปลี่ยนแปลงวัฒนธรรมองค์กรภายใน Meta ก็เกิด การลดการลงทุนด้านเทคนิคและการขาดผู้ดูแลหลัก จนทำให้การพัฒนาระยะยาวต้องหยุดลง
  • ปัจจัยเชิงโครงสร้างในระบบนิเวศโอเพนซอร์ส เช่น การถอด Valgrind ออกและการขาดฟีดแบ็กจากผู้ใช้ภายนอก ก็มีส่วนทำให้โครงการขาดความเชื่อมต่อ
  • ในอนาคตยังเปิดโอกาสให้เกิดการพัฒนารูปแบบใหม่ผ่าน fork ได้ แต่คาดว่าการพัฒนาหลักอย่างเป็นทางการจะไม่เดินหน้าต่อไปแล้ว

ภาพรวมของ jemalloc

  • jemalloc เป็น ตัวจัดสรรหน่วยความจำโอเพนซอร์ส ที่ถูกออกแบบขึ้นครั้งแรกในปี 2004 โดยมีเป้าหมายเพื่อปรับปรุงประสิทธิภาพและความสามารถในการขยายตัว และตลอด 20 ปีที่ผ่านมาได้ถูกใช้อย่างกว้างขวางในโครงการโอเพนซอร์สสำคัญและโครงสร้างพื้นฐานของบริษัทยักษ์ใหญ่ด้านเทคโนโลยี
  • ปัจจุบันการพัฒนาหลักได้หยุดลงแล้ว และต่อจากนี้คาดว่าจะเป็นการดูแลรักษาผ่าน fork หรือโดยแต่ละองค์กรเอง

Phase 0: Lyken

  • ในปี 2004 ระหว่างการพัฒนาภาษาโปรแกรมสำหรับงานคำนวณเชิงวิทยาศาสตร์ชื่อ Lyken ได้เริ่มต้นจากตัวจัดสรรหน่วยความจำแบบแมนนวล
  • ตัวจัดสรรภายในของ Lyken พัฒนาเสร็จสมบูรณ์ในเชิงฟังก์ชันเมื่อเดือนพฤษภาคม 2005
  • ต่อมาหลังจากตัวจัดสรรนี้ถูกรวมเข้า FreeBSD ก็ถูกถอดออกจาก Lyken โดยเหลือเพียงแรปเปอร์บาง ๆ ของตัวจัดสรรในระบบไว้เท่านั้น
  • เหตุผลที่ถอดออกคือ หลังจากรวมเข้ากับ FreeBSD แล้ว จึงเห็นได้ชัดว่าจุดอ่อนของตัวจัดสรรระบบมีเพียงบางส่วน เช่น การติดตามโควต้าการจัดสรรแยกตามเธรด
  • ที่น่าสนใจก็คือ ภายหลัง jemalloc ก็ได้เพิ่ม ฟีเจอร์เก็บสถิติ ที่เคยจำเป็นต่อ Lyken ในช่วงแรกเข้ามา

Phase 1: FreeBSD

  • ในปี 2005 ซึ่งเป็นช่วงที่ คอมพิวเตอร์แบบมัลติโปรเซสเซอร์ เริ่มแพร่หลาย FreeBSD ยังใช้ phkmalloc อยู่ แต่ไม่เหมาะกับสภาพแวดล้อมที่มีเธรดทำงานขนานกัน
  • เนื่องจากตัวจัดสรรของ Lyken มีข้อได้เปรียบชัดเจนด้านการขยายตัว จึงถูกนำมารวมเข้ากับ FreeBSD และในไม่นานก็ได้ชื่อว่า jemalloc
  • อย่างไรก็ตาม ได้เกิด ปัญหาการแตกกระจายอย่างรุนแรง ในแอปพลิเคชันอย่าง KDE จนมีคำถามว่าโครงการจะไปรอดหรือไม่
  • สาเหตุของการแตกกระจายมาจาก วิธีจัดสรรพื้นที่รวมโดยไม่แยกตามขนาด และหลังการวิจัยจึงมีการปรับโครงสร้างครั้งใหญ่ไปสู่ อัลกอริทึมแยกโซนตามขนาด
  • รายละเอียดของกระบวนการนี้ถูกบันทึกไว้ในบทความ BSDCan ปี 2006

Phase 1.5: Firefox

  • ในปี 2007 ก่อนการออก Mozilla Firefox 3 ปัญหาการแตกกระจายของหน่วยความจำบน Windows เป็นประเด็นใหญ่
  • การพอร์ต jemalloc ไปยัง Linux ทำได้ง่าย แต่บน Windows นั้นยุ่งยากกว่า
  • Mozilla ได้ fork jemalloc ที่อยู่ใน FreeBSD libc เพื่อนำมาปรับปรุงด้านการพกพาและความเข้ากันได้
  • เมื่อเวลาผ่านไป Mozilla ได้ส่งคืนการปรับปรุงจำนวนมากกลับสู่ upstream ของ jemalloc แต่ก็ยังเป็น เวอร์ชัน fork ที่ให้ประสิทธิภาพสูงกว่า อยู่เสมอ
  • ยังไม่ชัดเจนว่าสาเหตุมาจากปัญหา performance regression หรือเป็นผลจากการปรับแต่งเฉพาะสำหรับบางสภาพแวดล้อม

Phase 2: Facebook

  • เมื่อเข้าทำงานที่ Facebook ในปี 2009 อุปสรรคใหญ่ที่สุด ของ jemalloc คือการขาดเครื่องมือ เช่น การทำ profiling และการตรวจจับ memory leak
  • เพื่อแก้ปัญหานี้ จึงมีการเพิ่มฟีเจอร์ heap profiling ที่เข้ากันได้กับ pprof ใน jemalloc 1.0.0
  • หลังย้ายการพัฒนาไปยัง GitHub ก็มีการปรับปรุงจำนวนมากร่วมกับผู้ใช้และผู้มีส่วนร่วมจากภายนอก เช่น โครงสร้างพื้นฐานการทดสอบ การรองรับ Valgrind สถิติแบบ JSON และการจัดการเพจรูปแบบใหม่
  • ภายในองค์กร ระบบ telemetry ขนาดมหาศาล ของ Facebook ช่วยอย่างมากทั้งในการปรับแต่งประสิทธิภาพและป้องกัน regression
  • 3.x: เพิ่มโครงสร้างพื้นฐานการทดสอบและการรองรับ Valgrind
  • 4.x: เพิ่ม decay-based purging และสถิติแบบ JSON
  • 5.x: เปลี่ยนจากการออกแบบแบบ chunk ไปสู่แบบ extent และวางพื้นฐานสำหรับการใช้ 2MiB huge page
  • การวิเคราะห์ประสิทธิภาพโดยอาศัย telemetry ภายใน Facebook มีบทบาทชี้ขาดต่อการเพิ่มประสิทธิภาพ
  • การถอดการรองรับ Valgrind ออกในเวอร์ชัน 5.0.0 เป็นการตัดสินใจจากการที่ภายในองค์กรไม่ได้ใช้งาน แต่ก็เจอกระแสคัดค้านจากภายนอกอย่างหนัก โดยเฉพาะจาก นักพัฒนา Rust
  • ต่อมาเมื่อ Facebook/Meta ปรับโครงสร้างองค์กร ทีม jemalloc ก็ถูกลดขนาดลง และยุทธศาสตร์ธุรกิจก็เปลี่ยนไปสู่การเน้นประสิทธิภาพเชิงองค์กรแทนการลงทุนในเทคโนโลยีหลัก
  • ด้วยเหตุนี้ การพัฒนาฟีเจอร์ขนาดใหญ่อย่าง Huge Page Allocation จึงชะงักงัน และบางงานก็ไม่เสร็จสมบูรณ์
  • หลัง Evans ลาออกในปี 2017 การพัฒนายังคงดำเนินต่อไปอีกหลายปีภายใต้การนำของ Qi Wang
  • แม้หลังการส่งต่อความเป็นผู้นำ จะยังมีผู้มีส่วนร่วมหลายคนช่วยดูแลโครงการต่อ แต่ก็ไม่มีผู้รับผิดชอบวิสัยทัศน์ระยะยาวอีกต่อไป

Phase 4: Stasis (ภาวะหยุดนิ่ง)

  • ปัจจุบันการพัฒนา upstream ของ jemalloc ได้ยุติลงแล้ว และ Meta เองก็หันไปกำหนดทิศทางแยกต่างหากตามความต้องการภายใน
  • หนี้ทางเทคนิคของ codebase เดิมมีมากจนจำเป็นต้องรีแฟกเตอร์ครั้งใหญ่ก่อน
  • ความต้องการของ Facebook/Meta และผู้ใช้ภายนอก ไม่สอดคล้องกันอีกต่อไป
  • หากจะกลับมาพัฒนาต่อในอนาคต ก็จะต้องเริ่มจากการสะสางหนี้ทางเทคนิค นับร้อยชั่วโมง ก่อน ซึ่งผู้เขียนเองไม่มีแรงจูงใจจะทำ
  • โดยอิงจากสาขา dev หรือเวอร์ชัน 5.3.0 ยังสามารถทำ external fork ได้ จึงยังเป็นไปได้เสมอที่จะมี โครงการใหม่ที่ต่อยอดจาก fork เกิดขึ้น

ข้อคิดย้อนหลังและบทเรียน

  • ความขัดแย้งที่เกิดจาก การถอดการรองรับ Valgrind ออก มีต้นเหตุจาก การมองไม่เห็นการใช้งานของผู้ใช้ภายนอก
  • แม้แต่ข้อเท็จจริงที่ว่า Android ใช้ jemalloc อยู่ ก็เพิ่งมาทราบ หลังจากผ่านไป 2 ปี
  • แม้โครงการจะเปิดบน GitHub แบบ เปิดเผยเต็มรูปแบบ แต่ ผู้มีส่วนร่วมหลักจากองค์กรภายนอก ก็ไม่สามารถสานต่อได้อย่างยั่งยืน
    • ทั้ง Mike Hommey จาก Firefox และความพยายามย้ายไปใช้ CMake ต่างก็ จบลงแบบไม่สมบูรณ์
  • จากประสบการณ์นี้ การแค่เปิดซอร์สอย่างเดียวไม่ได้ทำให้กลายเป็น โครงการอิสระที่ยั่งยืน
  • ผู้เขียนเน้นว่า โอเพนซอร์สไม่ได้อยู่รอดได้ด้วยการเปิดเผยซอร์สเพียงอย่างเดียว แต่ต้องมีการสร้างผู้มีส่วนร่วมหลักและมี governance ที่ชัดเจน

ถ้อยคำส่งท้าย

  • jemalloc เป็นประสบการณ์ที่พิเศษแม้สำหรับผู้เขียนซึ่งเป็น ผู้สนับสนุน garbage collection มานานกว่า 25 ปี
  • แม้ตอนนี้จะกลับไปโฟกัสกับการพัฒนาระบบ garbage collection อีกครั้ง ผู้เขียนก็ยังขอขอบคุณอย่างลึกซึ้งต่อทุกคนที่เคยร่วมมือกับ jemalloc

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
ganadist 2025-06-14

มีฉบับแปลข้อความเต็มด้วย
https://rosettalens.com/s/ko/jemalloc-postmortem
 
GN⁺ 2025-06-14
ความคิดเห็นใน Hacker News

  • ผมเข้าใจการตัดสินใจที่จะ archive upstream repository ก่อนออกจาก Meta ทีม Jemalloc ของเราก็ไม่มีแรงพอจะรับมือกับ issue สารพัดที่เข้ามาบน GitHub อยู่แล้ว (เช่น เคยมีคนเปิด issue ว่าเทสต์ไม่ผ่านบน Itanium ซึ่งสำหรับผมมันค่อนข้างขำอยู่เหมือนกัน) ถึงอย่างนั้นพอเห็นสถานการณ์แบบนี้ก็ยังรู้สึกเสียดายอยู่ ทุกวันนี้ผมก็ยังมองว่า jemalloc เป็นตัวเลือกที่ทั้งแรงและใช้งานง่ายที่สุดในบรรดา malloc implementation แบบใช้งานทั่วไป TCMalloc ก็ยอดเยี่ยม แต่ถ้าไม่ได้ใช้ bazel จะใช้งานได้ลำบากมาก (ช่วงนี้ bazel 7.4.0 เพิ่ม cc_static_library เข้ามา ทำให้ export เป็น static library ง่ายขึ้นเล็กน้อย แต่ประเด็นนี้ก็ยังมีนัยสำคัญอยู่) ตอนนี้ผมตั้งใจว่าจะไปถาม Qi ว่าก่อนจะ archive repository อีกรอบ พอจะออกรุ่น 6.0 ปิดท้ายได้ไหม ถ้าเป็น release สุดท้ายก็น่าจะปรับค่าเริ่มต้นให้ทันสมัยขึ้นหน่อยได้ ตัวอย่างเช่น ปิดค่า cache oblivious ที่ชื่อชวนสับสนจากค่า default เพื่อกันไม่ให้ size-class 16 KiB บวมเป็น 20 KiB โดยไม่จำเป็น นี่น่าจะเป็นการปรับปรุงใหญ่ ไม่ได้จะตำหนิการตัดสินใจเดิม (คือการตัดสินใจช่วงแรกของ Jason) เพราะตอนคุยเรื่องนี้กับ Qi และ David เหตุผลเรื่อง TLB associativity ที่โดยทั่วไปสมัยนั้นต่ำกว่าปัจจุบันมากก็ฟังขึ้นอยู่ ในทำนองเดียวกัน การเพิ่มค่า page size เริ่มต้นจาก 4 KiB เป็นค่าที่ใหญ่ขึ้น (ราว 16 KiB) ก็น่าจะเป็นการเปลี่ยนแปลงที่ดี เพราะจะเลื่อนเกณฑ์ของ large size-class (จุดที่หยุดเอาหลาย allocation ไปลงใน slab แล้วเปลี่ยนเป็นจัดสรรเป็นช่วงแยกแต่ละก้อน) จาก 16 KiB เป็น 64 KiB ซึ่งมีผลมาก ก่อนผมออกจาก Meta ครั้งสุดท้ายที่พิจารณาจะใช้การเปลี่ยนแปลงนี้กับบริการภายในหลัก มันเป็น optimization ที่ลดการใช้ CPU ลงได้หลายเปอร์เซ็นต์ แลกกับการใช้หน่วยความจำเพิ่มขึ้นเล็กน้อยจาก RAM fragmentation นอกจากนี้ยังมีอีกสองสามอย่างที่อยากเปลี่ยน (เช่น เปลี่ยนค่า default ของ metadata_thp จาก disabled เป็น auto, ปรับ extent sizing ของ slabs จากเดิมที่ต้องเป็นพหุคูณตรงตัวของ page size ไปเป็นแบบยอมเสียพื้นที่ราว 1% เพื่อแลกลด fragmentation เป็นต้น) แต่ค่าที่พูดถึงก่อนหน้านี้น่าจะเป็นการเปลี่ยนแปลงที่ใหญ่ที่สุด

    • คนที่เปิด issue เรื่อง Itanium test suite ล้มเหลวนั่นก็คือผมเอง

    • เรื่องเล่าจากประสบการณ์จริงหรือ insight จากคนวงในแบบนี้แหละที่ทำให้ผมยังกลับมา Hacker News อยู่เรื่อย ๆ ผมสงสัยว่าทำไม TCMalloc ถึงใช้งานยากถ้าไม่มี bazel (ถามด้วยความอยากรู้จริง ๆ)

    • ผมหวังว่าความรู้ภายในสำคัญ ๆ แบบนี้จะถูกเผยแพร่ในรูปเอกสารทางการหรือบทความบล็อกที่ขยายความมากกว่านี้ ตอนนี้เอกสารทางการดูบางเกินไปจริง ๆ อยากให้ know-how จากงานจำนวนมากที่ทำกันใน Meta ถูกแบ่งปันก่อนที่เวลาจะทำให้มันหายไป

    • น่าเสียดายที่ซอฟต์แวร์ยอดเยี่ยมแบบนี้กลับไม่ได้ถูกใช้ให้เต็มที่ เพราะขั้นตอน build และ integration ซับซ้อนเกินไป

    • คุณพูดถึงว่า “ทีม Jemalloc ไม่มีแรงพอจะรับมือกับ random issue ที่เข้ามาบน GitHub” เลยอยากถามว่าเบื้องหลังที่ทำให้การดูแล issue ไม่ราบรื่นคืออะไร ทั้งที่จากภายนอกดูเหมือน Meta น่าจะมีคนพอดูแลโปรเจ็กต์นี้อยู่แล้ว ถ้าผมเข้าใจผิดก็ช่วยแก้ไขด้วย

  • ผมอยากเล่าว่างานของ Jason ส่งผลต่อการทำงานของเรามากแค่ไหน บริษัทเรามีขนาดค่อนข้างใหญ่และประมวลผลภาพ/วิดีโอวันละหลายร้อยล้านรายการ ช่วงหลายปีแรกเราทรมานกับปัญหา memory fragmentation มาก แล้ววันหนึ่งเราก็นำ jemalloc มาใช้ เปลี่ยนแค่สองบรรทัดใน Dockerfile ปัญหาทั้งหมดก็หายไป ทุกวันนี้เราเป็นบริษัทที่มีรายได้ระดับหลายหมื่นล้าน และทุก service กับทุก Dockerfile ก็ใช้ jemalloc อยู่ ขอบคุณจากใจจริง

    • ในทางปฏิบัติ service จัดการภาพที่เขียนด้วย golang จำนวนมากก็แนะนำหรือใช้งาน jemalloc อยู่ 3 อันดับแรกในหัวข้อ resize-images ณ วันที่ 2025-06-13 คือ imaginary ใช้งาน แบบนี้ใน Dockerfile, ส่วน imgproxy ก็มีการพูดถึงใน repo ของ imaginary โดยอ้างอิง เอกสารที่ถูก archive ไว้ และ imagor ก็ใช้ jemalloc ที่ตำแหน่งนี้

    • ถามด้วยความอยากรู้จริง ๆ (ไม่ได้ประชดเลย): แล้วได้บริจาคด้วยไหม เพราะการแสดงความขอบคุณด้วยเงินก็น่าจะเป็นการขอบคุณที่ดีที่สุดไม่ใช่หรือ

  • เรื่องความเห็นที่ว่า “jemalloc ถูกถอดออกจาก Rust binary เร็วเกินคาด” ผมอยากแชร์ว่าในความเป็นจริง issue นั้นเป็นเพียงหนึ่งในหลายสาเหตุ ดูเบื้องหลังได้จากคอมเมนต์นี้ และ jemalloc ก็ไม่ได้ถูกถอดออกทั้งหมดจนกระทั่งผ่านไปถึง 2 ปีหลังจากที่มีการยก issue นี้ขึ้นมาครั้งแรก (อ้างอิง: PR นี้)

    • ในหลาย issue ที่พูดถึงตรงนั้น ผมว่าน่าสนใจที่ปัญหา page size แบบ hardcoded บน arm64 ยังไม่ได้รับการแก้ไขใน upstream จนถึงทุกวันนี้ เรื่องนี้ทำให้นักพัฒนาแอปต้องปล่อย arm64 Linux binary แยกหลายตัว หรือไม่ก็ยอมทิ้งการรองรับบางแพลตฟอร์มไปเลย ถ้าตอนนั้นรองรับ dynamic page size (ด้วยการใช้ binary patch แบบ ftrace เพื่อ performance) มันจะช้าลงกว่าตอนนี้มากไหมก็น่าคิด

  • ผมติดนิสัยไปแล้วว่าจะใช้ jemalloc ใน game engine ทุกตัวที่ทำมาตลอดหลายปี บน win32 มันเร็วกว่า allocator ปริยายมาก และการใช้ allocator เดียวกันทุกแพลตฟอร์มก็มีข้อดีมาก ผมรู้จัก jemalloc ตอนที่มันถูก integrate เข้า FreeBSD แล้วหลังจากนั้นก็ใช้มาโดยตลอด รู้สึกภูมิใจที่ jemalloc ช่วยสร้างความสนุกให้กับผู้เล่นเกมจำนวนมาก

    • allocator ปริยายของ windows ห่วยจริง ๆ ผมมั่นใจว่า jemalloc ดีที่สุด

  • เป็นบทความที่ดีมาก — ผมสงสัยว่า Facebook (ตอนนี้คือ Meta) เลิกใช้ jemalloc เองไปแล้ว หรือแค่เข้าสู่ช่วงดูแลรักษาเท่านั้น หรือมีโอกาสเปลี่ยนไปใช้ tcmalloc หรือ allocator ตัวอื่นหรือเปล่า มีประโยคหนึ่งว่า “ในวิศวกรรมโครงสร้างพื้นฐานของ Facebook จุดเน้นย้ายจากการลงทุนใน core technology ไปเป็น ROI มากขึ้น”

    • ตอนผมลาออกจาก Meta เมื่อเกือบ 2 ปีก่อน (และคิดว่าคงยังไม่ได้เปลี่ยนไปมาก) jemalloc ก็ยังถูก static link อยู่ใน binary ทุกตัวภายใน Meta สำหรับคำถามว่าจะเปลี่ยนไปใช้ tcmalloc หรือ allocator ตัวอื่นได้ง่ายไหม คำตอบคือยากกว่าที่คิด เพราะ jemalloc ผูกอยู่ลึกมากกับ ecosystem ภายในบริษัท ตั้งแต่ Strobelight telemetry plumbing ไปจนถึง extensions จำนวนมากที่ใช้งานตามแบบของ jemalloc (เช่น manual arena ที่ใช้ custom extent hook โดยตรง) รวมถึงความจริงที่ว่าแอปส่วนใหญ่พัฒนามาให้ดึงคุณลักษณะของ jemalloc ออกมาใช้ได้เต็มที่

    • ถ้าจะพูดถึงการเปลี่ยนแปลงใหญ่ล่าสุด ก็คือ long-term maintainer ของ jemalloc ลาออกกันหมดแล้ว แต่ในอีกด้านหนึ่ง ภายใน Facebook กลับเริ่มสนใจโปรเจ็กต์นี้มากกว่าเดิม และหลังจากผ่าน issue ที่ค่อนข้างเป็นประเด็นมาบางส่วน ก็หวังว่าในอนาคตจะเดินไปในทิศทางที่คำนึงถึงทั้ง Qi, Jason และผู้ใช้ภายนอกมากขึ้น

    • Meta ยังพัฒนา fork ของตัวเองอย่าง active อยู่ ที่นี่

  • เป็นเกียรติมากที่ผมได้มีส่วนร่วมกับงานที่มีอิทธิพลต่อเนื่องยาวนาน ตั้งแต่ Firefox จนถึง Facebook

    • ผมเองก็อยากทิ้งข้อความขอบคุณไว้ตรงนี้ในจังหวะที่เหมาะสมเหมือนกัน ไม่คิดเลยว่าบทความนี้จะขึ้นวันนี้ แต่ก็รู้สึกเป็นเกียรติที่ได้เป็นส่วนเล็ก ๆ ของการเดินทางอันยิ่งใหญ่นี้ ขอขอบคุณ @je, qi, david รวมถึงผู้มีส่วนร่วมทั้งในยุคนั้นและหลังจากนั้นด้วย

    • ผมคิดว่าความเป็นผู้นำของคุณที่ผลักดันให้ Facebook ลงทุนกับ core technology ต่อไปนั้นออกดอกออกผลได้มากที่สุดแล้ว เพราะนั่นเป็นพื้นฐานที่ทำให้นวัตกรรมอย่าง GraphQL, PyTorch และ React เกิดขึ้นได้

  • คำพูดอ้างอิง FTA ที่ว่า “เมื่อมีแต่ทางเลือกที่เป็นไปไม่ได้ คนเราก็เหลือแค่ 1) ตัดสินใจแย่ ๆ ภายใต้แรงกดดันมหาศาล 2) ยอมจำนนภายใต้แรงกดดันมหาศาล หรือ 3) หาทางอ้อม” ฟังดูยากจะเชื่อว่าเป็นบรรยากาศการทำงานจริง

    • น่าเศร้าที่ที่ทำงานแทบทุกแห่งที่ผมเจอมาตั้งแต่ปี 2008 ก็เป็นแบบนั้นทั้งนั้น

  • ผมคิดว่า jemalloc เป็น allocator ตัวเดียวที่บน macOS สามารถ override malloc/free ได้ลื่นไหลแบบ LD_PRELOAD (อย่างน้อยก็ราวปี 2020) เพราะมันสามารถแทรกตัวเป็น allocator ปริยายได้ง่ายผ่านกลไกแบบ zone และยังเข้ากับข้อกำหนด allocator เฉพาะของ Apple ได้ดี allocator third-party ตัวอื่นมักพลาดเพราะข้อกำหนดพวกนี้

    • แต่แนวทางนี้ใช้ได้ก็ภายใต้สมมติฐานว่า system allocator ของ macOS จะไม่เปลี่ยนโครงสร้างภายใน ซึ่งผมจำได้ว่า Apple เคยเปลี่ยนจนมันพังไปประมาณสองครั้ง

    • ผมเข้าใจว่า mimalloc ก็น่าจะทำแบบเดียวกันได้ แต่ไม่แน่ใจนัก

  • เท่าที่ผมเห็น jemalloc เหนือกว่า malloc ของ glibc แทบทุกด้าน และใน benchmark ก็มักทำผลงานได้ดีกว่าเสมอ เลยสงสัยในฐานะคนนอกว่าทำไมมันถึงไม่กลายเป็น allocator ปริยาย

    • บน FreeBSD นั้น jemalloc เป็นค่า default อยู่แล้ว ถ้าอยากเปลี่ยน malloc วิธีที่ง่ายกว่าก็คือเปลี่ยน libc ไปใช้ FreeBSD libc ด้วย และถ้าจะทำแบบนั้นก็แทบจะต้องเปลี่ยน kernel เป็น FreeBSD ไปเลย ตอนที่บริษัทเราไปรวมกับ Facebook ผมตื่นเต้นมากที่ได้แนะนำ jemalloc ให้พนักงานฝั่งนั้น แต่สุดท้ายมันกลับเป็นเรื่องธรรมดาเกินไปสำหรับฝั่งที่ใช้ FreeBSD อยู่แล้ว

    • ผมไม่ใช่วิศวกร allocator เลยให้ความเห็นแบบผู้เชี่ยวชาญไม่ได้ แต่เคยคุยกับวิศวกรที่ดูแล OS allocator มาก่อน เขาบอกว่า custom allocator มักทำให้ process หนึ่งได้เปรียบอย่างมากในเรื่อง allocation แต่ทำให้ fairness ของ allocation ทั้งระบบแย่ลง ในมุมของ system allocator ถ้าแต่ละ process มีรูปแบบต่างกันไป การ optimize ทั้งระบบก็ยากขึ้น เพราะอย่างนี้ในสภาพแวดล้อมแบบ service ส่วนใหญ่ jemalloc จึงมักถูกแนะนำภายใต้สมมติฐานว่า “ตอนนี้ process ของฉันสำคัญที่สุด”

    • ผมไม่คิดว่าจะมีเหตุผลทางเทคนิคที่ทำให้ jemalloc เป็น allocator ปริยายไม่ได้ จริง ๆ บน FreeBSD มันก็เป็น default อยู่แล้ว (ตามที่บทความบอก) ตามความเข้าใจของผม ประเด็นนี้เป็นเรื่องการเมืองมากกว่าเรื่องเทคนิค

    • jemalloc ผ่านการพิสูจน์แล้วใน production ขนาดใหญ่จริง ใบอนุญาตก็เปิดกว้างมาก ประสิทธิภาพก็ได้รับการยืนยันแล้ว แล้วเหตุผลอะไรที่ยังต้องยึดติดกับ glibc malloc? นอกจาก “ความบริสุทธิ์เชิงอุดมการณ์” กับแรงเฉื่อยของระบบเก่า ผมสงสัยจริง ๆ ว่ามีใครได้ประโยชน์จากสภาพนี้ ทำไมยังอ้างว่า “เพื่อความเข้ากันได้” อยู่ได้

    • เมื่อก่อนปัญหาใหญ่ของ allocator ทางเลือกคือมันไม่ยอมคืนหน่วยความจำที่ free แล้วกลับให้ OS เลย เอาแต่ค้างไว้เป็น dirty page (สุดท้ายก็มีการปรับปรุง แต่ก็เป็นตัวอย่างชัดเจนถึงความต่างของลำดับความสำคัญของ allocator) และในความเป็นจริง process ส่วนใหญ่มีแค่ main thread ตัวเดียว หรือไม่ก็แทบมีแต่ thread ที่ idle allocator ที่ optimize เพื่อ multithreading อาจเกินความจำเป็นและกลายเป็นภาระในสภาพแบบนั้น อีกอย่างที่คนส่วนใหญ่มักไม่ค่อยนึกถึงคือ ต้นทุนที่ kernel ต้อง zero หน้า page กับต้นทุนที่ user process ต้อง zero เองเพื่อเอากลับมาใช้ภายในนั้น แทบไม่ต่างกันเท่าไร

  • อยากให้เอาลิงก์บทความบล็อกไปใส่ไว้ใน GitHub repository มากกว่า เพื่อให้คนที่แวะเข้า repo ในอนาคตรู้บริบทนี้และใช้อ้างอิงได้