OpenJDK on ilmainen versio Java-kehitysalustasta oliopohjaisen kielen käsitteen alla.
äskettäin julkaistiin ehdotus asynkronisten pinojälkien edistämiseksi Javassa ja että se kukoistaa OpenJDK:n Java-parannusprosessissa. Projektin tarkoituksena on määrittää AsyncGetStackTrace API keräämään pinojälkiä asynkronisesti ja sisältämään tietoa Javasta ja alkuperäisistä pinokehyksestä.
Ehdotuksen mukaan mm. suorituskyky ei vaikuta, jos API ei ole käytössä ja muistivaatimukset eivät kasvaisi merkittävästi nykyiseen AsyncGetCallTrace API:hen verrattuna. Uutta APIa ei suositella tuotantokäyttöön, koska se voi kaataa JVM:n. Suunnitelmiin kuuluu tällaisen tapauksen riskien minimoiminen laajan testauksen ja todentamisen avulla.
Useimmat generaattorit käyttävät AsyncGetCallTracea profiilit saatavilla, sekä avoimen lähdekoodin että kaupalliset, mukaan lukien async-profiler. Mutta sillä on kaksi suurta haittaa.
- tämä on sisäinen API, jota ei viedä missään otsikoissa;
- se palauttaa vain tiedot Java-kehyksistä, eli niiden menetelmästä ja tavukoodiindekseistä.
Nämä ongelmat vaikeuttavat profiloijien ja niihin liittyvien työkalujen käyttöönottoa. Vaikka HotSpot VM:stä voidaan poimia lisätietoja monimutkaisen koodin avulla, muuta hyödyllistä tietoa on piilotettu ja mahdotonta saada:
Onko käännetty Java-kehys verkossa (tällä hetkellä saatavana vain korkeammille käännetyille kehyksille).
Java-kehyksen koontitaso (eli C1:n tai C2:n kääntämä).
Tietoja C/C++-kehyksistä, jotka eivät ole pinon yläosassa.
Nämä päivämäärät voi olla hyödyllistä virtuaalikoneen profiloinnissa ja virittämisessä tietylle sovellukselle sekä profiloitaessa koodia, joka käyttää paljon JNI:tä.
API mallinnettaisiin APIAsyncGetCallTracen avulla, Uutta APIa ei myöskään ole vielä tarjottu tietylle Java-standardin versiolle. Javan seuraava julkaisu on (JDK) 20, jonka odotetaan valmistuvan maaliskuussa 2023. Javassa on muodollinen prosessi alustamuutosten sisällyttämiseksi, joka on onnistunut vastaamaan muuttuviin olosuhteisiin ja saavuttamaan korkean vakauden.
Profiloijat voivat kutsua tätä APIa saadakseen pinojäljityksen parhaillaan suoritettavalle säikeelle. Tämän API:n kutsuminen signaalinkäsittelystä on turvallista, ja uusi toteutus on vähintään yhtä vakaa kuin JFR-pinon jäljityskoodi. Virtuaalikone täyttää kehystiedot ja kehysmäärän. API-soittajan on varattava puhelutaulukko, jossa on tarpeeksi muistia pyydettyä pinon syvyyteen.
Virtuaalikone viimeistelee jäljitysrakenteen, joka sisältää kuvataulukon kuvien todellisen määrän tai virhekoodin. Virhekoodit ovat AsyncGetCallTracen virhekoodien osajoukko.
Vaikka API tarjoaa enemmän tietoa, kehystä kohden tarvittava tila (esimerkiksi 16 tavua x86:ssa) on sama kuin olemassa olevassa APIAsyncGetCallTracessa. C/C++-kehyksiä koskevien tietojen palauttaminen johtaa toteutustietojen paljastamiseen, mutta tämä pätee myös AsyncGetCallTrace Java -kehyksiin, koska ne paljastavat standardikirjastotiedostojen toteutustiedot ja sisältävät alkuperäisiä käärekehykset .
jopa kokeneella Java-kehittäjällä ei ehkä ole hyvää ymmärrystä kuinka alustaa kehitetään ja ylläpidetään. Pääasiallinen opetus on, että tämä on todella avoin prosessi.
Java-kehityksen perusta on Java Community Process (JCP). Se on eräänlainen itsetietoinen perusdokumentti, joka määrittelee, miten alustaan tehdään muutoksia ja mahdollistaa myös itse prosessin muokkaamisen. JCP:n uusin versio on 2.11, joka otettiin käyttöön vuonna 2019.
JCP virallistaa kuinka uusia ominaisuuksia ja muutoksia Javassa ehdotetaan, tarkistetaan ja hyväksytään. (eli tekniset tiedot), mukaan lukien erilaisten ihmisten roolien määrittely. Nämä roolit auttavat tarjoamaan paikan, jossa Java-käyttäjäyhteisö voi osallistua alustan hallintaan.
Uusien toimintojen ja muutosten ehdottamiseksi JCP sallii Java-määrityspyyntöjen (JSR) luomisen ("alustamisen"). Tämä tehdään standardoidulla lomakkeella. Lomakkeen käyttämiseksi sinun on rekisteröidyttävä ilmaiselle JCP-tilille.
Sieltä monia muutoksia, pieniä tai ei, tulee päivittäin käyttämiimme Java-tekniikoihin. Kun JSR saapuu, se siirtyy JSR-tarkistusprosessiin. Se on monivaiheinen prosessi, jossa JSR:ssä ehdotettuja muutoksia harkitaan vähitellen vakavammin, niitä muutetaan ja lopulta hyväksytään tai lopetetaan.
Vihdoin jos olet kiinnostunut tietämään siitä lisää, voit tarkistaa yksityiskohdat Seuraavassa linkissä.