Kode og Rapportskrivning

Dato:	28 Mar 2014
Varighed:	7 timer

Status

Mangler tavlesvamp.
Adfærdshierakiet skal skrives om, så det illustrere robottens forskellige adfærd. Evt. vha. State Diagrams?
Kodeafsnittene skal skrives/skrives om.
Implementeringerne skal have nye navne.
Ole har skrevet en simpel implementering af "Rugwarrior"-implementeringen. Den skal læses igennem.

Mål

Anskaf en tavlesvamp.
Gennemlæs Ole's kode. Evt. forbedringer på egen kode skal overvejes.

Kodegennemlæsning og tavlesvamp

Tavlen kan nu gøre ren (med tavlesvamp). Yay.

Derudover blev koden gennemlæst. Den kan findes her som Program.zip.

Ideen er have en PrivateCar (pc) og en SharedCar (sc). Sc gemmer den seneste kommando og pc sætte direkte værdier vha. controlMotor. Det er en god ide, da den giver mulighed for at genbruge adfærd fra et adfærdshieraki til et andet. 

Rapportskrivning

Rapportskrivning var ikke eksisterende. I stedet fik jeg genovervejet præcis hvad Jones & Flynn mener med deres RugWarrior; en tavle-monolog der mest omhandlede Diskret vs Kontinuerlig tid.

Denne diskussion udmundede sig i at noget af min kode skal skrives om, eller dokumenteres grundigt. Dette kommer på listen af opgaver.

Rapportskrivning

Dato:	28 Mar 2014
Varighed:	7 timer

Status

EV3-appendiks om opbygning af robotten er "færdigt".
Adfærdshierakiet skal skrives om, så det illustrere robottens forskellige adfærd. Evt. vha. State Diagrams?
Kodeafsnittene skal skrives/skrives om.
Implementeringerne skal have nye navne? Rugwarrior vs leJOS?

Mål

Find en god måde at omskrive/udvide adfærdskapitlet.
Find en god måde at skrive om kode-implementeringerne.
Skriv på adfærdskapitlet.

Skriveprocess

Meget lidt skrevet. Tiden gik med diskussion og overvejelser ift. struktur og illustration vs. kode til rapporten.
Struktur af rapport overordnet på plads:  Indledning (problemformulering) og konklusion skal på listen.
Kode bliver brugt frem for tvivlsom illustration.
Ole har forsøgt sig med at implementere Flynn og Jones arkitektur i hans kursus for i år. Tag et kig på det i starten af næste uge.
Mangler tavlesvamp...

Rapportoversigt

Dato:	27 Mar 2014
Varighed:	7 timer

Status

EV3-afsnit mangler noget om robottens opbygning.
EV3-appendiks mangler noget om skydemekanismen.

Mål

Lav appendiks færdigt / skriv om robotten i afsnittet om EV3.

Skriveprocess

Appendiks og afsnit om EV3 færdigt. Påbegyndt at danne et overblik over hvordan kodeimplementations-afsnit skal præsenteres.
Eksperimenterer med state diagrammer (som måske kan bruges til at illustrere adfærd).

Rapporten

Overordnede struktur er beskrevet herunder:

Indledende del af rapporten

1. Abstract (gør muligvis begge indledninger unødvendige)
2. Takke-afsnit
3. Indholdsfortegnelse
4. Indledning (beskrivelse af hvordan rapporten skal læses, hvis nødvendig)
5. EV3 (kort beskrivelse af den platform der programmeres)
6. Fodboldspillet (beskrivelse af hvad det er for en opgave robotten forsøger at løse: Robottens mål)
7. Robotten (kort om hvordan formål og platform er brugt til at bygge en robot)
8. Adfærdshieraki (beskrivelse af hvilke adfærd der skal bruges for at løse robottens mål)

• -> Interrupt (Beskrivelse af min implementering af leJOS robot-kontrol) + problemer
• -> IO (Beskrivelse af min implementering af Flynn and Jones robot-kontrol) + problemer

Eksperimenterende del af rapporten

1. Indledning (hvordan eksperimenterne er opbygget og hvordan denne del skal læses, hvis nødvendigt)
2. Tråde
3. Kompass-målinger af banen som 3d kort (ikke udført eksperiment)

