Nye muligheter med tråder og RISC-V: Her er nyhetene i Java 19

Det er temmelig unikt at alle nyhetene i en kommende runde Java er i prøve-tilstand – «preview» eller «incubator».

Men det er det folkene bak Java byr på denne gangen. Bortsett fra en ny maskinvare-plattform som er den åpne brikketeknologien RISC-V, med Linux på toppen. Den er klar til bruk i Java 19.

Bak interessen for den åpne spesifikasjonen, som alle kan produsere brikker ut fra, står flere forhold. Det er blant annet ytelse: Flere eksperimentelle versjoner kan gi ytelsesforbedringer per watt som slår dagens CPU-er og samtidig være i stand til å kjøre et helt vanlig Linux-operativsystem. Den absolutte ytelsen per kjerne er imidlertid lavere enn de mainstream-CPU-ene som er på markedet i dag.

Firmaer bak disse brikkene holder kortene tett til brystet, så tiden vil vise om resultatet kan gjentas i masseproduksjon. Et annet forhold er den modulære arkitekturen til RISC-V, der man så å si kan bygge opp brikker etter behov og skreddersy dem til spesifikke formål.

En annen faktor er tidens geopolitiske spenninger der en stormakt ikke lenger kan regne med å få adgang til den teknologien som rivaliserende makter kontrollerer. Og derfor kanskje må bruke eldre og utdatert teknologi.

I den sammenhengen er det interessant at to av de tre interessentene bak spesifikasjonen er kinesiske Huawei og Alibaba (mens den tredje er IBM-eide Red Hat).

Huawei har hatt store problemer på det amerikanske markedet. Firmaets produkter er svartelistet, og det gir grunn til nervøsitet når det gjelder adgang til den vestlige prosessorteknologien, som kreves for å være konkurransedyktig på mobilmarkedet.

For Alibaba handler det dessuten om å lage prosessorer som er skapt for behovene i et sky-datasenter.

Og det dreier seg først og fremst om høyest mulig ytelse til lavest mulig strømforbruk. Det er som nevnt her RISC-V har vist lovende takter i laboratoriet, og Alibaba har allerede skapt mange brikker basert på teknologien.

De tre nevnte firmaene har allerede flyttet Open source-Java til RISC-V, så i Java 19 handler det om å flytte plattformen inn i Javas verden, og det burde bare kreve enkle endringer, står det i spesifikasjonen.

Virtuelle tråder

Og så er det nye muligheter med tråder. Det ser ut til å være en gjenganger for tiden, også i andre språk. Moderne flerkjerne-maskinvare krever parallelliserte programmer, og da er det bra å ha ulike modeller til ulike typer problemer.

Javas første forsøk på trådhåndtering var Thread-objektet i versjon 1.0. I Java 5 kom executor-bibliotekene med enkle trådpuljer, skrevet av eksperten Doug Lea og kopiert i mange andre språk. I Java 8 kom CompletableFuture og tillegg, som er den konstruksjonen som ligger bak async/await i andre språk.

Og nå kommer virtuelle tråder. Hvorfor det, egentlig?

Det gjør det mulig å skrive serverprogrammer der man bruker én tråd per forespørsel eller oppgave. Den løsningen skalerer ikke så godt med ekte tråder, som de operativsystemet stiller til rådighet, så i stedet kan man bruke virtuelle tråder.

Under panseret fungerer det ved å ha en vanlig trådsamling, og så hektes oppgavene fortløpende på den neste ledige tråden. Det minimerer den overhead og oppstartstid man har når man instansierer en ny tråd.

Men hvorfor ikke bare bruke asynkron programmering med CompletableFuture og Java 8s funksjonelle streams, som vi alle har hørt at vi skal bruke?

Det er fordi denne programmeringsmodellen er upraktisk, sier utviklerne rett ut, på grensen av det kontroversielle:

– Med den asynkrone stilen kan hver del av en forespørsel utføres med en annen tråd, og hver tråd avvikler deler som tilhører ulike forespørsler, på et innbyrdes integrert vis. Det har store konsekvenser for forståelsen av programmets atferd: Stack-traces gir ingen brukbar kontekst, debuggere kan ikke gå gjennom logikken for håndtering av forespørsler, og profileringsverktøy kan ikke koble sammen ressursforbruket til det stedet i koden som kaller operasjonen. Det er mulig å sette sammen lambda-uttrykk når man bruker Javas stream-API til å behandle data i en kort pipeline, men det er problematisk når all kode til håndtering av forespørsler i et program skal skrives på denne måten.

Denne programmeringsstilen er i strid med Java-plattformen fordi applikasjonens måte å se samtidighet på – den asynkrone pipelinen – ikke er plattformens syn på samtidighet, heter det i spesifikasjonen.

En virtuell tråd er enkel å skape:

