Windows XP पर जावा अधिकतम मेमोरी

Question

मैं हमेशा 32-बिट विंडोज एक्सपी (जावा 1.4, 1.5 और 1.6) पर चलने वाले जावा एसई के लिए 1400 मेगाबाइट आवंटित करने में सक्षम रहा हूं।

java -Xmx1400m ...

आज मैंने जावा 1.5_16 और 1.6.0_07 का उपयोग करके एक नई विंडोज एक्सपी मशीन पर एक ही विकल्प की कोशिश की और त्रुटि मिली:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

परीक्षण और त्रुटि के माध्यम से ऐसा लगता है कि 1200 मेगाबाइट सबसे अधिक है जो मैं इस मशीन पर आवंटित कर सकता हूं।

किसी भी विचार क्यों एक मशीन 1400 और दूसरे केवल 1200 की अनुमति देगा?

संपादित करें: मशीन में 4GB RAM है जिसमें लगभग 3.5GB है जिसे Windows पहचान सकता है।

Comments

आपको कम से कम मेरे अनुभव में 32-बिट शेल या 64-बिट शेल में ऐप चलाने के बीच अधिकतम अंतर दिखाई देगा, हालांकि 64-बिट विंडोजएक्सपी सिस्टम दुर्लभ हैं।

— djangofan

wiki.eclipse.org/Eclipse.ini - oracle.com/technetwork/java/javase/…

— एंड्रयू

Answer 1

ध्यान रखें कि विंडोज में वर्चुअल मेमोरी मैनेजमेंट है और जेवीएम को केवल मेमोरी की आवश्यकता होती है जो इसके एड्रेस स्पेस में सन्निहित है । इसलिए, सिस्टम पर चल रहे अन्य प्रोग्राम आपके ढेर के आकार को प्रभावित नहीं करेंगे। आपके रास्ते में क्या मिलेगा वो है DLL जो आपके एड्रेस स्पेस में लोड हो जाता है। दुर्भाग्य से विंडोज़ में अनुकूलन जो कि लिंक करने के दौरान डीएलएल के स्थानांतरण को कम करता है, यह अधिक संभावना है कि आपके पास एक खंडित पता स्थान होगा। सामान्य सामान से अलग आपके एड्रेस स्पेस में कटौती की संभावना वाली चीजों में सुरक्षा सॉफ्टवेयर, सीबीटी सॉफ्टवेयर, स्पाइवेयर और मैलवेयर के अन्य रूप शामिल हैं। भिन्नताओं के संभावित कारण अलग-अलग सुरक्षा पैच, सी रनटाइम संस्करण, आदि होते हैं। डिवाइस ड्राइवर और अन्य कर्नेल बिट्स का अपना पता स्थान होता है (4GB 32-बिट स्थान के अन्य 2GB)।

आप अपने जेएलएम प्रक्रिया में अपने DLL बाइंडिंग के माध्यम से जाने की कोशिश कर सकते हैं और अपने DLL को अधिक कॉम्पैक्ट एड्रेस स्पेस में रिबेट करने का प्रयास कर सकते हैं। मज़ा नहीं, लेकिन अगर आप हताश हैं ...

वैकल्पिक रूप से, आप केवल 64-बिट विंडोज और 64-बिट जेवीएम पर स्विच कर सकते हैं। दूसरों ने जो सुझाव दिया है, इसके बावजूद कि यह अधिक रैम चबाएगा, आपके पास बहुत अधिक सन्निहित आभासी पता होगा, और 2GB को आवंटित करना तुच्छ होगा।

Comments

मेमरी dll में लोड हो रही है, यह देखने के लिए प्रोसेस एक्सप्लोरर का उपयोग करें। अक्सर कुछ अपडेट किए गए ड्राइवर आपके पते की जगह के बीच में ही चिपके रहेंगे। REBASE कमांड का उपयोग करके आप इन्हें आसानी से बाहर निकाल सकते हैं। हालांकि, ध्यान रखें कि dll फिर से अपडेट होने और चीजों को तोड़ने के अधीन है।

