Android Studioのメモリサイズ設定と原理

7315 ワード

http://www.cnblogs.com/justinzhang/p/4274985.html
http://tsroad.lofter.com/post/376316_69363ae
Android studio 1.0.2デフォルトの最大メモリは750 Mで、このように走るのはとてもカードで、我慢しにくくて、機械は固体ハードディスクではありませんて、最後に発見して、このデフォルト値は修正することができて、android studioディレクトリの下で見つけます:studio 64.exe.vmoptionsファイル、緑の部分が修正されたパラメータ(-Xmx 1050 m)、デフォルトのパラメータを1050 MBに変更すると、走るのがスムーズになります.まだスムーズではないと思ったら、もっと高く変更できます.
-Xms128m
-Xmx1050m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=96m
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djna.nosys=true
-Djna.boot.library.path=

-Djna.debug_load=true
-Djna.debug_load.jna=true
-Djsse.enableSNIExtension=false
-XX:+UseCodeCacheFlushing
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-Didea.platform.prefix=AndroidStudio
-Didea.paths.selector=AndroidStudio


Macシステムの下でAndroid studioパッケージの内容のcontents-bin-studio.vmoptions
Android Studio 设置内存大小及原理_第1张图片
この設定が有効でない場合は、File->Ivalidate Cachesで、Ivalidate and Restartを選択すると有効になります.
Android Studio 设置内存大小及原理_第2张图片   Android Studio 设置内存大小及原理_第3张图片
最後に、studio 64は、リソースマネージャで見ることができる.exeのメモリ占有率は一瞬にして1 GB以上に上昇した.
Android Studio 设置内存大小及原理_第4张图片
————————————————————————————————————————————
Android Studioの起動パラメータから知った以下のJVMのもの(メモリ使用、JITなど)
Android Studioを使ってカードをよく感じるのは、システムがASに割り当てたメモリが足りないためかもしれません./APplications/Android Studioを開きます.app/Contents/bin/studio.vmoptions(Mac)では、以下の構成が見られます.
-Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -XX:+UseCompressedOops
これらのパラメータはそれぞれどういう意味ですか?
-Xms128m
The -Xms option sets the initial and minimum Java heap size. The Java heap (the “heap”) is the part of the memory where blocks of memory are allocated to objects and freed during garbage collection.
つまり、JVMが起動した最初のスタックメモリであり、スタックメモリはオブジェクトに割り当てられたメモリである.ここで512 mに変更しました
-Xmx750m
This option sets the maximum Java heap size.
つまりAndroid Studioで使える最大heapメモリ、ここで2048 mに変更しました
どちらのパラメータも-Xで始まり、非標準のパラメータを表します.非標準とは何ですか.JVMには多くの実装があることを知っています.Oracleの、OpenJDKなど、ここの-Xパラメータは、OracleのJVM実装で使用されています.OpenJDKは必ずしも使用できるとは限りません.つまり、これらのパラメータを標準化していないので、すべてのJVM実装で使用できます.
-XX:MaxPermSize=350m
このパラメータは最大Permanent generationサイズを指定します.Oracleベースのドキュメント:
Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
Permanent Generationもメモリ領域であり、heapとは異なり、その中に格納されている事類自体(オブジェクトではない)、方法、固定された文字列などが知られています.Permanent Generationについて
-XX:ReservedCodeCacheSize=90m
ReservedCodeCacheSize (and InitialCodeCacheSize) is an option for the (just-in-time) compiler of the Java Hotspot VM. Basically it sets the maximum size for the compiler's code cache.
JIT java compilerのcompile時の最大コードキャッシュを設定します.簡単に言えば、JIT(Just In Time)コンパイラはコードをコンパイルする際に、いくつかのものをキャッシュする必要があります.このパラメータは、これらのものをキャッシュするために最大どれだけのメモリを使用できるかを指定します.JITとは何ですか.wikipediaの説明を見てください.
In computing, just-in-time compilation (JIT), also known as dynamic translation, is compilation done during execution of a program – at run time – rather than prior to execution.Most often this consists of translation to machine code, which is then executed directly, but can also refer to translation to another format. JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both.[1] Roughly, JIT compilation combines the speed of compiled code with the flexibility of interpretation, with the overhead of an interpreter and the additional overhead of compiling (not just interpreting). JIT compilation is a form of dynamic compilation, and allows adaptive optimization such as dynamic recompilation – thus in principle JIT compilation can yield faster execution than static compilation. Interpretation and JIT compilation are particularly suited for dynamic programming languages, as the runtime system can handle late-bound data types and enforce security guarantees.
プログラミング言語は2つに分けられることを知っています.-コンパイル型で、まず人が書いたコードをアセンブリ言語または機械言語に全体的にコンパイルし、1つのコードを実行します.-解釈型は、コンパイルする必要はありません.人が書いたコードを1本ずつ持ってきて、1回実行して、先に1本取って、実行して、終わったら次の1本を取って、それから実行します.
Javaでは、JVMはまずJavaコード全体をbytecodeにコンパイルし、JVM内部でbytecodeコードをもう1つ実行するため、この状況は特殊です.コンパイル型だと言っていますね.bytecodeは機械コードにコンパイルする必要はありません.2つ目はbytecodeを1回実行します.解釈型だと言っていますね.またコンパイルの過程があります.Javaがコンパイル型なのか解釈型なのかは今でも定説がありません.しかし、JavaのJITコンパイル技術を検討することができます.さっき言ったように、bytecodeレベルでは、コードは解釈実行されます.説明型の言語は、コンテキストに基づいてコードを最適化できないため、遅いです.コンパイル型の言語は最適化できます.JavaのJIT技術は、bytecode解釈実行の場合、必ずしも1つの解釈実行ではない.2つ目は、1つのコードを取り、マシンコードにコンパイルして実行することで、コンテキストがあり、コードを最適化できるので、実行速度も速くなる.このように、JIT技術はコンパイル型(高速)と解釈型言語(コードがより柔軟)の両方の利点を組み合わせており、動的言語の実行にとって非常に大きな利点である.
-XX:+UseCompressedOops
このパラメータを使用すると、コード内のリファレンスタイプを32ビットで格納できますが、64ビットのメモリサイズを使用できるようにします.現代の機械は基本的に64ビットであることがわかりますが、この場合、Javaコードのreferenceタイプも64ビットで格納されるようになり、2つの問題が発生します.1.64ビットは32より大きく、メモリが多く占められているのは明らかです.もちろん、この問題はプログラム全体から見れば明らかではありません.システムに1000個の参照が同時に存在していても、多くのメモリは4 Mです.これは重要ではありません.今、携帯電話がいくつかのGを動かすことができないので、大型サーバーは言うまでもありません.もっと重要なのは2つ目です.2.メモリに対してCPUのcacheが小さくてかわいそうで、referenceが32 bitから64 bitになると、cacheに格納できるreferenceの数が急に少なくなります.だから64 bitのreferenceはcacheに対して大きな問題で、そこでこのオプションがあって、システムが32 bitでreferenceを格納することを許可することができて、cacheの中でもっと多くのreferenceを格納することができて、同時にreferenceのアドレス範囲に影響しません.彼らがどうやってやったのか、私にはわかりません.の
以上の3つのパラメータは-Xで始まり、Oracleの説明に従って、
Options that are specified with -XX are not stable and are subject to change without notice.