you may encounter problem when building android with low ram machine
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.base/java.util.Arrays.copyOf(Arrays.java:3793) at com.intellij.util.ArrayUtil.realloc(ArrayUtil.java:84) at com.intellij.lang.impl.TokenSequence$Builder.resizeLexemes(TokenSequence.java:114) at com.intellij.lang.impl.TokenSequence$Builder.performLexing(TokenSequence.java:77) at com.intellij.lang.impl.PsiBuilderImpl.performLexing(PsiBuilderImpl.java:187) at com.intellij.lang.impl.PsiBuilderImpl.(PsiBuilderImpl.java:160) at com.intellij.lang.impl.PsiBuilderImpl.(PsiBuilderImpl.java:114) at com.intellij.lang.impl.PsiBuilderFactoryImpl.createBuilder(PsiBuilderFactoryImpl.java:37) at com.intellij.lang.java.parser.JavaParserUtil.createBuilder(JavaParserUtil.java:152) at com.intellij.psi.impl.source.JavaFileElementType.parseContents(JavaFileElementType.java:80) at com.intellij.psi.impl.source.tree.LazyParseableElement.lambda$ensureParsed$0(LazyParseableElement.java:189) at com.intellij.psi.impl.source.tree.LazyParseableElement$$Lambda$217/0x0000000100515040.run(Unknown Source) at com.intellij.psi.impl.DebugUtil.performPsiModification(DebugUtil.java:564) at com.intellij.psi.impl.source.tree.LazyParseableElement.ensureParsed(LazyParseableElement.java:188) at com.intellij.psi.impl.source.tree.LazyParseableElement.getFirstChildNode(LazyParseableElement.java:237) at com.intellij.psi.impl.source.tree.CompositeElement.countChildren(CompositeElement.java:432) at com.intellij.psi.impl.source.tree.CompositeElement.getChildrenAsPsiElements(CompositeElement.java:394) at com.intellij.psi.impl.source.PsiJavaFileBaseImpl.getClasses(PsiJavaFileBaseImpl.java:66) at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCliJavaFileManagerImpl$Companion.findClassInPsiFile(KotlinCliJavaFileManagerImpl.kt:263) at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCliJavaFileManagerImpl$Companion.access$findClassInPsiFile(KotlinCliJavaFileManagerImpl.kt:259) at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCliJavaFileManagerImpl.findPsiClassInVirtualFile(KotlinCliJavaFileManagerImpl.kt:229) at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCliJavaFileManagerImpl.findClass(KotlinCliJavaFileManagerImpl.kt:124) at org.jetbrains.kotlin.resolve.jvm.KotlinJavaPsiFacade$CliFinder.findClass(KotlinJavaPsiFacade.java:363) at org.jetbrains.kotlin.resolve.jvm.KotlinJavaPsiFacade.findClass(KotlinJavaPsiFacade.java:123) at org.jetbrains.kotlin.load.java.JavaClassFinderImpl.findClass(JavaClassFinderImpl.kt:36) at org.jetbrains.kotlin.load.java.lazy.descriptors.LazyJavaPackageScope$classes$1.invoke(LazyJavaPackageScope.kt:76) at org.jetbrains.kotlin.load.java.lazy.descriptors.LazyJavaPackageScope$classes$1.invoke(LazyJavaPackageScope.kt:42) at org.jetbrains.kotlin.storage.LockBasedStorageManager$MapBasedMemoizedFunction.invoke(LockBasedStorageManager.java:512) at org.jetbrains.kotlin.load.java.lazy.descriptors.LazyJavaPackageScope.findClassifier(LazyJavaPackageScope.kt:142) at org.jetbrains.kotlin.load.java.lazy.descriptors.LazyJavaPackageScope.getContributedClassifier(LazyJavaPackageScope.kt:132) at org.jetbrains.kotlin.load.java.lazy.descriptors.JvmPackageScope.getContributedClassifier(JvmPackageScope.kt:52) at org.jetbrains.kotlin.resolve.scopes.ChainedMemberScope.getContributedClassifier(ChainedMemberScope.kt:33)
have a check for your build machine
java -XshowSettings 2>&1 | grep Heap
change this line from 2048 to 1024
pctx.StaticVariable("JavacHeapSize", "1024M")
android metalava use a lot of memory
or you can also try adjust linux memory setting
cat /proc/sys/vm/overcommit_ratio
cat /proc/sys/vm/overcommit_memory
But I still fail to build AOSP and seems adding swap has no help for java max heap size
refer: https://stackoverflow.com/a/34858395/1117177
Do. Not. Do this. Get more memory. Java and Swap Do. Not. Mix. Java and Swap are like "Crossing the Streams" Bad. Part of the Java heap will be swapped out, then Java will GC, which will thrash the box terribly, and still part of the heap will be swapped out, and Java will GC again. Rinse and repeat until you finally kill -9 Weblogic. Get more memory, or do without. Swap is not an option. Addenda: You machine has "Virtual Memory" (VM). By adding swap, you extend that VM. When you have more VM than actual memory, then the machine will "swap out" inactive memory pages to the swap space, and then "swap in" pages that want to be active from swap space in to RAM. If you have a bunch of idle processes that rarely need time, this isn't super terrible. But Java magnifies the problem. When you run out of physical RAM, some of that RAM is swapped out to disk. When some of that RAM is Java heap, then you have a big problem when the garbage collector kicks in. Because, in general, the GC touches every page of the heap. That means that all of the heaps pages need to be "active", and thus, "swapped in". But if they don't fit, then you have a problem like the 8 puzzle. Where you're shifting memory in and out from disk. This is called thrashing. A swapped JVM heap that is GC is the text book case of worst case thrashing. The machine is letting you allocate the extra memory because it thinks you have more, since your Virtual Memory (physical RAM + swap) is greater