— 1

मैंने इसे कभी उत्तर के रूप में स्वीकार नहीं किया और स्टैकओवरफ्लो ने इसे उत्तर के रूप में चिह्नित किया।

— स्टीव कुओ

@ क्रिसस्टर, क्या 32-बिट विंडोज एक्सपी पर 64-बिट जेवीएम का उपयोग करना संभव है?

— पचेरियर

@Pacerier क्षमा करें, मुझे आपकी क्वेरी याद आ गई। AFAIK, यह संभव नहीं है। ओएस एक्स में 32-बिट कर्नेल के साथ 64-बिट उपयोगकर्ता स्थान के लिए कुछ चालें थीं, लेकिन मैंने विंडोज के लिए ऐसी किसी भी चीज के बारे में नहीं सुना है।

— क्रिस्टोफर स्मिथ

@ChristopherSmith, Btw, आपने उल्लेख किया " सिस्टम पर चल रहे अन्य कार्यक्रम आपके ढेर आकार को प्रभावित नहीं करना चाहिए "। यदि हां, तो हम इस परिणाम की व्याख्या कैसे करते हैं: stackoverflow.com/questions/9303889/… ?

— 3

Answer 2

यह सन्निहित स्मृति के साथ करना है।

यहाँ कुछ जानकारी मिली है जो मैं किसी से पूछ रहा हूं कि "वीएम भगवान" से पहले,

जिस कारण से हमें ढेर के लिए एक सन्निहित स्मृति क्षेत्र की आवश्यकता होती है, वह यह है कि हमारे पास साइड डेटा संरचनाओं का एक समूह है जो ढेर की शुरुआत से (स्केल किए गए) ऑफसेट द्वारा अनुक्रमित होते हैं। उदाहरण के लिए, हम ऑब्जेक्ट संदर्भ अपडेट को "कार्ड मार्क ऐरे" से ट्रैक करते हैं जिसमें प्रत्येक 512 बाइट्स के लिए एक बाइट होता है। जब हम ढेर में एक संदर्भ संग्रहीत करते हैं तो हमें कार्ड मार्क सरणी में संबंधित बाइट को चिह्नित करना होगा। हम सही दुकान के गंतव्य पते को शिफ्ट करते हैं और कार्ड चिह्न सरणी को अनुक्रमित करने के लिए इसका उपयोग करते हैं। मजेदार अंकगणित खेलों को आप जावा में नहीं कर सकते हैं जो आपको (++ को C ++ में खेलना है)।

आमतौर पर हमें मामूली संक्रामक क्षेत्रों (विंडोह पर 1.5GB तक, सोलारिस पर 3.8 3.8 के बारे में। YMMV।) तक पहुंचने में परेशानी नहीं होती है। विंडोह्स पर, समस्या ज्यादातर यह है कि कुछ पुस्तकालय हैं जो जेवीएम शुरू होने से पहले लोड हो जाते हैं जो पते की जगह को तोड़ते हैं। / 3 जीबी स्विच का उपयोग करने से उन पुस्तकालयों को वापस नहीं किया जाएगा, इसलिए वे अभी भी हमारे लिए एक समस्या हैं।

हम जानते हैं कि चनों को ढेर कैसे बनाया जाता है, लेकिन इनका उपयोग करने के लिए कुछ ओवरहेड होगा। हम 32-बिट JVM में बड़े ढेर के लिए तेजी से भंडारण प्रबंधन के लिए अधिक अनुरोध करते हैं। यदि आप वास्तव में बड़े ढेर चाहते हैं, तो 64-बिट जेवीएम पर स्विच करें। हमें अभी भी सन्निहित मेमोरी की आवश्यकता है, लेकिन 64-बिट एड्रेस स्पेस में इसे प्राप्त करना बहुत आसान है।

Comments

