詳細(xì)剖析Python源代碼編制過程
Python語言中提供的re模塊能支持正則表達(dá)式,還提供SGML,XML分析模塊,大多數(shù)的開發(fā)人員運(yùn)用Python源代碼進(jìn)行XML程序的開發(fā)和運(yùn)行,在這里拿出來和大家分享一下。
有著很多相似點(diǎn),所以就用這個順序了,Python的GC章節(jié),我打算更多地著眼于實現(xiàn)和我的疑問,Java的GC章節(jié),更多放在使用上。Python是走多種GC技術(shù)路線相結(jié)合的路線的,我以為有可取之處。
首先Python采用了原始的Ref Counting技術(shù)而對于引用計數(shù)解決不了的循環(huán)引用,Python源代碼也采用了Mark-Sweeping進(jìn)行GC。這樣似乎有兩個好處,大量的內(nèi)存回收。分?jǐn)偨o了引用計數(shù)上。
減輕了Mark過程的負(fù)擔(dān),不會造成程序的停頓,而又可以真正的消除循環(huán)引用等造成的真實的內(nèi)存泄露。PyObject_GC_New將會調(diào)用_PyObject_GC_Malloc,其中前者的返回值。
關(guān)注的是對象本身,而后者關(guān)注的是內(nèi)存。實際上,在一塊剛剛分配的內(nèi)存上,對象和它鎖在的內(nèi)存有著如下的關(guān)系:從對象創(chuàng)建的過程來看,Python有如下幾個關(guān)鍵的C實現(xiàn)函數(shù)和結(jié)構(gòu):
- typedef union _gc_head {
- struct {
- union _gc_head *gc_next;
- union _gc_head *gc_prev;
- Py_ssize_t gc_refs;
- } gc;
- long double dummy; /* force worst-case alignment */
- } PyGC_Head;
其實,我本人對這個結(jié)構(gòu)稍有失望,因為要回收一塊內(nèi)存,所占用的資源實在是太多了??赡苁俏姨〖易託饬?,我覺得8個字節(jié)也許剛剛好。老實說,在我心中,已有一個初步的想法,一個對象的管理內(nèi)存,完全僅僅需要8個字節(jié)足夠了,而且整個GC的過程,不需要拷貝和壓縮。
當(dāng)我看代碼的時候,不知道是我對某些技巧不了解,還是LOCK就沒有實現(xiàn),我感覺Python的malloc和free擺放著一對兒沒有用處的LOCK和UNLOCK,【Python 2.5.2】,不知道是不是因為我沒有實際調(diào)試的緣故,還沒有發(fā)現(xiàn)這個宏的玄機(jī)。
老實說,我跟內(nèi)存泄露做了好多年的斗爭了,這次又從中學(xué)到了很多東西(也有從其他的資料),結(jié)合我曾經(jīng)寫過的Ref<T>類中使用的內(nèi)存池,這次構(gòu)造了一個全新的內(nèi)存池,希望可以有用武之地。
注:
【1】我沒有考證過最初的Python源代碼,但是印象里最初的Python只有引用計數(shù)機(jī)制,特別是Ruby 1.9才引入垃圾回收,而以往是采用引用計數(shù)技術(shù)的。
【2】簡直是迫使我查看JVM的源代碼了,但是到了64位的平臺上,這個結(jié)構(gòu)可能發(fā)生更大的變化。
【3】等到我完成了代碼,才能兌現(xiàn)這段話,到時候我會Open Source的。
【編輯推薦】


















