క్వార్కస్‌లో స్థానిక సంకలనం - ఇది ఎందుకు ముఖ్యమైనది

అందరికి వందనాలు! క్వార్కస్‌పై మా సిరీస్‌లో ఇది రెండవ పోస్ట్ - ఈ రోజు మనం స్థానిక సంకలనం గురించి మాట్లాడుతాము.

క్వార్కస్‌లో స్థానిక సంకలనం - ఇది ఎందుకు ముఖ్యమైనది

క్వార్కస్ కోసం రూపొందించబడిన జావా స్టాక్ Kubernetes. ఇక్కడ ఖచ్చితంగా ఇంకా చాలా చేయాల్సి ఉండగా, మేము JVM మరియు అనేక ఫ్రేమ్‌వర్క్‌లను ఆప్టిమైజ్ చేయడంతో సహా అనేక అంశాలలో చాలా మంచి పని చేసాము. డెవలపర్‌ల నుండి పెరిగిన ఆసక్తిని ఆకర్షించిన క్వార్కస్ యొక్క లక్షణాలలో ఒకటి, C మరియు C++ మాదిరిగానే, నిర్దిష్ట ఆపరేటింగ్ సిస్టమ్ ("స్థానిక సంకలనం" అని పిలవబడే) కోసం Java కోడ్‌ని ఎక్జిక్యూటబుల్ ఫైల్‌లుగా మార్చడానికి దాని సమగ్రమైన, అతుకులు లేని విధానం. సాధారణంగా నిర్మాణం, పరీక్ష మరియు విస్తరణ యొక్క చక్రం చివరిలో సంభవిస్తుంది.

మరియు స్థానిక సంకలనం ముఖ్యమైనది అయితే, మేము దిగువ చూపుతాము, క్వార్కస్ అత్యంత సాధారణ జావా మెషీన్‌లో బాగా నడుస్తుందని గమనించాలి, OpenJDK హాట్‌స్పాట్, మేము స్టాక్ అంతటా అమలు చేసిన పనితీరు మెరుగుదలలకు ధన్యవాదాలు. అందువల్ల, స్థానిక సంకలనాన్ని అదనపు బోనస్‌గా పరిగణించాలి, దీనిని కావలసిన లేదా అవసరమైన విధంగా ఉపయోగించవచ్చు. వాస్తవానికి, స్థానిక చిత్రాల విషయానికి వస్తే క్వార్కస్ OpenJDKపై ఎక్కువగా ఆధారపడుతుంది. మరియు డెవలపర్‌లచే హృదయపూర్వకంగా ఆమోదించబడిన dev మోడ్, హాట్‌స్పాట్‌లో అమలు చేయబడిన డైనమిక్ కోడ్ అమలు యొక్క అధునాతన సామర్థ్యాల కారణంగా మార్పుల యొక్క దాదాపు తక్షణ పరీక్షను నిర్ధారిస్తుంది. అదనంగా, స్థానిక GraalVM చిత్రాలను సృష్టించేటప్పుడు, OpenJDK క్లాస్ లైబ్రరీ మరియు హాట్‌స్పాట్ సామర్థ్యాలు ఉపయోగించబడతాయి.

ప్రతిదీ ఇప్పటికే సంపూర్ణంగా ఆప్టిమైజ్ చేయబడి ఉంటే మీకు స్థానిక సంకలనం ఎందుకు అవసరం? మేము క్రింద ఈ ప్రశ్నకు సమాధానం ఇవ్వడానికి ప్రయత్నిస్తాము.

స్పష్టతతో ప్రారంభిద్దాం: ప్రాజెక్ట్ అభివృద్ధి సమయంలో JVMలు, స్టాక్‌లు మరియు ఫ్రేమ్‌వర్క్‌లను ఆప్టిమైజ్ చేయడంలో Red Hat విస్తృతమైన అనుభవాన్ని కలిగి ఉంది వాటిలో JBoss, సహా:

  • ప్లాట్‌ఫారమ్‌లోని క్లౌడ్‌లో పని చేసే మొదటి అప్లికేషన్ సర్వర్ Red Hat OpenShift.
  • కంప్యూటర్లలో అమలు చేయడానికి మొదటి అప్లికేషన్ సర్వర్ ప్లగ్ PC.
  • అమలు చేయబడిన మొదటి అప్లికేషన్ సర్వర్ రాస్ప్బెర్రీ పై.
  • పరికరాలపై అమలవుతున్న ప్రాజెక్ట్‌ల శ్రేణి ఆండ్రాయిడ్.