वो बहुत रुचिकर है। मैंने हमेशा अपने आप से पूछा कि क्यों 1500 एमबी, अब मुझे मिल गया, धन्यवाद!

— टिम ब्यूटे

एक उम्र पुराने सवाल पर अनुवर्ती के लिए खेद है, लेकिन यह सबसे अच्छा जवाब है जो मैंने अब तक देखा है। लेकिन स्टार्टअप पर JVM विफल क्यों हो जाता है अगर यह अधिकतम ढेर आकार प्राप्त नहीं कर सकता है ? क्या यह चुपचाप न्यूनतम से ऊपर सबसे अच्छे आकार के लिए व्यवस्थित नहीं होना चाहिए ?

— स्ट्रोबोस्कोप

Answer 3

Windows के लिए जावा हीप आकार सीमाएँ हैं:

• 32-बिट जावा पर अधिकतम संभव हीप आकार: 1.8 जीबी
• 32-बिट जावा पर अनुशंसित आकार की सीमा: 1.5 जीबी (या 3 जीबी विकल्प के साथ 1.8 जीबी )

यह आपको एक बड़ा जावा हीप प्राप्त करने में मदद नहीं करता है, लेकिन अब आप जानते हैं कि आप इन मूल्यों से परे नहीं जा सकते।

Answer 4

Oracle JRockit , जो एक गैर-सन्निहित हीप को संभाल सकता है, का Windows 2003 / XP पर / 3GB स्विच के साथ 2.85 GB का जावा हीप आकार हो सकता है। ऐसा लगता है कि विखंडन एक जावा ढेर कितना बड़ा हो सकता है पर काफी प्रभाव डाल सकता है।

Answer 5

JVM को सन्निहित मेमोरी की आवश्यकता होती है और इस पर निर्भर करता है कि अन्य क्या चल रहा है, इससे पहले क्या चल रहा था, और विंडोज़ ने कैसे मेमोरी को प्रबंधित किया है आप 1.4GB तक सन्निहित मेमोरी प्राप्त कर सकते हैं। मुझे लगता है कि 64 बिट विंडोज बड़े ढेर की अनुमति देगा।

Comments

मुझे लगता है कि आधुनिक ऑपरेटिंग सिस्टम, के लिए निरंतर मेमोरी का अनुकरण करता है। 80486 के बाद से x86- आर्किटेक्चर भौतिक स्मृति को पुनर्व्यवस्थित करने के लिए पेजिंग का समर्थन करता है।

— Mnementh

Mnemeth: सबसे पहले, डेटाबेस और VMs जैसे उन्नत टूल के लिए WinAPI में एक विशिष्ट API (AllocateUserPhysicalPages) है जो विंडोज के साथ अपनी मेमोरी को खुद से प्रबंधित करने से बेहतर है। दूसरा, पेजिंग एक 80386 संरक्षित मोड सुविधा है, 80486 नहीं।

— तमस Czinege

Answer 6

सन की जेवीएम को सन्निहित स्मृति की आवश्यकता है। तो उपलब्ध स्मृति की अधिकतम मात्रा स्मृति विखंडन से तय होती है। विशेष रूप से ड्राइवर के डीएलएस मेमोरी को खंडित करते हैं, जब कुछ पूर्वनिर्धारित आधार पते में लोड किया जाता है। तो आपका हार्डवेयर और उसके ड्राइवर यह निर्धारित करते हैं कि आपको कितनी मेमोरी मिल सकती है।

सन इंजीनियरों के बयान के साथ इसके लिए दो स्रोत: मंच ब्लॉग

शायद एक और JVM? क्या आपने सद्भाव की कोशिश की है ? मुझे लगता है कि उन्होंने गैर-निरंतर स्मृति की अनुमति देने की योजना बनाई।

Comments

लेकिन मैं केवल 1GB रैम (प्लस वर्चुअल मेमोरी) के साथ एक मशीन पर 1300MB आवंटित करने में सक्षम था। मेरी 2GB रैम मशीन (वर्चुअल मेमोरी के साथ भी) केवल 1200MB आवंटित कर सकती है।