API-en ser kjent ut og bygger på executor-rammeverket:

Et mer virkelighetsnært eksempel kan se slik ut, med tanke på den sentrale delen av en serverapplikasjon:

Et serverprogram som dette skalerer godt fordi det kan bruke et høyt antall virtuelle tråder, heter det i spesifikasjonen.

Det er imidlertid en «catch» med virtuelle tråder: Man må ikke putte dem i en trådsamling – det kan gi konflikter. Det er heller ikke behov for det, siden virtuelle tråder er billige: De kan brukes og kastes.

Virtuelle tråder er i «preview», og det kommer vanligvis tre eller fire av dem før utformingen fryses fast – det vil si 18–24 måneder inn i fremtiden, hvis ideene ikke droppes før det. Men det skjer visst ikke ofte.

Structured Concurrency

I samme sjanger finner vi Structured Concurrency, som vil forenkle programmer med flere tråder ved hjelp av et bibliotek til «strukturert samtidighet», noe som bygger på virtuelle tråder.

Strukturert samtidighet kan brukes når en oppgave deles opp i flere samtidige deloppgaver, som skal utføres i sine egne tråder og der deloppgavene må være ferdige før hovedoppgaven fortsetter.

Det realiseres i klassen StructuredTaskScope, som sørger for at levetiden for en samtidig operasjon er begrenset av en syntaksblokk, akkurat som for en sekvensiell operasjon i strukturert programmering. Det lyder litt som fork-join-løsningen som finnes i Javas biblioteker allerede, men det er mer i det enn som så.

Det kan se slik ut:

Det skal fremme en programmeringsstil som kan fjerne risiko som oppstår ved annullering og stenging, slik som tråd-lekkasjer og forsinkelser ved annullering. Eksisterende alternativer, slik som ExecutorService-metodene invokeAll og invokeAny, er ikke nok til å løse mer generelle koordineringsproblemer, mener utviklerne.

Structured Concurrency er en incubator – et tillegg til klassebibliotekene som kan fjernes igjen på et senere tidspunkt. Så tiden vil vise om det blir noe av dette.

Imperativ programmering er tilbake

Forslagene om virtuelle tråder og strukturert samtidighet kan leses som om at imperativ programmering – algoritmer som bakeoppskrifter, kjent fra klassisk C, C++ og tidlig Java – er tilbake, på bekostning av den funksjonelle stilen som har vært dogmet om god programmeringsstil de siste årene, blant annet som en løsning på de store problemene ved parallellprogrammering.

De abstraksjonene som kreves, kan hindre innsikt for programmerere og begrense bruken av verktøyene, heter det i spesifikasjonene.

Med litt god vilje kan man si at programmeringsspråk i 2022 er mer hybride enn noen gang. Det er i hvert fall dommen fra vår koderedaksjon.

Mønstermatch for records

Som tidligere varslet møtes to nye tillegg, pattern matching og records, i den nye spesifikasjonen pattern matching for records. Records er Javas nye post-klasser som kapsler inn verdier og ikke så mye mer enn det. Med en ny syntaks kan man lett få tak i feltenes verdier:

Det fungerer også med records som har felter som også er records. Da kan man bruke denne enkle syntaksen, der et Rectangle instansieres med et ColoredPoint, som instansieres med Point:

Record Patterns er i første preview.

Og så litt av hvert

Resten av nyhetene i Java 19 er previews og incubators, som nå er i senere faser.

Foreign Function and Memory API er nå forfremmet fra incubator til preview, som altså betyr at det siktes mot at funksjonaliteten blir en del av klassebibliotekene. Det handler om det ikke så enkle grensesnittet til kode og hukommelse i andre språk og programmer.

Et vektor-API som bruker CPU-ers muligheter for å utføre vektor-beregninger, er nå i fjerde incubator.

Dessuten har pattern matching for switch-setningen kommet fram til tredje preview, og de er det oftest tre eller fire av, så her er vi tett på målstreken.

Versjon 19 er ikke en langtidsstøttet LTS-utgave – den æren tilkommer versjon 21, som ligger 15 måneder inn i framtiden. Tidlige builds av versjon 19 er tilgjengelige på prosjektets hjemmeside. Den ferdige utgaven blir lansert i slutten av september.

Det er som vanlig en lang rekke varianter av åpen kildekode-utgaven OpenJDK, og her er nyheten at Amazons utgave har tatt et kjempesprang – fra 2 til 22 prosent i andel på de siste to årene. I samme periode har den kommersielle utgaven fra Oracle, som eier varemerket Java, falt fra 75 til 34 prosent.

Det skyldes antagelig bruken i Amazons sky, AWS.

I tillegg til AWS finnes en rekke andre varianter. En oversikt finner du på Wikipedia.

Denne artikkelen ble først publisert på Version 2