Begeleiders:
Context: opkomst van multi en many-core architectuur. Kenmerkend voor deze architecturen is dat CPU cores verbonden zijn via een veel 'dynamischer' netwerk dan in klassieke architecturen. Hierdoor is de kwaliteit van de verbindingen tussen de CPU cores variabel tijdens uitvoeringstijd (“at runtime”) zelf. De vraag is hoe we zulke architectuur optimaal kunnen programmeren? We gaan in dit voorstel uit van een relatief hoog-niveau 'scripting'taal dewelke de programmeur expliciet ondersteunt bij het programmeren van zulke architecturen.
AmbientTalk is een gedistribueerde hoog-niveau actor-taal ontwikkeld op het PROG labo. Deze taal werd origineel ontwikkeld voor het programmeren van mobiele netwerken (dit zijn netwerken van mobiele computers zoals bvb. PDAs of telefoons die draadloos met mekaar communiceren). Hoe kunnen/moeten we de taal aanpassen om te schalen naar netwerken van CPU cores eerder dan netwerken van (relatief heavyweight) volwaardige computers? Een belangrijk aspect is dat in een actor-taal actoren asynchroon met mekaar communiceren. Dit heeft bepaalde voordelen: netwerk latency (bvb. veroorzaakt door weggevallen verbindingen, of door netwerk-opstoppingen) kan makkelijker verborgen worden (en heeft minder rechstreekse impact op de applicatie. Een actor kan bvb. nooit 'geblokeerd raken'.), messages kunnen in batch verstuurd worden, etc.
Binnen deze context zijn er verscheidene mogelijke onderzoeksrichtingen die gekozen kunnen worden:
- In de huidige AmbientTalk virtuele machine wordt elke actor gemapt op 1 (Java Virtuele Machine) thread. De huidige implementatie biedt echter geen support voor het uitbuiten van multi of many-core architecturen. Een interessante onderzoeksvraag kan dus zijn hoe de AmbientTalk virtuele machine actoren kan alloceren over verschillende nodes. Hierbij kunnen misschien allerlei thread-pooling technieken worden toegepast om het aantal echte threads zo laag mogelijk te houden. Threads zijn “heavyweight” processen, dus hoe meer actoren gebruik kunnen maken van dezelfde thread, hoe meer actoren er kunnen worden aangemaakt zonder onmiddelijke impact op de performantie.
- Een andere onderzoeksvraag is hoe de actor-threads kunnen gemapt worden op de verschillende cores. Allocatie kan bvb. statisch gebeuren (door expliciet actoren te linken aan verschillende cores via annotaties in de source code) maar het is waarschijnlijk interessanter om te kijken naar dynamischer scheduling algoritmen dewelke at runtime actoren kunnen her-alloceren al naargelang hun “load”. Dynamische scheduling is belangrijk omdat de verbindingen tussen de verschillende CPU cores van variabele kwaliteit zijn tijdens uitvoeringstijd zelf, dus een allocatie die statisch optimaal lijkt kan at-runtime opeens sub-optimaal worden. Een belangrijk aspect hierbij is ook het ontwikkelen van de juiste heuristieken om de performantie van het systeem te “monitoren”. Zo kan bvb. de “load” van een actor gerelateerd worden aan het gemiddeld aantal berichten in hun 'mailbox' (= de buffer waarin ze binnenkomende berichten opslaan).
- Veel applicaties vereisen soft real-time garanties (bvb. video-streaming). Hoe kan het asynchrone actor-paradigma vereenzelvigd worden met zulke soft real-time constraints? Mogelijke oplossingen zijn het introduceren van 'vluchtige asynchrone berichten' dewelke gedropt mogen worden als zij niet binnen een bepaalde deadline verwerkt kunnen worden, asynchrone berichten die gerepliceerd worden en waar alleen het eerste (snelste) antwoord wordt van weerhouden (dit kan zonder al te veel moeite als de berichten alleen functionele operaties triggeren), of zelfs door het repliceren van volledige actoren.