— स्टीव कू

सद्भाव मर गया है ना?

— पेसियर

हां: "अपाचे हार्मनी 16 नवंबर, 2011 से अपाचे सॉफ्टवेयर फाउंडेशन में सेवानिवृत्त है।"

— 17

Answer 7

मुझे लगता है कि इस प्रतिक्रिया के संकेत के रूप में विंडोज को कैसे कॉन्फ़िगर किया गया है, इसके साथ अधिक करना है: जावा -Xmx विकल्प

कुछ और परीक्षण: मैं केवल पुराने विंडोज़ एक्सपी मशीन (प्लस वर्चुअल मेमोरी) के साथ एक पुरानी विंडोज एक्सपी मशीन पर 1300 एमबी आवंटित करने में सक्षम था। मेरी 2GB रैम मशीन पर मैं केवल 1220MB पा सकता हूं। विभिन्न अन्य कॉरपोरेट मशीनों पर (पुराने विंडोज एक्सपी के साथ) मैं 1400 एमबी प्राप्त करने में सक्षम था। 1220MB की सीमा वाली मशीन बहुत नई है (सिर्फ डेल से खरीदी गई है), इसलिए शायद इसमें नया (और अधिक फूला हुआ) विंडोज और DLL हो (यह विंडो XP प्रो संस्करण 2002 SP2 चला रहा है)।

Comments

यह आपकी वर्चुअल मेमोरी सेटिंग्स से भी प्रभावित हो सकता है।

— स्कैफ़मैन

जिन मशीनों को मैं टेस्ट करता हूं उनमें वर्चुअल मेमोरी कम से कम दो बार फिजिकल रैम की होती है।

— स्टीव कूओ

ध्यान दें कि आप वास्तव में जावा के साथ वास्तव में वर्चुअल मेमोरी का उपयोग नहीं करना चाहते हैं, क्योंकि जीसी प्रदर्शन बहुत खराब हो जाएगा मेमोरी की मात्रा इस बात पर निर्भर करती है कि कौन सी डीएल पहले से लोड हो चुकी है और स्मृति को खंडित कर दिया है।

— १०:१

Answer 8

मुझे यह त्रुटि संदेश तब मिला जब एक (सीमित मेमोरी) से पुण्योजो वीपीएस में जावा प्रोग्राम चला रहा था। मैंने कोई स्मृति तर्क निर्दिष्ट नहीं किया था, और पाया कि मुझे स्पष्ट रूप से एक छोटी राशि निर्धारित करनी थी क्योंकि डिफ़ॉल्ट बहुत अधिक होना चाहिए था। Eg -Xmx32m (जाहिर है कि आपके द्वारा चलाए जा रहे कार्यक्रम के आधार पर इसे ट्यून करने की आवश्यकता है)।

यदि किसी अन्य व्यक्ति ने बड़ी मात्रा में मेमोरी को निर्दिष्ट किए बिना उपरोक्त त्रुटि संदेश प्राप्त किया हो तो इसे यहां डाल देना।

Answer 9

यदि आप एक बड़ा ब्लॉक आवंटित करते हैं तो सूरज की JDK / JRE को एक स्मृति राशि की आवश्यकता होती है।

OS और प्रारंभिक एप्लिकेशन लोडिंग के दौरान बिट्स और टुकड़ों को आवंटित करते हैं जो उपलब्ध रैम को टुकड़े करते हैं। यदि कोई सन्निहित ब्लॉक उपलब्ध नहीं है, तो SUN JDK इसका उपयोग नहीं कर सकता है। बी से JRockit (Oracle द्वारा अधिग्रहित) टुकड़ों से मेमोरी आवंटित कर सकता है।

Answer 10

हर कोई सन्निहित स्मृति के बारे में उत्तर देता प्रतीत होता है, लेकिन अधिक दबाव वाले मुद्दे को स्वीकार करने की उपेक्षा करता है।

यहां तक ​​कि 100% सन्निहित स्मृति आवंटन के साथ, आपके पास 32-बिट विंडोज ओएस (* डिफ़ॉल्ट रूप से) पर 2 गीब ढेर आकार नहीं हो सकता है। ऐसा इसलिए है क्योंकि 32-बिट विंडोज प्रक्रियाएं अंतरिक्ष के 2 GiB से अधिक को संबोधित नहीं कर सकती हैं।

जावा प्रक्रिया में परमिट जीन (पूर्व जावा 8), स्टैक आकार प्रति थ्रेड, जेवीएम / लाइब्रेरी ओवरहेड (जो प्रत्येक बिल्ड के साथ बहुत अधिक बढ़ता है) सभी ढेर के अतिरिक्त होंगे ।

इसके अलावा, JVM झंडे और उनके डिफ़ॉल्ट मान संस्करणों के बीच बदलते हैं। बस निम्नलिखित चलाएं और आपको कुछ विचार मिलेगा:

 java -XX:+PrintFlagsFinal

ढेर सारे विकल्प ढेर के अंदर और बाहर मेमोरी डिवीजन को प्रभावित करते हैं। आपको कम से कम 2 गीब के साथ खेलने के लिए छोड़कर ...

मेरे इस उत्तर के अंशों का पुन: उपयोग करने के लिए (टॉमकैट के बारे में, लेकिन किसी भी जावा प्रक्रिया पर लागू होता है):

विंडोज़ ओएस कुल मिलाकर (डिफ़ॉल्ट रूप से) 2 गीब तक 32-बिट प्रक्रिया की मेमोरी आवंटन को सीमित करता है।

[आप केवल सक्षम होंगे] लगभग 1.5 GiB हीप स्थान आवंटित करने के लिए क्योंकि प्रक्रिया के लिए आवंटित अन्य मेमोरी (JVM / लाइब्रेरी ओवरहेड, परमिट जीन स्पेस आदि) भी है।

32-बिट विंडोज 2 जीबी प्रोसेस एड्रेस स्पेस लिमिट क्यों लगाता है, लेकिन 64-बिट विंडोज 4 जीबी लिमिट लगाता है?

अन्य आधुनिक ऑपरेटिंग सिस्टम [कफ लिनक्स] 32-बिट प्रक्रियाओं को 4 GiB पता योग्य स्थान के सभी (या अधिकांश) का उपयोग करने की अनुमति देते हैं।

कहा कि, 64-बिट विंडोज ओएस को 32-बिट प्रक्रियाओं की सीमा को 4 GiB (32-बिट पर 3 GiB) बढ़ाने के लिए कॉन्फ़िगर किया जा सकता है:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

Comments

यह उत्तर केवल यह बताता है कि वह केवल 2 जीबी क्यों आवंटित कर सकता है, यही नहीं वह एक कंप्यूटर पर 1.4 जीबी और दूसरे पर केवल 1.2 जीबी क्यों आवंटित कर सकता है। वह आपके 1.5 GB, 2 GB, या 4 GB की सीमाएँ यहाँ नहीं बताई गई है।

— वाप्गुगी

JVM झंडे पर पैराग्राफ यह समझाने का कोई तरीका है कि स्मृति संस्करणों के बीच भिन्न क्यों हो सकती है। इसके अलावा, मेरी बात पर ध्यान दें कि कैसे ढेर की स्थापना हमेशा कुल प्रक्रिया के आकार का एक बड़ा (बड़ा) अंश है - इसलिए नीचे एक सेटिंग अभी भी 2 GiB प्रक्रिया की सीमा को प्रभावित कर सकती है - एक और सन्निहित स्मृति आवंटन द्वारा विवश हो सकती है।

— माइकल

