#experience

Bizning jamoa infrastrukturadagi dasturlarni maintain (qo'llab quvatlab turadi) qiladi. Ish boshlaganimdan 3 oy o'tib menga ham networking'da bir qiziq loyiha berildi va loyiha kodi asosan Rust'da yozilgan ekan (undan oldin asosan C++ da bo'lgan ekan yechim). Loyihani tushunib olishga va Rustga ko'nikishga biroz vaqt ketdi.

Loyiha maqsadi asosan kuniga bir necha ming terabaytlab ma'lumot almashadigan serverlar o'rtasida reliable (ishonchli) yechim qilish bo'lgan. Bu juda katta masshtabli loyiha. Loyihada socket connection, encoding/decoding, async support, va juda ko'p boshqa omillar ro'l o'ynashini juda qiziq dokumentatsiya qilib yozib chiqishgan ekan.

Ushbu loyiha uchun, Go GC (Garbage collector) bor tillardan xisoblangani uchun unda latency (kechikish) tez-tez uchragan ekan (GC spikes), ayniqsa uni grafana bilan monitoring qilganda juda bilindi. Xotiradan ishlatilmayotgan ma'lumotlar darhol o'chishini o'rniga GC ni uyg'onib xotirani scan qilishini kutadi va natijada latency baydo bo'ladi.

Rust meni lol qoldirgan tomoni bu CC (Concurrency Control) bo'ldi. Race condition dan Compile-time da qutilish imkoniyatini berar ekan. Yana bir tomoni Go'da Goroutine'lar runtime-managed, Rust esa sizga threading model tanlash va boshqarishni manually imkon beradi (o'z tabingizga qarab ishlatasiz degani). Data sharing bo'yicha ham Send va Sync yechimlari o'ta go'zal ishlagan, sizga resourslar aro ma'lumotni bo'lishishni ham o'zingiz tanlaysiz (o'zingiz boshqarasiz).

Rust'ni maqtash emas shunchaki undagi xotira bilan ishlash (Memory control) tizimi shunchalik yaxshi ishlaganini va nima uchun ayan Rust memory safe ekanligini qisman, aniqroq tushunib oldim deb o'ylayman.

Misol uchun Go dasturlash tilida mana bunday ish qilsangiz nimalar bo'ladi:

go handleConnection(conn)

Hozir siz:
- gorutine'lar (map, slices, counters, ...) o'rtasida state share qildingiz
- Agar to'g'ri lock qila olmasangiz, data race yuzaga keladi.
- Channel buffer juda kichik bo'lsa, deadlock'ga sabab bo'ladi
- Goroutine leak bo'lsa, silent memory bloat (dastur siz o'ylagandan ko'ra ko'proq resurs yeyishni boshlaydi) sodir bo'ladi

Bunday ishlarni to'liq o'z nazoratingizga olishingiz uchun sizga low-level til kerak bo'ladi, misol uchun Rust yoki C++. O'sha loyihani 25-30% hali ham C++ da turadi, Rust'ni tanlashganini yana bir tomoni aynan o'sha modellarni extend (kengaytirib) qilib ishlatish bo'lgan bo'lsa kerak.

Post ancha uzunroq va sizga tushunarsizroq bo'lgan bo'lishi mumkin. Ammo xavotir olmang, otabek.io da bunday postlarni tushunishingiz uchun ko'proq soddaroq postlar yozishga harakat qilaman. Rust'ni doim ishlatmasakda ammo o'rganayabmiz sekin-asta. Shuning uchun xatolar bo'lsa tushunasiz deb o'ylayman.

#experience

Ikki hafta oldin kompaniyada TechTalk’da "Memory leak" mavzusida ma’ruza berdim. 51 ta turli xil jamoalardan muhandislar kirib eshitishdi, to‘g‘risi ancha qo‘rquv bosdi. Memory leak juda nozik mavzu, agar siz ishlatayotgan tilni mohiyatini yaxshi bilmasangiz xotira bilan ishlashda juda chiroyli muammolarga duch kelishingiz mumkin. Biz asosan Python va Go tillaridan misollar ko‘rib ketdik.

Online meeting orqali qatnasha olganlar juda ajoyib feedback yozishdi. Ularni har hafta o‘qib maza qilyapman. Ma’ruzamning videosi chiqqanidan so‘ng tomosha qilganlar ham yaxshi xabarlar yozishdi, ammo bir yigitni xabari e’tiborimni tortdi. U bu ma’ruzadan keyin tizimdagi memory leak’ni topishga muvaffaq bo‘lgan. 

Ular ishlaydigan tizim kodi Java’da yozilgan ekan. Bilamizki Java ham Garbage collected til hisoblanadi. GC xotirani tozalash uchun reference counting dan foydalanadi. Agar obyekt ishlatiladigan bo‘lsa uni reference count odatda +1 ga teng bo‘ladi. GC juda aqlli bo‘lgani bilan, benuqson emas. 

U yozgan xabarda inner class yozish va uni xotiraga ta’siri haqida gap ketgan. Men uning ma’ruzamda memory leak’ga sabab bo‘lishi mumkinligi haqida misollar bilan yoritib o‘tgan edim. 

Muamo outer class obyekti o‘chib ketganiga qaramay inner class obyekti ishlatilishda davom etishida. Qanday qilib inner class obyekti o‘chib ketmadi deyishingiz mumkin. Sabab, unga reference saqlanib qolgan (ref count +1). Dastur to‘laoqnli to‘g‘ri ishlashini ta’minlash uchun uni o‘chib ketishini ham o‘zingiz dasturlashingizga to‘g‘ri keladi. 

Yana bir bola o‘zining frontend loyhasidan memory leak topganini yozibdi. Closures - outer scope’dagi o‘zgaruvchilarni eslab qola oladi. Agar obyektni saqlab qolsangiz, u reference qilgan qiymatlar ham o‘chmay saqlanib turaveradi degani. Agar ehtiyot bo‘lmasangiz Javascript kodingiz, browser’da leak’ga sababchi ishlar qilishi juda osonligini ko‘rdim. U yuborgan koddan parcha:

function setup() {
  const bigData = new Array(1e6).fill(’leak’);

document.getElementById(’btn’).addEventListener(’click’, function () {
    console.log(bigData[0]);
  });
}

Bunday muammolar ko‘p. Ma’ruza berish orqali faqat o‘rgatmadim, balkim ko‘p o‘rgandim ham. Videoni ommaviy ulashish imkoni bo‘lsa, ulashishni reja qilib turibman. Sizga ham bir parcha tajriba ilindim : )