इस पेज में, सीमित रैम के साथ Basel को चलाने के लिए, फ़्लैग इस्तेमाल करने का तरीका बताया गया है.
कुछ स्थितियों में, हो सकता है कि आप Basel को कम मेमोरी का इस्तेमाल करने देना चाहें. आप
स्टार्टअप फ़्लैग के ज़रिए ज़्यादा से ज़्यादा हीप
--host_jvm_args
--host_jvm_args=-Xmx2g जैसे.
हालांकि, अगर आपके बिल्ड इतने बड़े हैं, तो Baज़र आपको OutOfMemoryError फेंक सकता है
(OOM) जब इसमें ज़रूरत के मुताबिक मेमोरी न हो. आप Basel को कम मेमोरी का इस्तेमाल करने के लिए सेट कर सकते हैं, यहां
नीचे दिए गए कमांड फ़्लैग पास करके, धीमे इंक्रीमेंटल बिल्ड की लागत को हल कर सकते है:
--discard_analysis_cache
--nokeep_state_after_build और --notrack_incremental_state.
ये फ़्लैग उस मेमोरी को कम कर देंगे जिसका इस्तेमाल Ba बैंक ने बिल्ड में किया है, लेकिन इसके लिए इतनी ज़्यादा रकम खर्च करनी होगी अगर फ़्यूचर बिल्ड को स्टैंडर्ड इंक्रीमेंटल बिल्ड के मुकाबले धीमा बनाया जाता है.
इनमें से किसी भी फ़्लैग को एक-एक करके भी भेजा जा सकता है:
--discard_analysis_cache, एक्ज़ीक्यूशन के दौरान इस्तेमाल की गई मेमोरी को कम कर देगा (नहीं विश्लेषण). इंक्रीमेंटल बिल्ड को पैकेज लोडिंग फिर से करने की ज़रूरत नहीं होगी, लेकिन के लिए फिर से विश्लेषण और निष्पादन करना होगा (हालांकि ऑन-डिस्क कार्रवाई कैश दोबारा लागू होने से रोकें).--notrack_incremental_state, Basel के इंटरनल वर्शन में किसी भी किनारे को सेव नहीं करेगा डिपेंडेंसी ग्राफ़, ताकि इंक्रीमेंटल बिल्ड के लिए इसका इस्तेमाल न किया जा सके. अगला बिल्ड उस डेटा को खारिज कर देगा, लेकिन उस तारीख तक उसे अंदरूनी डीबगिंग के लिए सुरक्षित रखा जाता है, जब तक--nokeep_state_after_buildबताया न गया हो.--nokeep_state_after_buildबिल्ड के बाद सारा डेटा खारिज कर देगा, ताकि इंक्रीमेंटल बिल्ड शुरुआत से बनाने चाहिए (डिस्क पर होने वाली कार्रवाई को छोड़कर) कैश मेमोरी में सेव किया जाता है). फ़िलहाल, इससे मौजूदा बिल्ड के ज़्यादा पानी वाले निशान पर कोई असर नहीं पड़ेगा.