青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 14,  comments - 57,  trackbacks - 0
  昨天一個同事一大早在群里推薦了一個google project上的開源內(nèi)存分配器(http://code.google.com/p/google-perftools/),據(jù)說google的很多產(chǎn)品都用到了這個內(nèi)存分配庫,而且經(jīng)他測試,我們的游戲客戶端集成了這個最新內(nèi)存分配器后,F(xiàn)PS足足提高了將近10幀左右,這可是個了不起的提升,要知道3D組的兄弟忙了幾周也沒見這么大的性能提升。

如果我們自己本身用的crt提供的內(nèi)存分配器,這個提升也算不得什么。問題是我們內(nèi)部系統(tǒng)是有一個小內(nèi)存管理器的,一般來說小內(nèi)存分配的算法都大同小異,現(xiàn)成的實現(xiàn)也很多,比如linux內(nèi)核的slab、SGI STL的分配器、ogre自帶的內(nèi)存分配器,我們自己的內(nèi)存分配器也和前面列舉的實現(xiàn)差不多。讓我們來看看這個項目有什么特別的吧。

一、使用方法

打開主頁,由于公司網(wǎng)絡(luò)禁止SVN從外部更新,所以只能下載了打包的源代碼。解壓后,看到有個doc目錄,進(jìn)去,打開使用文檔,發(fā)現(xiàn)使用方法極為簡單:
To use TCMalloc, just link TCMalloc into your application via the "-ltcmalloc" linker flag.再看算法,也沒什么特別的,還是和slab以及SGI STL分配器類似的算法。
unix環(huán)境居然只要鏈接這個tcmalloc庫就可以了!,太方便了,不過我手頭沒有l(wèi)inux環(huán)境,文檔上也沒提到windows環(huán)境怎么使用,
打開源代碼包,有個vs2003解決方案,打開,隨便挑選一個測試項目,查看項目屬性,發(fā)現(xiàn)僅僅有2點不同:
1、鏈接器命令行里多了
  "..\..\release\libtcmalloc_minimal.lib",就是鏈接的時候依賴了這個內(nèi)存優(yōu)化庫。
2、鏈接器->輸入->強制符號引用 多了 __tcmalloc。
這樣就可以正確的使用tcmalloc庫了,測試了下,測試項目運行OK!

二、如何替換CRT的malloc

從前面的描述可知,項目強制引用了__tcmalloc, 搜索了測試代碼,沒發(fā)現(xiàn)用到_tcmalloc相關(guān)的函數(shù)和變量,這個選項應(yīng)該是為了防止dll被優(yōu)化掉(因為代碼里沒有什么地方用到這個dll的符號)。
初看起來,鏈接這個庫后,不會影響任何現(xiàn)有代碼:我們沒有引用這個Lib庫的頭文件,也沒有使用過這個dll的導(dǎo)出函數(shù)。那么這個dll是怎么優(yōu)化應(yīng)用程序性能的呢?
實際調(diào)試,果然發(fā)現(xiàn)問題了,看看如下代碼
    void* pData = malloc(100);
00401085 6A 64            push        64h 
00401087 FF 15 A4 20 40 00 call        dword ptr [__imp__malloc (4020A4h)]
跟蹤 call malloc這句,step進(jìn)去,發(fā)現(xiàn)是
78134D09 E9 D2 37 ED 97   jmp         `anonymous namespace'::LibcInfoWithPatchFunctions<8>::Perftools_malloc (100084E0h)
果然,從這里開始,就跳轉(zhuǎn)到libtcmalloc提供的Perftools_malloc了。
原來是通過API掛鉤來實現(xiàn)無縫替換系統(tǒng)自帶的malloc等crt函數(shù)的,而且還是通過大家公認(rèn)的不推薦的改寫函數(shù)入口指令來實現(xiàn)的,一般只有在游戲外掛和金山詞霸之類的軟件才會用到這樣的掛鉤技術(shù),
而且金山詞霸經(jīng)常需要更新補丁解決不同系統(tǒng)兼容問題。

三、性能差別原因

如前面所述,tcmalloc確實用了很hacker的辦法來實現(xiàn)無縫的替換系統(tǒng)自帶的內(nèi)存分配函數(shù)(本人在使用這類技術(shù)通常是用來干壞事的。。。),但是這也不足以解釋為什么它的效率比我們自己的好那么多。
回到tcmalloc 的手冊,tcmalloc除了使用常規(guī)的小內(nèi)存管理外,對多線程環(huán)境做了特殊處理,這和我原來見到的內(nèi)存分配器大有不同,一般的內(nèi)存分配器作者都會偷懶,把多線程問題扔給使用者,大多是加
個bool型的模板參數(shù)來表示是否是多線程環(huán)境,還美其名曰:可定制,末了還得吹噓下模板的優(yōu)越性。
tcmalloc是怎么做的呢? 答案是每線程一個ThreadCache,大部分操作系統(tǒng)都會支持thread local storage 就是傳說中的TLS,這樣就可以實現(xiàn)每線程一個分配器了,
這樣,不同線程分配都是在各自的threadCache里分配的。我們的項目的分配器由于是多線程環(huán)境的,所以不管三七二十一,全都加鎖了,性能自然就低了。

僅僅是如此,還是不足以將tcmalloc和ptmalloc2分個高下,后者也是每個線程都有threadCache的。
關(guān)于這個問題,doc里有一段說明,原文貼出來:
ptmalloc2 also reduces lock contention by using per-thread arenas but there is a big problem with ptmalloc2's use of per-thread arenas. In ptmalloc2 memory can never move from one arena to another. This can lead to huge amounts of wasted space.
大意是這樣的:ptmalloc2 也是通過tls來降低線程鎖,但是ptmalloc2各個線程的內(nèi)存是獨立的,也就是說,第一個線程申請的內(nèi)存,釋放的時候還是必須放到第一個線程池中(不可移動),這樣可能導(dǎo)致大量內(nèi)存浪費。
 

四、代碼細(xì)節(jié)

1、無縫替換malloc等crt和系統(tǒng)分配函數(shù)。

   前面提到tcmalloc會無縫的替換掉原有dll中的malloc,這就意味著使用tcmalloc的項目必須是 MD(多線程dll)或者M(jìn)Dd(多線程dll調(diào)試)。tcmalloc的dll定義了一個
static TCMallocGuard module_enter_exit_hook;
的靜態(tài)變量,這個變量會在dll加載的時候先于DllMain運行,在這個類的構(gòu)造函數(shù),會運行PatchWindowsFunctions來掛鉤所有dll的 malloc、free、new等分配函數(shù),這樣就達(dá)到了替換功能,除此之外,
為了保證系統(tǒng)兼容性,掛鉤API的時候還實現(xiàn)了智能分析指令,否則寫入第一條Jmp指令的時候可能會破環(huán)后續(xù)指令的完整性。

2、LibcInfoWithPatchFunctions 和ThreadCache。

LibcInfoWithPatchFunctions模板類包含tcmalloc實現(xiàn)的優(yōu)化后的malloc等一系列函數(shù)。LibcInfoWithPatchFunctions的模板參數(shù)在我看來沒什么用處,tcmalloc默認(rèn)可以掛鉤
最多10個帶有malloc導(dǎo)出函數(shù)的庫(我想肯定是夠用了)。ThreadCache在每個線程都會有一個TLS對象:
__thread ThreadCache* ThreadCache::threadlocal_heap_。

3、可能的問題


設(shè)想下這樣一個情景:假如有一個dll 在tcmalloc之前加載,并且在分配了內(nèi)存(使用crt提供的malloc),那么在加載tcmalloc后,tcmalloc會替換所有的free函數(shù),然后,在某個時刻,
在前面的那個dll代碼中釋放該內(nèi)存,這豈不是很危險。實際測試發(fā)現(xiàn)沒有任何問題,關(guān)鍵在這里:
 span = Static::pageheap()->GetDescriptor(p);
    if (!span) {
      // span can be NULL because the pointer passed in is invalid
      // (not something returned by malloc or friends), or because the
      // pointer was allocated with some other allocator besides
      // tcmalloc.  The latter can happen if tcmalloc is linked in via
      // a dynamic library, but is not listed last on the link line.
      // In that case, libraries after it on the link line will
      // allocate with libc malloc, but free with tcmalloc's free.
      (*invalid_free_fn)(ptr);  // Decide how to handle the bad free request
      return;
    }
tcmalloc會通過span識別這個內(nèi)存是否自己分配的,如果不是,tcmalloc會調(diào)用該dll原始對應(yīng)函數(shù)(這個很重要)釋放。這樣就解決了這個棘手的問題。

五、其他

其實tcmalloc使用的每個技術(shù)點我從前都用過,但是我從來沒想過用API掛鉤來實現(xiàn)這樣一個有趣的內(nèi)存優(yōu)化庫(即使想過,也是一閃而過就否定了)。
從tcmalloc得到靈感,結(jié)合常用的外掛技術(shù),可以很輕松的開發(fā)一個獨立工具:這個工具可以掛載到指定進(jìn)程進(jìn)行內(nèi)存優(yōu)化,在我看來,這可能可以作為一個外掛輔助工具來優(yōu)化那些
內(nèi)存優(yōu)化做的很差導(dǎo)致幀速很低的國產(chǎn)游戲。
posted on 2010-07-10 17:32 feixuwu 閱讀(10108) 評論(14)  編輯 收藏 引用 所屬分類: 游戲開發(fā)

FeedBack:
# re: 推薦一個跨平臺內(nèi)存分配器
2010-07-10 19:52 | chaogu
好像內(nèi)存分配策略沒有講明白.....
  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-07-10 20:39 | feixuwu
@chaogu
恩,這篇主要不是講常規(guī)小內(nèi)存分配的,那個到處都在講,沒啥新意了,文章資料里提到的很多都是常規(guī)小內(nèi)存實現(xiàn),也可以直接看代碼或者侯捷的STL源碼剖析,有詳細(xì)內(nèi)容的。  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-08-07 08:27 | maxime
小內(nèi)存分配器主要作用是“減小內(nèi)存碎片化趨勢,減小薄記內(nèi)存比例,提高小內(nèi)存利用率”,從性能上說,系統(tǒng)內(nèi)存分配器已針對小內(nèi)存分配進(jìn)行優(yōu)化,單純使用自定義的小內(nèi)存分配器,對性能幫助不會很大。內(nèi)置分配器意義還是體現(xiàn)在,實現(xiàn)無鎖分配,避免API調(diào)用切換開銷。
CRT自身new-delete會用到500個時鐘周期,而一個CS會消耗50個時鐘周期,一個mutex會用到2000個時鐘周期,以上是無競爭的情況。所以,如果用mutex做互斥,那還不如用系統(tǒng)的分配器;如果用CS,也不見會好多少,因為CS會隨鎖競爭加劇大幅增加時間,甚至?xí)^mutex。
所以結(jié)論是,對于單線程,內(nèi)置分配器有一定的價值;對于多線程,帶鎖內(nèi)置分配器基本上可以無視了(至少對于winxp以后是這樣,win2k好像要打補丁)呵呵,從你說的情況來看,很有可能你們原來的分配器用mutex幫倒忙了。

tcmalloc中的唯一亮點應(yīng)該是,如何做到跨線程歸還內(nèi)存,又能保持高性能,猜想可能使用了某種二級分配策略,內(nèi)存塊可以屬于任何線程的內(nèi)存池,歸還到那個線程內(nèi)存池,就由這個內(nèi)存池管理。由于各個線程的分配和釋放多半不平衡,有線程池會撐滿,有的會不足。估計撐滿的就會歸還到公共內(nèi)存池。第一級分配無鎖,如果內(nèi)存池不足了,就進(jìn)入第二級帶鎖批量分配,而且第二級分配會先從公共內(nèi)存池獲取,如果還不夠,這才使用系統(tǒng)內(nèi)存分配,這該算是第三級分配了。


最后,tcmalloc也是可以用于MT版本的哦,詳見(要翻墻才能看見)http://groups.google.com/group/google-perftools/browse_thread/thread/41cd3710af85e57b  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-08-07 08:31 | maxime
為避免大家翻墻,將原文貼在下面了。另外,如果下載chrome的源代碼,其中就包含了tcmalloc的,它里面已經(jīng)幫你把這篇文章要做的都做了,用腳本的形式。

Hi,

I wanted to post a little information about some changes that I'm
working on finishing up for the windows version of tcmalloc. If
you've ever had trouble overriding malloc/free on windows, you might
find this useful.


With Chrome, we wanted to override the default C runtime allocators
with TCMalloc. Chrome links the C runtime statically (/MT) in
VS2005. Unfortunately, VS2005 does not have a static mechanism to
override all allocators. This sounds easy, but it is not - VS2005 and
VS2008 both use C runtimes with internal functions that cannot be
overridden. We also didn't like the runtime patching approach which
tcmalloc currently uses. So, to get static linkage to work, we take
the C runtime library from Microsoft and remove all heap allocators
from it using the LIB.EXE tool. We then implement stub functions for
the non-overridable functions in the C runtime and manually link
Chrome to use the new library.


If you want to do this too, here are the steps:


Steps
1) Create a slimmed down version of the C Runtime Library. The C
Runtime Library ships with VS2005 in $VCInstallDir\lib\libcmt.lib. We
use the script below to do this.
2) In TCMalloc's config.h, define WIN32_OVERRIDE_ALLOCATORS
3) Modify your DLL or EXE build with the following:
a) link in tcmalloc.lib by adding a Project Dependency to it.
b) in Properties -> Linker -> Input, set "Ignore Specific Library"
to "libcmt.lib"
c) in Properties -> Linker -> Input, add "mylibcmt.lib" to the
"Additional Dependencies" line.


SLIM_CRT.BAT
REM
REM This script takes libcmt.lib for VS2005 and removes the allocation
related
REM functions from it.
REM
REM Usage: prep_libcmt.bat <VCInstallDir> <OutputFile>
REM
REM VCInstallDir is the path where VC is installed, typically:
REM C:\Program Files\Microsoft Visual Studio 8\VC\
REM
REM OutputFile is the directory where the modified libcmt file should
be stored.
REM


SET LIBCMT=%1lib\libcmt.lib
SET LIBCMTPDB=%1lib\libcmt.pdb
SET OUTDIR=%2
SET OUTCMT=%2\libcmt.lib


MKDIR %OUTDIR%
COPY %LIBCMT% %OUTDIR%
COPY %LIBCMTPDB% %OUTDIR%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\malloc.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\free.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\realloc.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\calloc.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\new.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\delete.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\new2.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\delete2.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\align.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\msize.obj %OUTCMT%


LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\heapinit.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\expand.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\heapchk.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\heapwalk.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\heapmin.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\sbheap.obj %OUTCMT%
LIB /IGNORE:4006,4221 /REMOVE:build\intel\mt_obj\smalheap.obj %OUTCMT%
  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-08-07 09:15 | feixuwu
@maxime
同意加鎖的自定義分配器還不如不用的說法(所以說設(shè)計討論在項目中是需要的,除了開發(fā)者,我們大家都不知道項目的多線程分配加鎖了:))。

對“系統(tǒng)內(nèi)存分配器已針對小內(nèi)存分配進(jìn)行優(yōu)化”,這個我觀點覺得有可能(畢竟沒有驗證),不過我倒覺得crt分配小內(nèi)存的至少還是會有個head的,這個浪費免不了了(當(dāng)然tcmalloc現(xiàn)在也是有頭的,一般自己實現(xiàn)的內(nèi)存分配器是不會有頭的),從比例上來說浪費的還是比較多的,這個可以做個實驗驗證,一次分配50M和多次分配10byte至50M,2者進(jìn)程的內(nèi)存差距還是比較明顯的。
好在現(xiàn)在PC和服務(wù)器內(nèi)存越來越大,內(nèi)存分配器的主要焦點都集中在速度上了。

tcmalloc跨線程歸還內(nèi)存,確實是因為所有線程公用了底層的一個分配器,所以跨線程歸還是無需加鎖的(從手冊上看的,不知道博文提了沒有)。
關(guān)于tcmalloc亮點,我倒覺得算法上的小優(yōu)化其實倒沒那么振奮,給我沖擊最大的是產(chǎn)品的可用性,以往一個產(chǎn)品要使用新的內(nèi)存分配器,一般需要改很多代碼,最常見的是將已有類從一個SmallObject之類的類繼承,很麻煩,這方面tcmalloc干的不錯。

最后感謝maxime提供了MT使用tcmalloc的資料,以我從前的看法,靜態(tài)編譯的版本是無法使用tcmalloc的。  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-08-08 11:19 | kingzt
不知道博主能否做出一個外掛式的內(nèi)存優(yōu)化工具分享一下,現(xiàn)在的國產(chǎn)游戲優(yōu)化確實是讓人無語,如果有這個的話情況估計會好很多  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-08-08 11:22 | kingzt
博主能否實現(xiàn)一個這樣的外掛式內(nèi)存優(yōu)化工具分享給國內(nèi)的游戲玩家,現(xiàn)在有的游戲優(yōu)化確實是讓人無語,如果有這個的話情況估計會好很多  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-09-15 01:08 | 求助啊
請問如何在MFC程序中使用此tcmalloc?
能說下嗎?
多謝了。
  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-09-17 21:03 | Roger
@求助啊
我在我的VS2003工程中用到TCMalloc,此功能有很多其他DLL模塊.
出現(xiàn)2個問題:
1。 有些DLL模塊在TCMall模塊之前加載,并且分配了內(nèi)存,此時不能被TCMalloc管理
2。 在進(jìn)程退出時異常崩潰
出現(xiàn)在:(*invalid_free_fn)(ptr)
好像是地址無效了.
我猜想是:hook其他dll模塊的函數(shù),而此時的dll模塊已經(jīng)卸載了,因此此指針函數(shù)無效.
// This lets you call back to a given function pointer if ptr is invalid.
// It is used primarily by windows code which wants a specialized callback.
inline void do_free_with_callback(void* ptr, void (*invalid_free_fn)(void*)) {
if (ptr == NULL) return;
ASSERT(Static::pageheap() != NULL); // Should not call free() before malloc()
const PageID p = reinterpret_cast<uintptr_t>(ptr) >> kPageShift;
Span* span = NULL;
size_t cl = Static::pageheap()->GetSizeClassIfCached(p);

if (cl == 0) {
span = Static::pageheap()->GetDescriptor(p);
if (!span) {
// span can be NULL because the pointer passed in is invalid
// (not something returned by malloc or friends), or because the
// pointer was allocated with some other allocator besides
// tcmalloc. The latter can happen if tcmalloc is linked in via
// a dynamic library, but is not listed last on the link line.
// In that case, libraries after it on the link line will
// allocate with libc malloc, but free with tcmalloc's free.
(*invalid_free_fn)(ptr); // Decide how to handle the bad free request
return;
}  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2010-09-17 21:03 | Roger
我的QQ:roger201008@qq.com  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器[未登錄]
2011-08-25 22:12 | Lee
很奇怪,我在MFC工程里面把tcmalloc編譯進(jìn)去,vc居然報內(nèi)存泄漏。
我的環(huán)境是vc2010.
不知道可否有人碰到這個情況啊?  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2012-11-16 18:06 | gohay
大哥,tcmalloc 不是通過API掛鉤來實現(xiàn)無縫替換系統(tǒng)自帶的malloc等crt函數(shù)的。
tcmalloc是通過靜態(tài)全局變量的初始化早于main函數(shù)這個原理搞的,它定義了一個全局變量(tcmalloc.cc 文件中920行) static TCMallocGuard module_enter_exit_hook;
在TCMallocGuard這個類的構(gòu)造函數(shù)中做了一大堆事情用來替換系統(tǒng)自帶的malloc等crt函數(shù)  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2012-11-29 14:21 | feiwu
@gohay
抱歉我沒說清楚。
你說的那個是在tcmalooc在linux下的做法。在windows下就是改寫指令來處理的。
linux下不能掛鉤,但是可以先加載來覆蓋系統(tǒng)crtAPI,相比之下,linux下做這個更容易,linux甚至都不同編譯進(jìn)去就可以直接用。  回復(fù)  更多評論
  
# re: 推薦一個跨平臺內(nèi)存分配器
2013-05-17 22:02 | leehark
在windows下怎么做堆檢測呢?  回復(fù)  更多評論
  
<2010年8月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
2930311234

文章轉(zhuǎn)載請注明出處

常用鏈接

留言簿(11)

隨筆分類

隨筆檔案

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产午夜精品麻豆| 亚洲永久精品大片| 久久久久久综合| 国内成人精品2018免费看 | 欧美亚洲网站| 激情六月婷婷久久| 另类尿喷潮videofree| 美女国产一区| 亚洲精品久久久久| 99精品国产在热久久下载| 欧美性事免费在线观看| 久久国产免费| 免费视频亚洲| 亚洲一区二区三区四区五区黄| 亚洲午夜av在线| 国产亚洲成av人片在线观看桃 | 欧美在线观看视频在线 | 欧美婷婷六月丁香综合色| 国产精品v欧美精品v日本精品动漫| 亚洲综合成人婷婷小说| 久久精品国产99国产精品澳门| 亚洲欧洲另类| 99视频精品免费观看| 国产午夜精品理论片a级探花 | 亚洲欧洲一区二区三区在线观看| 一区二区欧美在线观看| 极品少妇一区二区三区精品视频 | 久久精品99无色码中文字幕| 免费欧美电影| 欧美一级视频精品观看| 免费欧美日韩| 久久久久久久综合| 欧美日韩一级片在线观看| 久久久亚洲成人| 欧美日韩久久| 美女网站久久| 国产视频精品va久久久久久| 91久久精品www人人做人人爽| 国产精品女人网站| 最新成人av网站| 影音先锋亚洲一区| 羞羞漫画18久久大片| 99国产精品久久久久久久| 久久精品女人的天堂av| 欧美一级电影久久| 欧美日韩国产影院| 亚洲高清在线观看一区| 亚洲福利视频在线| 久久精品一二三| 欧美在线一区二区| 国产精品九九| 正在播放欧美一区| 亚洲午夜精品福利| 欧美日韩国产美| 亚洲人成网站999久久久综合| 亚洲国产精品电影| 久久蜜桃精品| 麻豆精品在线观看| 精品va天堂亚洲国产| 久久gogo国模裸体人体| 久久久.com| 国内自拍一区| 久久九九热免费视频| 久久久综合免费视频| 国内精品久久久久久| 久久精品国产一区二区电影| 老司机精品视频一区二区三区| 国产主播一区二区三区| 久久人人看视频| 欧美国产91| 99热精品在线| 欧美午夜电影一区| 亚洲欧美日韩综合| 久久久精品性| 亚洲高清在线观看| 欧美激情视频给我| 一本综合精品| 久久久久青草大香线综合精品| 国产一区二三区| 久久久欧美精品sm网站| 亚洲国产精品一区二区第一页| 日韩视频一区二区三区| 亚洲免费观看在线观看| 欧美激情国产日韩| 亚洲精品亚洲人成人网| 欧美精品xxxxbbbb| 亚洲主播在线观看| 久久手机免费观看| 日韩午夜av| 国产欧美日韩| 嫩模写真一区二区三区三州| 亚洲精品乱码久久久久久按摩观| 亚洲欧美激情诱惑| 亚洲承认在线| 欧美午夜视频一区二区| 久久精品视频亚洲| 日韩亚洲成人av在线| 久久久久国内| 一区二区三区久久久| 国产欧美日韩一区二区三区| 麻豆av一区二区三区| 亚洲一卡二卡三卡四卡五卡| 久久免费高清视频| 亚洲一品av免费观看| 在线观看精品| 国产精品人成在线观看免费| 美国十次成人| 亚洲欧美日韩国产成人| 91久久精品日日躁夜夜躁欧美| 性欧美大战久久久久久久免费观看| 亚洲国产婷婷香蕉久久久久久| 国产精品人人做人人爽| 欧美精品福利在线| 久久久爽爽爽美女图片| 亚洲影视在线播放| 亚洲黄色成人| 美女诱惑一区| 久久久一区二区三区| 亚洲影院在线| 99re亚洲国产精品| 亚洲国产免费| 国语自产精品视频在线看一大j8| 国产精品国产三级欧美二区 | 久久aⅴ国产紧身牛仔裤| 99国产精品国产精品毛片| 欧美成人综合| 美国三级日本三级久久99| 欧美在线视频导航| 亚洲在线1234| 亚洲一二三区在线| 99国内精品久久| 亚洲精品中文字| 亚洲破处大片| 91久久线看在观草草青青| 一区二区三区在线观看国产| 国产在线精品成人一区二区三区 | 国内成+人亚洲+欧美+综合在线| 国产精品啊v在线| 欧美日韩人人澡狠狠躁视频| 欧美护士18xxxxhd| 欧美黄色视屏| 欧美日韩成人网| 欧美区二区三区| 欧美精品一区三区| 欧美日韩一区二区精品| 欧美色图天堂网| 国产精品美女久久久久av超清 | 国产欧美日韩一区二区三区在线观看| 欧美色图首页| 国产欧美视频一区二区三区| 亚洲日本中文字幕区| 久久久久99| 久久精品女人天堂| 久久精品视频播放| 美女精品国产| 亚洲国产成人精品久久| 亚洲精品美女| 亚洲性感激情| 久久人人爽人人| 欧美α欧美αv大片| 欧美日韩国产综合网| 国产精品久久久爽爽爽麻豆色哟哟| 国产精品一区二区三区观看| 国产一区二区激情| 亚洲精品免费在线观看| 亚洲欧美日韩在线播放| 久久精品国产精品亚洲| 老司机免费视频一区二区| 亚洲国产日韩美| 亚洲在线视频网站| 免费成人黄色av| 国产精品久久久久久久久免费樱桃 | 亚洲国产精品一区二区尤物区 | 黄色工厂这里只有精品| 亚洲欧洲在线播放| 欧美亚洲综合另类| 亚洲电影观看| 午夜免费日韩视频| 欧美成人午夜剧场免费观看| 国产精品丝袜xxxxxxx| 亚洲国产日本| 性一交一乱一区二区洋洋av| 免费高清在线一区| 中日韩美女免费视频网址在线观看 | 亚洲国产欧美国产综合一区| 亚洲视频综合| 牛人盗摄一区二区三区视频| 99riav1国产精品视频| 久久综合网络一区二区| 国产精品美女久久久久久免费| 亚洲国产精品一区| 欧美一区二区精品在线| 亚洲全黄一级网站| 久久蜜桃资源一区二区老牛| 国产精品美女一区二区在线观看| 亚洲欧洲美洲综合色网| 久久一日本道色综合久久| 亚洲少妇在线| 欧美日韩极品在线观看一区| 在线观看一区|