మేము చాలా సంవత్సరాలుగా క్లౌడ్‌లో మరియు రిసోర్స్-నిర్బంధిత పరికరాల్లో (చదవండి: IoT) జావా అప్లికేషన్‌లను అమలు చేయడంలో ఎదురయ్యే సవాళ్లతో వ్యవహరిస్తున్నాము మరియు పనితీరు మరియు మెమరీ ఆప్టిమైజేషన్ పరంగా JVM నుండి అత్యధిక ప్రయోజనాలను పొందడం నేర్చుకున్నాము. అనేక ఇతర మాదిరిగానే, మేము చాలా కాలంగా జావా అప్లికేషన్ల స్థానిక సంకలనంతో పని చేస్తున్నాము జి.సి.జె., ఏవియన్, ఎక్సెల్సియర్ JET మరియు కూడా Dalvik మరియు ఈ విధానం యొక్క లాభాలు మరియు నష్టాల గురించి మాకు బాగా తెలుసు (ఉదాహరణకు, "ఒకసారి నిర్మించండి - ఎక్కడైనా అమలు చేయండి" అనే సార్వత్రికత మరియు సంకలనం చేయబడిన అప్లికేషన్‌లు చిన్నవిగా ఉండటం మరియు వేగంగా పని చేయడం వంటివి ఎంచుకోవడంలో గందరగోళం).

ఈ లాభాలు మరియు నష్టాలను పరిగణనలోకి తీసుకోవడం ఎందుకు ముఖ్యం? ఎందుకంటే కొన్ని సందర్భాల్లో వారి నిష్పత్తి నిర్ణయాత్మకంగా మారుతుంది:

  • ఉదాహరణకు, సర్వర్‌లెస్/ఈవెంట్ ఆధారిత పరిసరాలలో సేవలు కేవలం ప్రారంభం కావాలి ఈవెంట్‌లకు ప్రతిస్పందించడానికి సమయం పొందడానికి (కఠినమైన లేదా మృదువైన) నిజ సమయంలో. దీర్ఘకాలిక నిరంతర సేవల వలె కాకుండా, ఇక్కడ కోల్డ్ స్టార్ట్ యొక్క వ్యవధి అభ్యర్థనకు ప్రతిస్పందన సమయాన్ని విమర్శనాత్మకంగా పెంచుతుంది. JVM ఇప్పటికీ ప్రారంభించడానికి గణనీయమైన సమయాన్ని తీసుకుంటుంది మరియు కొన్ని సందర్భాల్లో దీనిని స్వచ్ఛమైన హార్డ్‌వేర్ పద్ధతుల ద్వారా తగ్గించవచ్చు, ఒక సెకను మరియు 5 మిల్లీసెకన్ల మధ్య వ్యత్యాసం జీవితం మరియు మరణం మధ్య వ్యత్యాసం కావచ్చు. అవును, ఇక్కడ మీరు జావా మెషీన్‌ల హాట్ రిజర్వ్‌ను సృష్టించడం ద్వారా ఆడవచ్చు (ఉదాహరణకు, మేము దీనితో చేసాము ఓపెన్‌విస్క్‌ని నేటివ్‌కి పోర్ట్ చేస్తోంది), అయితే ఇది లోడ్ స్కేల్స్‌గా అభ్యర్థనలను ప్రాసెస్ చేయడానికి తగినంత JVMలు ఉంటాయని హామీ ఇవ్వదు. మరియు ఆర్థిక కోణం నుండి, ఇది బహుశా చాలా సరైన ఎంపిక కాదు.
  • ఇంకా, తరచుగా కనిపించే మరొక అంశం ఉంది: బహుళత్వం. JVMలు వాటి సామర్థ్యాలలో ఆపరేటింగ్ సిస్టమ్‌లకు చాలా దగ్గరగా ఉన్నప్పటికీ, అవి ఇప్పటికీ Linux - ఐసోలేటింగ్ ప్రక్రియలలో మనకు బాగా అలవాటు పడిన వాటిని చేయగల సామర్థ్యాన్ని కలిగి లేవు. అందువల్ల, ఒక థ్రెడ్ యొక్క వైఫల్యం మొత్తం జావా మెషీన్‌ను తగ్గించగలదు. చాలా మంది వ్యక్తులు వైఫల్యం యొక్క పరిణామాలను తగ్గించడానికి ప్రతి వినియోగదారు యొక్క అప్లికేషన్‌ల కోసం ప్రత్యేక JVMని కేటాయించడం ద్వారా ఈ లోపాన్ని అధిగమించడానికి ప్రయత్నిస్తారు. ఇది చాలా లాజికల్, కానీ స్కేలింగ్‌తో సరిగ్గా సరిపోదు.
  • అదనంగా, క్లౌడ్-ఆధారిత అనువర్తనాల కోసం, హోస్ట్‌లోని సేవల సాంద్రత ఒక ముఖ్యమైన సూచిక. మెథడాలజీకి మార్పు 12 అప్లికేషన్ కారకాలు, మైక్రోసర్వీసెస్ మరియు కుబెర్నెట్స్ ఒక్కో అప్లికేషన్‌కు జావా మెషీన్‌ల సంఖ్యను పెంచుతాయి. అంటే, ఒక వైపు, ఇవన్నీ స్థితిస్థాపకత మరియు విశ్వసనీయతను అందిస్తాయి, అయితే అదే సమయంలో సేవ పరంగా బేస్ మెమరీ వినియోగం కూడా పెరుగుతుంది మరియు ఈ ఖర్చులలో కొన్ని ఎల్లప్పుడూ ఖచ్చితంగా అవసరం లేదు. స్టాటిక్‌గా కంపైల్ చేయబడిన ఎక్జిక్యూటబుల్ ఫైల్‌లు తక్కువ-స్థాయి డెడ్-కోడ్ ఎలిమినేషన్ వంటి వివిధ ఆప్టిమైజేషన్ టెక్నిక్‌ల కారణంగా ఇక్కడ ప్రయోజనం పొందుతాయి, చివరి ఇమేజ్‌లో సర్వీస్ వాస్తవానికి ఉపయోగించే ఫ్రేమ్‌వర్క్‌ల (JDKతో సహా) భాగాలను మాత్రమే కలిగి ఉంటుంది. అందువల్ల, క్వార్కస్ స్థానిక సంకలనం భద్రతతో రాజీ పడకుండా హోస్ట్‌లో సేవా సందర్భాలను దట్టంగా ఉంచడానికి సహాయపడుతుంది.