Appendix (uordnet)

1. Lab-blog (denne blog)
2. Robot-konstruktion gennemgang
3. Sensor-test blog (tidligere blog)

Ordforklaring

Literatur (Bibtex-genereret)

Skrivelab

Dato:	26 Mar 2014
Varighed:	7 timer

Status

EV3-afsnit mangler noget om robottens opbygning.
EV3-opbygning bør laves om til appendiks.

Mål

Lav appendiks / skriv om robotten i afsnittet om EV3.

Skriveprocess

Makro til at vise 2 billeder side om side lavet for rapporten (ensartet visning af billeder er vigtig).

Appendiks skrevet videre på. Mangler sektion(er) om skydemekanismen.

Skrivelab

Dato:	25 Mar 2014
Varighed:	4 timer

Status

EV3-afsnit mangler noget om robottens opbygning.
Mangler billeder af Robotten.

Mål

Tag billeder af robotten.
Skriv afsnit om opbygning af robotten.

Billeder og skriveprocess

Fik taget billeder af robotten samt påbegyndt at skrive om robotten.

SkriveLab

Dato:	24 Mar 2014
Varighed:	8 timer

Status

Rapport mangler de første par afsnit.
Afsnit om fodbold-spillet ikke færdigt.
Aftalt hjælp til opsætning/forbedring af billeder i rapport.

Mål

Skriv afsnit om fodbold-spillet til rapporten færdigt.
Skriv afsnit om EV3.
Check indholdsfortegnelse.

Skriveprocess

Fik installeret dansk stavekontrol til TexMaker (mit skriveprogram) samt rettet en række problemer med hvordan xelatex genererer min rapport.
Derudover afsnit om Fodboldspillet og EV3 forbedret. EV3 mangler en beskrivelse af den fysiske robot og fodboldspillet virker ufuldstændigt/grimt opsat.

Rapport-oversigt

Dato:	21 Mar 2014
Varighed:	8 timer

Status

Rapport mangler de første par afsnit.

Mål

Skriv afsnit om fodbold-spillet til rapporten.

Rapporten

Overordnede struktur er beskrevet herunder:

Indledende del af rapporten

1. Abstract (gør muligvis begge indledninger unødvendige)
2. Takke-afsnit
3. Indholdsfortegnelse
4. Indledning (beskrivelse af hvordan rapporten skal læses, hvis nødvendig)
5. EV3 (kort beskrivelse af den platform der programmeres)
6. Fodboldspillet (beskrivelse af hvad det er for en opgave robotten forsøger at løse: Robottens mål)
7. Adfærdshieraki (beskrivelse af hvilke adfærd der skal bruges for at løse robottens mål)

• -> Interrupt (Beskrivelse af min implementering af leJOS robot-kontrol) + problemer
• -> IO (Beskrivelse af min implementering af Flynn and Jones robot-kontrol) + problemer

Eksperimenterende del af rapporten

1. Indledning (hvordan eksperimenterne er opbygget og hvordan denne del skal læses, hvis nødvendigt)
2. Tråde
3. 
   

Appendix (uordnet)

1. Lab-blog (denne blog)
2. Sensor-test blog (tidligere blog)

Ordforklaring

Literatur (Bibtex-genereret)

Som det kan ses herover, så burde jeg være i stand til at skrive hele den første (indledende) del af rapporten fra dags dato. Denne indsigt skal bruges til at komme godt igang med arbejdet over de næste par uger, og jeg forventer at arbejdet med disse afsnit kommer til at afdække flere problemstillinger til den eksperimenterende del af rapporten - mit arbejde kommer til at være iterativt ift. rapporten.

Rapport-skrivning

Dato:	20 Mar 2014
Varighed:	8 timer

Status

Overordnet struktur er forbedret, og skrevet på planlægnings-tavlen.
Rapport mangler de første par afsnit.
Laptop mangler opdateringer, så latex mm. kommer til at fungere igen.
Trådtest mangler at blive afprøvet på en windows-maskine.

Mål

Få opsat hjemme-maskine (windows) så den også kan fungere til test og rapport-skrivning.

Opdater Laptop.

Test tråde på windows-maskine.

Skriv afsnit om fodbold-spillet til rapporten.

Tråde på Windows 8

Efter at have kørt samme program som blev afviklet på EV3 og min laptop fik jeg præcis samme resultat på min windows-maskine: Trådenes prioriteter havde ingen målbar effekt. Desværre er testene skrevet med kun 2 (3 med main) tråde, og min stationære maskine har 4 kerner: Det kan være at dette er årsagen til at prioriteterne ikke har effekt. Programmet skal derfor skrives lidt om til at have f.eks. 10 tråde, for at kunne bemærke en signifikant forskel, hvis der er nogen.

Hvor godt tråde virker på en windows-maskine er dog ikke så vigtigt for forståelsen af netop dette speciales mål, så denne test er lagt på hylden.

Cygwin

Latex-opbygningen af min rapport kræver en række linux-disp værktøjer, så en stor del af dagen gik med at installere et meningsfyldt virtuelt miljø, så jeg kan skrive rapport på både min stationære (bedre og større skærme) og på min laptop. Overraskende tog installationen 3-4 timer pga. de mange filer og min ret dårlige harddisk.

Rapport og Oracle

Dato:	19 Mar 2014
Varighed:	8 timer

Status

Data-opsamling af adfærds tråd-opførsel er færdig. Løsning/forståelse er stadig ufuldstændig.

Mål

Undersøg prioriteter af tråde helt til bunds.

Beskriv strukturen af hvilke afsnit rapporten skal have.

Skrive en del af rapporten's indledende afsnit.

Oracle-JVM og Linux

Efter det skuffende resultat med at sætte prioriteter for tråde i java på EV3'eren, besluttede jeg mig for at lave samme test på min Ubuntu-maskine, for at se forskellen... Og forskellen lader stadig vente på sig. Herunder ses kørsler af samme program (frataget LCD-udskrift, naturligvis) som jeg benyttede til at teste prioriteter på min EV3:

Begge disse blev afviklet som .jar-filer med sudo-privileger. Jeg prøvede også uden admin-rettighederne, med præcis samme resultat. Dette undrede mig en del, så jeg søgte lidt på nettet og fandt følgende sider:

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4813310
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6512687

Her (første link) beskrives en lang række af Oracles JVM's som for standard-indstillingerne ignorerer prioriteter af tråde. Her er det udpluk jeg finder interessant i bug-rapporten:

Linux Sun JVM 1.4.1 no
Linux Sun JVM 1.3.1 no
Linux Blackdown JVM 1.4.1 beta no
Linux Bea JVM 1.4 --
Linux IBM JVM 1.4 no
Solaris Sun JVM 1.4.1 no
MacOS-X Apple JVM 1.4.1-a7 yes
Windows Sun JVM 1.4.1 yes no - behaves like simple round-robin scheduler (ignoring priorities).

På baggrund af mine test samt disse bug-reports (og "fixes"), vil jeg konkludere at prioriteter af tråde ikke kommer til at fungere på den platform og i det framework jeg arbejder med: EV3 og leJOS.

Graffremstilling af underlig opførsel for IO

Dato:	18 Mar 2014
Varighed:	7 timer

Status

Computer og tand er ordnet efter nedbrud af begge

Grafgenerator-kode er lavet, men der er ingen blog over arbejdet (pga. computer-nedbrud)

Indledende data-opsamlig er påbegyndt.

Opsamling af arbejder uden blog

Kode til at generere grafer over den data der opsamles, er lavet[1]. Koden er ikke testet grundigt, da data-opsamlings format ikke er helt fastlagt.

Mål 

Færdigør den indledende undersøgelse af hvad der sker med trådene, samt generer grafer over dataen. Dette indbefatter at have fastlagt en måde hvorpå data skal gemmes.
Opsæt ordenlig backup af støtteprojekter.

Data-opbygning

Data gemmes som tekst-strenge under afviklingen af programmet. I første omgang gemmes dataen i hukommelsen, for så når programmet er afsluttet, at blive skrevet til disken. Hver logging af data skrives i følgende format:

startTid,slutTid,adfærdNavn

Start og slut indikerer hvilket ms dette log-event blev start og sluttet. Disse tal er ift. start af log-klassen, men behandles af GrafGeneratoren således, at alle tidsangivelser bliver tilpasset således, at første registrede tid er ved 0.

Adfærdens navn er enten den adfærd der har været aktiv eller Arbitratoren.

Hver gang der skrevet til loggen, registreres navn og startTid (T1) og dette logEvent registreres som det seneste. Det logEvent, hvis der er noget, der var umiddelbart inden dette nye seneste, får sat slutTid til T1. Bliver en adfærd faktisk færdig med sin action, så registreres slutTid til dette sluttidspunkt.

Interrupt_Subsumption-Data[2]

Herunder er kun vist den graf der blev opbygget af en kørsel med leJOS-styrring (også kaldet interrupt andre steder på bloggen).

Denne video er opførslen af robotten for den data der er ovenfor i grafen. Dog passer tiden i videoen ikke helt overens med tiden i grafen!

Jeg har valgt at registre hvilket valg arbitratoren træffer hver gang den køres. Derfor er SUPPRESS, NEW og NO_CHANGE skrevet i parantes. New betyder at der ikke var nogen anden adfærd aktiv, da arbitratoren startede en adfærd. No_change betyder at den nuværrende adfærd ikke blev ændret og Suppress betyder at en kørende adfærd blev undertrykt for at starte en ny adfærd.

Jeg har forsøgt at gemme til loggen inden en adfærd begynder, samt umiddelbart inden hver gang en adfærd forsøger at vente/sove. For Arbitratoren gemmes der blot hver gang en beslutning er taget om hvilken adfærd der skal være aktiv.

IO_Subsumption-data[3]

Herunder er så hele grunden til testen: Dataen for hvordan trådene bliver færdig med at opdatere deres motor-kommandoer. Først en video der dokumenterer hvordan robotten opfører sig:

Herunder er så graferne der skal forsøge at beskrive hvad der sker:

Den første observation jeg gjorde mig, er at der opsamles over 60 gange så mange logEvents for IO som for Interrupt, 35340 vs 578. Korrigeret for forskellen i tid er det dog "kun" en faktor 14 til forskel i hvor mange gange der logges. Den næste er naturligvis at SeekBall ser underligt anderledes ud end de andre.

Jeg ser i første omgang bort fra forskellen i logEvents. Alle tests jeg har lavet med logging slået til passer fint overens med de samme test på robotten uden logging; dvs. IO performer tilfældigt og Interrupt fungerer nogenlunde som forventet, omend ikke optimalt.

SeekBall logEvents er rigtig interessant og derfor har jeg lavet et udsnit af dataen til en ny graf. Jeg har valgt at tage perioden fra 16000-18000, da programmet ser ud til at være "stabiliseret" på dette tidspunkt.

Problemet er jo helt klart at der går næsten 2 sekunder imellem to opdateringer af motor-kommandoer fra SeekBall. Dette kommer som en klar overraskelse for mig, da koden der afvikles ikke er specielt kompleks: >=, <, addition, multiplikation samt et enkelt cast (int).

Dette mysterie må være en undersøgelse i sig selv, til senere.

Anden sammenlignings-data

Jeg har også samlet noget data over hvordan IO vs Interrupt ser ud. Herunder ses lidt information, hvor jeg prøvede at danne mit et billede af hvor stort tidsspænd hvert LogEvent dækker over:

IO

Min   duration: 0 ms

Max   duration: 490 ms

Avg   duration: 1 ms

Total duration: 70296 ms

Interrupt

Min   duration: 1 ms

Max   duration: 713 ms

Avg   duration: 27 ms

Total duration: 16154 ms

Konklussion på data

Umiddelbart begynder jeg at tænke at det kunne være rart at tilføje mere CPU-power for at se om dette ville løse mine problemer med trådene (jf. den artikkel jeg arbejder frem fra). Dette er dog af åbenlyse årsager ikke muligt for min robot. En anden ide kunne være at pille ved trådenes prioritet. F.eks. får dribble en hel del cpu-tid til at gå med ikke at ændre noget ved robottens makro-opførsel. Fra tidligere blog ved jeg dog at dette ikke kan lade sig gøre...

Til fremtidig test og undersøgelse af problematikken ved IO_Subsumption må trådningen derfor være en central problemstilling, der skal løses for at kunne få adfærdskontrollen til at fungere overhovedet.

References

1. https://sites.google.com/site/digikaison/GrapgGeneratorV1.tar.gz

2. https://sites.google.com/site/digikaison/leJOS_Log_6.txt

3. https://sites.google.com/site/digikaison/IO_Log_4.txt

Trådtest

Dato:	12 Mar 2014
Varighed:	8 timer

Status

Kode til test af tråde er færdig, men ikke testet.

Mål

Test og tilpas kode så trådenes opførsel bliver tydelig.
Præsenter resultater på bloggen.

Test af prioriteterne

I denne test startes 2 tråde (T1 og T2) fra main tråden. Begge tråde venter på at få lov at køre, og får vha. en gate lov til at køre samtidig. Main-tråden yielder uafbrudt, imens hver workertråd beregner primtal imellem 1 og 2000, og skriver antallet af beregnede primtal divideret med 1000 ud i displayet. Grunden til beregningerne er at de tager tid, så jeg kan nøjes med at skrive forholdsvis små tal ud i displayet; opdateres displayet for ofte kan tallene ikke læses/sammenlignes.
For dette program er der lavet 2 test:

1. Begge tråde har samme prioritet (samme som main-tråden)
2. T1 har PRIORITY_MIN prioritet og T2 har PRIORITY_MAX prioritet.

Begge tråde er daemon-tråde til main, men testen er også forsøgt (med samme resultat), hvor dette ikke er tilfældet. Koden hvor T1 og T2 er daemons er vedhæftet nederst på siden, da den er mest overskuelig.

Første test:

Ud fra denne test vil jeg mene at trådene følges ad, som forventet for adfærd af 2 tråde der laver samme arbejde og har samme prioritet.

Anden test:

Ud fra denne test vil jeg mene at trådene følges ad, ligesom testen hvor trådene har samme prioritet. Jeg ville forvente at tråd 2 enten var den eneste der talte op eller at tråd 2 talte mærkbart hurtigere op. Første forventning er baseret på en beskrivelsen af at processer-prioritet altid forfordeles til den højest prioriterede tråd, der er klar (begge tråde er altid klar) og anden er baseret på en form for Aging af tråde. Med Aging mener jeg at en tråd med tiden får højere prioritet, hvis den ikke kommer til når den vil, for at sikre at ingen tråde udsættes for udsultning.

Desværre er ingen af mine to forventninger opfyldt. Den adfærd der ses her er, vil jeg mene, at trådenes prioritet ignoreres.

Herunder har jeg lavet grafer over kørsler af de to test:

De to grafer har faktisk hver 2 tråde repræsenteret, men de føles så tæt, at det kan være svært at få øje på forskellen...

Konklussion

Eftersom mit OS ikke understøtter logging af information på trådiveau for den version leJOS har valgt at benytte, kan jeg desværre ikke se hvilken nice-prioritet, der faktisk gives for hver tråd. Jeg vil dog på baggrund af særligt graferne vurdere at prioriter af tråde i java ikke fungerer på det system jeg har at arbejde med: Dette kommer noget bag på mig, da det er Oracle der har leveret det JRE[2] der benyttes af leJOS. Med mindre folkene bag leJOS har skjult endnu et jre som det hemmeligt afvikler i steden for dette jre, så er problemet et generelt problem for Oracles arm-arkitektur JRE.

Referencer

1. https://sites.google.com/site/digikaison/ThreadTester2.java

    https://sites.google.com/site/digikaison/PrimeCruncher.java

2. http://java.com/legomindstorms

Måledata for de 2 implementationer

Dato:	10 Mar 2014
Varighed:	6½ timer

Status

Robotten er "færdig": IO Subsumption er blive trådet.
Robotten's adfærd er kaotisk pga. trådningen.
Undersøgelserne af hvordan Java trådes på EV3 har et resultat og er muligvis færdigt.

Jeg er tilbage på projektet igen, 1 visdomstand fattigere. Forventet fuldstændig klar til arbejde.

Mål

Klargør kode til at opsamle data for hvordan robottens adfærd skifter ved de 2 implementationer.
Påbegynd opsamling af data med ovenstående kode.

Kode

Koden blev færdig og delvis testet, men efter snak med vejleder blev jeg interesseret i at udvide min test til at finde frem til hvordan java's prioriteter fungerer på EV3'eren. Resultaterne for dette må vente til næste lab.

IO Subsumption opstart

IO Subsumption og trådning af Java

Dato:	4 Mar 2014
Varighed:	8 timer

Status

Robotten er næsten færdig: IO Subsumption mangler at blive trådet.

Mål

Gør arbejdet med IO Subsumption trådet, så robotten er "færdig".

Undersøg og eksperimenter med trådning af java's Thread (igennem den installerede JVM) på maskinen.

Trådning af robotten

Robottens IO adfærd er kodet om til at benytte 1 tråd pr adfærd. desværre ser det ud til at robotten ikke kan lide dette. Der er alvorlige timing-problemer ift. skifte imellem adfærd. Dette må undersøges næste lab.
Herunder kan ses præcis hvad problemet er ift. robottens adfærd (som burde være "identisk" med leJOS-implementationen):

En umiddelbar tanke ift. at få undersøgt om det helt konkret er trådningen eller fejlagtig konvertering af adfærd, ville være at implementere alle opdateringer af motor-forspøgelser i en enkelt tråd. Jeg må vende tilbage for at vurdere hvordan jeg bedst afdækker udfordringen og giver et svar på problemet ovenfor.

Undersøgelse af trådningens effekt

For at finde ud af hvordan trådene faktisk fungerer, har jeg startet med at tage et hurtigt kig på hvilken software jeg har at arbejde med. Grunden til at dette er så relevant er, at jeg ikke inden undersøgelsen var sikker på hvordan maskinens JVM faktisk håndterede tråde, og dokumentationen fra oracle gør der tydeligt at dette kun gælder for deres Hotspot. EV3 bruger en anden JVM (ejre-7u40-fcs-b43-linux-arm-sflt-headless-27_aug_2013), som jeg hidtil har antaget virker på nogenlunde samme måde som Hotspot, ift. afvikling af java-kode. Nu er det på tide at finde ud af om denne JVM blot er en headless Hotspot.

Ligeledes faldt jeg over en diskussion[1] på stackoverflow om hvordan tråde er mapped fra Java til OS. Jeg vil herunder afdække, empirisk, hvorvidt min EV3 bruger Native eller Green Threads.

System info

Kernel: 2.6.33-rc4 (released on February 24th, 2010 [2])
Busybox: v1.13.2 (2010-12-21 19:28:47 CST) multi-call binary 

Betydning for undersøgelsen

Busybox er en fin ide til at begrænse forbruget af ressourcer på et system. Desværre for mig, understøtter den forholdsvis gamle version ingen af de gængse måder at overvåge cpu-forbrug (top / ps, med argumenter). Eller rettere, de programmer er kun understøttet i så begrænset omfang, at jeg ikke kan se tråde.

Selve undersøgelsen

Da de "lette" kommandoer ikke er til rådighed, blev jeg nødsat til at tilgå informationen direkte. Derfor vil der herunder være lettere kryptiske udskrifter, som jeg forklarer og gennemgår til sidst. Kommentare er skrevet i [], hvis jeg har ændret på udskrift eller for at forklare hvad jeg laver med mit java-program. 

root@EV3:~# top

Mem: 59084K used, 1820K free, 0K shrd, 1612K buff, 30324K cached

CPU:  89% usr   8% sys   0% nic   0% idle   0% io   0% irq   1% sirq

Load average: 1.23 0.75 1.01 2/87 1503

  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND

 1487  1356   root          S      171m   288%    88%   /home/root/lejos/ejre1.7.0_51/bin/[...]

[fjernet resten, dette er mit program/min process]

root@EV3:~# cat /proc/sys/kernel/threads-max 

949

[java-programmet kører med 1 aktiv tråd og 0 ekstra tråde]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  176648 kB

VmSize:  175764 kB

VmLck:       0 kB

VmHWM:   14264 kB

VmRSS:   14264 kB

VmData:  153384 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      50 kB

Threads: 10

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

[java-programmet kører med 1 aktiv tråd og 5 ekstra tråde]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  177384 kB

VmSize:  177364 kB

VmLck:       0 kB

VmHWM:   14428 kB

VmRSS:   14428 kB

VmData:  154984 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      52 kB

Threads: 15

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

[java-programmet kører med 1 aktiv tråd og 10 ekstra tråde]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  179116 kB

VmSize:  179096 kB

VmLck:       0 kB

VmHWM:   14520 kB

VmRSS:   14520 kB

VmData:  156716 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      52 kB

Threads: 20

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

[java-programmet kører med 1 aktiv tråd og 15 ekstra tråde]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  180716 kB

VmSize:  180696 kB

VmLck:       0 kB

VmHWM:   14616 kB

VmRSS:   14616 kB

VmData:  158316 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      54 kB

Threads: 25

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

[java-programmet kører med 1 aktiv tråd og 25 ekstra tråde]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  183916 kB

VmSize:  183896 kB

VmLck:       0 kB

VmHWM:   14800 kB

VmRSS:   14800 kB

VmData:  161516 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      58 kB

Threads: 35

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

[java-programmet kører med 1 aktiv tråd og 0 ekstra tråde, ventede 1 min for at være sikker på garbage collection ol.]

root@EV3:~# cat /proc/1487/status

Name: java

State: S (sleeping)

Tgid: 1487

Pid: 1487

PPid: 1356

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 1024

Groups:

VmPeak:  183916 kB

VmSize:  183896 kB

VmLck:       0 kB

VmHWM:   14824 kB

VmRSS:   14824 kB

VmData:  161516 kB

VmStk:      84 kB

VmExe:       4 kB

VmLib:   12760 kB

VmPTE:      58 kB

Threads: 10

SigQ: 0/474

SigPnd: 0000000000000000

ShdPnd: 0000000000000000

SigBlk: 0000000000000004

SigIgn: 0000000000000000

SigCgt: 2000000181005ccf

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: ffffffffffffffff

CapBnd: ffffffffffffffff

Cpus_allowed: 1

Cpus_allowed_list: 0

voluntary_ctxt_switches: 2

nonvoluntary_ctxt_switches: 145

Jeg har markeret den signifikante information med fed skrift. For hver ekstra java-thread jeg startede, blev der forbrugt endnu 1 native thread. Ved hver nedlagte java-thread blev der (med passende ventetid) nedlagt 1 native thread. Dette tager jeg som bevis for at Java til OS mapping af tråde er 1:1 (altså ligesom for Hotspot).

Ligeledes er det interessant at bemærke, at systemet maksimalt kan håndtere 949 tråde for alle processer. Denne øvre grænse er noget højere end jeg antog inden undersøgelsen begyndt.

Eftersom hver java-tråd er mapped til en native tråd, betyder det også at det er OS der står for schedueling af trådene. Denne schedueling KAN være anderledes end Round-Robin, som blev brugt at java's Green Threads i version 1.1, men ved den kernel jeg har på min EV3 benyttes Round-Robin dog også - havde min kernel været nutidig, ville den have brugt Completely Fair Schedueling (CFS) i stedet. Dette er en relevant ting at huske, særligt hvis leJOS beslutter sig for at opdatere deres system på et tidspunkt (hvilket man kunne håbe på, ud fra de datoer jeg har skrevet ovenfor... =).

Besynderligt nok så står programmet til at have status S (sleeping), på trods af at det kører og beregner primtal. Jeg har intet bud på hvorfor denne state ikke er sat til R (ready/running).
Her er lidt mere om de pthreads der er talt ovenfor:
http://man7.org/linux/man-pages/man7/pthreads.7.html

Refs

1. http://programmers.stackexchange.com/questions/120384/why-not-green-threads

2. http://kernelnewbies.org/Linux_2_6_33