या संभवतः 1.5 जीबी की सीमा, उस पर 1.4 जीबी आवंटन वह कर रहा है। अब और अधिक समझ में आता है - उस स्पष्टीकरण के लिए धन्यवाद।

— वाप्गुगी

Answer 11

यहां बताया गया है कि पेजिंग का आकार कैसे बढ़ाया जाए

1. mycomputer पर राइट क्लिक करें ---> गुण ---> उन्नत
2. प्रदर्शन अनुभाग में सेटिंग्स पर क्लिक करें
3. उन्नत टैब पर क्लिक करें
4. वर्चुअल मेमोरी सेक्शन में, परिवर्तन पर क्लिक करें। यह उर करंट पेजिंग आकार दिखाएगा।
5. ड्राइव का चयन करें जहां एचडीडी स्थान उपलब्ध है।
6. प्रारंभिक आकार और अधिकतम आकार प्रदान करें ... उदाहरण के लिए प्रारंभिक आकार 0 एमबी और अधिकतम आकार 4000 एमबी। (जितना आपको आवश्यकता होगी)

Answer 12

** ढेर के आकार को बदलने के कई तरीके हैं, जैसे,

1. file-> setting-> build, exceution, dep तैनाती-> कंपाइलर यहां आपको ढेर का आकार मिलेगा
2. file-> setting-> build, exceution, dep तैनाती-> compiler-> andriod यहां भी आपको ढेर का आकार मिलेगा। यदि आप समान समस्या का सामना कर रहे हैं, तो आप andriod प्रोजेक्ट के लिए इसे संदर्भित कर सकते हैं।

मेरे लिए क्या काम था

1. उचित उचित JAVA_HOME पथ सेट करें जिसे आपने जावा अपडेट किया है।

2. बनाने नई प्रणाली चर कंप्यूटर> गुण> उन्नत सेटिंग > नई प्रणाली चर बना

नाम: _JAVA_OPTION मान: -Xmx750m

FYI करें: आप Intellij सहायता में डिफ़ॉल्ट VMoption पा सकते हैं- > कस्टम VM विकल्प को संपादित करें , इस फ़ाइल में आप मिनट और अधिकतम आकार के ढेर देखते हैं। **

Answer 13

सबसे पहले, जब आप 4 जीबी रैम वाले पेज-फाइल का उपयोग कर रहे हैं तो बेकार है। विंडोज 4 जीबी से अधिक का उपयोग नहीं कर सकता है (वास्तव में, मेमोरी छेद के कारण कम) इसलिए पृष्ठ फ़ाइल का उपयोग नहीं किया जाता है।

दूसरा, पता स्थान 2 में विभाजित है, कर्नेल के लिए आधा, उपयोगकर्ता मोड के लिए आधा। यदि आपको अपने अनुप्रयोगों के लिए अधिक RAM की आवश्यकता है / boot.ini में 3GB विकल्प का उपयोग करें (सुनिश्चित करें कि java.exe को "बड़े पते से अवगत" (अधिक जानकारी के लिए Google) के रूप में चिह्नित किया गया है।

तीसरा, मुझे लगता है कि आप पूरे 2 GB पता स्थान आवंटित नहीं कर सकते क्योंकि जावा कुछ मेमोरी को आंतरिक रूप से (थ्रेड्स के लिए, JIT कंपाइलर, VM आरंभीकरण, आदि) बर्बाद करता है। अधिक के लिए / 3 जीबी स्विच का उपयोग करें।

Comments

4GB या RAM के साथ किसी पेज फ़ाइल के बेकार होने का विचार गलत है। पेजफाइल के बिना, ऑपरेटिंग सिस्टम भौतिक रैम से अप्रयुक्त प्रक्रिया डेटा (अप्रयुक्त सेवाओं के लिए स्टैक स्थान आदि) को खाली नहीं कर सकता है, इस प्रकार वास्तविक कार्य के लिए उपलब्ध रैम की मात्रा कम हो जाती है। Pagefile होने से RAM मुक्त हो जाती है।

— कोई नहीं