వాస్తవానికి, క్వార్కస్ ప్రాజెక్ట్ పార్టిసిపెంట్ల కోణం నుండి స్థానిక సంకలనం యొక్క సమర్థనను అర్థం చేసుకోవడానికి పై వాదనలు ఇప్పటికే సరిపోతాయి. అయితే, మరొక, నాన్-టెక్నికల్, కానీ ముఖ్యమైన కారణం కూడా ఉంది: ఇటీవలి సంవత్సరాలలో, చాలా మంది ప్రోగ్రామర్లు మరియు డెవలప్‌మెంట్ కంపెనీలు కొత్త ప్రోగ్రామింగ్ భాషలకు అనుకూలంగా జావాను విడిచిపెట్టాయి, జావా దాని JVMలు, స్టాక్‌లు మరియు ఫ్రేమ్‌వర్క్‌లతో పాటుగా కూడా మారిందని నమ్ముతున్నారు. జ్ఞాపకశక్తి-ఆకలి, చాలా నెమ్మదిగా, మొదలైనవి.

అయితే ఏ సమస్య వచ్చినా అదే సాధనాన్ని ఉపయోగించడం అలవాటు ఇది ఎల్లప్పుడూ సరైనది కాదు. కొన్నిసార్లు ఒక అడుగు వెనక్కి వేసి వేరే వాటి కోసం వెతకడం మంచిది. మరియు క్వార్కస్ ప్రజలను పాజ్ చేసి ఆలోచించేలా చేస్తే, అది మొత్తం జావా పర్యావరణ వ్యవస్థకు మంచిది. Quarkus మరింత సమర్థవంతమైన అప్లికేషన్‌లను ఎలా రూపొందించాలనే వినూత్న వీక్షణను సూచిస్తుంది, సర్వర్‌లెస్ వంటి కొత్త అప్లికేషన్ ఆర్కిటెక్చర్‌లకు జావాను మరింత సందర్భోచితంగా చేస్తుంది. అదనంగా, దాని ఎక్స్‌టెన్సిబిలిటీ కారణంగా, క్వార్కస్ జావా పొడిగింపుల యొక్క మొత్తం పర్యావరణ వ్యవస్థను కలిగి ఉంటుంది, బాక్స్ వెలుపల ఉన్న అప్లికేషన్‌లలో స్థానిక సంకలనానికి మద్దతు ఇచ్చే ఫ్రేమ్‌వర్క్‌ల సంఖ్యను గణనీయంగా పెంచుతుంది.

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి