Caroline Diguisto
email: carolinediguisto@gmail.com

Amélie Le Gouge

Chloé Arthuis

Norbert Winer

Olivier Parant

Christophe Poncelet

Celine Chauleur

Jacob Hannigsberg

Guillaume Ducarme

Denis Gallot

Ame ´lie Le Gouge

Chloe ´arthuis

Rene Gabriel

Raoul Desbriere

Gael Beucher

Cyrille Faraguet

Helene Isly

Patrick Rozenberg

Bruno Giraudeau

Franck Perrotin

dinoprostone slow release system: The MAGPOP randomised controlled trial

Keywords: CI, confidence interval, FHR, fetal heart rate, OR, odd ratio, PROM, prelabour rupture of membranes

Cervical ripening in prolonged pregnancies by silicone double balloon catheter versus vaginal

Introduction

Pregnancies that reach 41 weeks are associated with increased rates of oligohydramnios, meconium-stained fluid, fetal heart rate anomalies, cesarean delivery, asphyxia, and perinatal death [START_REF] Wennerholm | Induction of labour at 41 weeks versus expectant management and induction of labour at 42 weeks (SWEdish Post-term Induction Study, SWEPIS): multicentre, open label, randomised, superiority trial[END_REF][START_REF] Bruckner | Increased neonatal mortality among normal-weight births beyond 41 weeks of gestation in California[END_REF][START_REF] Olesen | Perinatal and maternal complications related to postterm delivery: a national register-based study, 1978-1993[END_REF][START_REF] Chauhan | Amniotic fluid index vs single deepest pocket technique during modified biophysical profile: a randomized clinical trial[END_REF][START_REF] Kortekaas | Perinatal death beyond 41 weeks pregnancy: an evaluation of causes and substandard care factors as identified in perinatal audit in the Netherlands[END_REF][START_REF] Caughey | Complications of term pregnancies beyond 37 weeks of gestation[END_REF][START_REF] Cheng | Perinatal outcomes in low-risk term pregnancies: do they differ by week of gestation?[END_REF]. In many countries, induction of labour is recommended starting at 41 weeks to reduce this mortality and morbidity [START_REF] Middleton | Induction of labour for improving birth outcomes for women at or beyond term[END_REF]. When the cervix is unfavourable, cervical ripening before oxytocin administration is recommended to increase the likelihood of vaginal delivery [START_REF] Alfirevic | Intravenous oxytocin alone for cervical ripening and induction of labour[END_REF]. Ripening methods include pharmacological methods (misoprostol and dinoprostone) and mechanical options (single or double balloon catheters) [START_REF] Levine | Cervical ripening: Why we do what we do[END_REF], and the 2 strategies have proved to be equally effective to achieve vaginal deliveries. However, pharmacological ripening appears to lead to more uterine tachysystole causing fetal heart rate (FHR) anomalies and intensive care admission of neonates than mechanical ripening [START_REF] De Vaan | Mechanical methods for induction of labour[END_REF][START_REF] Thomas | Vaginal prostaglandin (PGE2 and PGF2a) for induction of labour at term[END_REF][START_REF] Du | Double-balloon catheter versus prostaglandin E2 for cervical ripening and labour induction: a systematic review and meta-analysis of randomised controlled trials[END_REF][START_REF] Alfirevic | Which method is best for the induction of labour? A systematic review, network meta-analysis and cost effectiveness analysis[END_REF]. Pharmacological methods being associated with an increased risk of FHR anomalies and suspicion of fetal asphyxia, they may not be the most suitable method when pregnancies reach 41 weeks, as there is already a higher risk of asphyxia in such cases. We hypothesised that mechanical cervical ripening, which involves less uterine hyperstimulation with FHR anomalies, might be associated with better perinatal outcomes in prolonged pregnancies. Comparison of mechanical and pharmacological methods without defining a single device or a single substance among the mechanical and pharmacological techniques available seemed unsatisfactory for reasons of both organisation and interpretation. To standardise interventions, we chose the silicone double balloon catheter for the mechanical group and the Propess system for vaginal slow release of dinoprostone for the pharmacological group.

Methods

Study design

MAGPOP is a multicentre, superiority, open-label, randomised controlled trial with 2 parallel groups, which compares mechanical ripening with a silicone double balloon catheter with pharmacological ripening with a pessary for the slow release of dinoprostone among women with prolonged pregnancies. The protocol has been published and is available online (https:// bmjopen.bmj.com/content/7/9/e016069.long) [START_REF] Diguisto | Mechanical cervicAl ripeninG for women with PrOlon-gedPregnancies (MAGPOP): protocol for a randomised controlled trial of a silicone double balloon catheter versus the Propess system for the slow release of dinoprostone for cervical ripening of prolonged pregnancies[END_REF].

Participants

Women were recruited in 15 hospital obstetric units (tertiary and nontertiary hospitals) in France all equipped with maternal and neonatal intensive care units. Women were eligible for the study if they were 18 years old or more, had a singleton pregnancy, a fetus in vertex presentation with a term between 41 weeks + 0 days and 42 weeks + 0 (estimated from an ultrasound between 11 and 14 weeks), and had agreed with their obstetric professional that their labour should be induced. The exclusion criteria for the study were a Bishop score �6, severe preeclampsia, a previous cesarean delivery or other uterine surgery, low-lying placenta, suspected genital herpes infection, known HIV seropositivity, suspected severe congenital abnormalities, pathological FHR, or prelabour rupture of membranes (PROM).

Eligible women were screened from 41 weeks' gestation during the monitoring provided by midwives, sonographers, or physicians, recommended every 2 days at this term by French guidelines [START_REF] Vayssière | Prolonged and postterm pregnancies: guidelines for clinical practice from the French College of Gynecologists and Obstetricians (CNGOF)[END_REF]. Women were informed of the aims and scopes of the study, and written informed consent was obtained from those who met all inclusion and no exclusion criteria.

Randomisation and blinding

Women were randomly assigned (1,1 ratio) to mechanical cervical ripening with a silicone double balloon catheter or pharmacological cervical ripening with a pessary for the slow release of dinoprostone. Randomisation and concealment were managed by a secured online centralised web-based system. Randomisation was stratified for centre and parity (nulliparas versus others) and generated by use of permuted blocks of variable size. The sequence was generated by someone who was not involved in patient recruitment. The nature of the intervention made it impossible to blind either the women or obstetric staff. To compensate for the absence of blinding, the primary outcome was adjudicated by an adjudication committee, blinded to the allocation group.

Interventions

Both interventions were used according to their manufacturer's recommendations. The mechanical cervical ripening device was the Cook Cervical Ripening Balloon (Cook Medical Europe, Limerick, Ireland, reference J-CRBS-184000). A speculum was inserted to obtain cervical access, and the cervix wiped with a solution compatible with the woman's allergies (povidone iodine or sodium hypochlorite). The catheter was introduced so that both balloons reached the extra-amniotic space. Clinicians were recommended to use saline to inflate both balloons. Recommendations were to inflate the upper, uterine balloon (40 ml) first, then gently pull the catheter until the upper balloon abutted the internal os and then inflate the vaginal balloon (40 ml) so that balloons were situated on either side of the cervix. Saline was then inserted in both balloons to a maximum volume of 80 ml per balloon.

For the pharmacological cervical ripening procedure, the clinician inserted the Propess system pessary for the slow release of 10 mg dinoprostone (prostaglandin PGE2 Propess, Ferring SAS, Gentilly, France) against the cervix with or without a speculum.

Follow-up

Monitoring and management were identical in both groups. After cervical ripening began, FHR was monitored by external tocography for 2 hours [START_REF] Ayres-De-Campos | FIGO consensus guidelines on intrapartum fetal monitoring: Cardiotocography[END_REF]. Fetal well-being and uterine activity were then monitored intermittently. Women were admitted to the labour ward if labour started. Epidural analgesia was placed for women who requested it, according to the usual medical indications and contraindications. If labour had not started 24 hours after cervical ripening began, the device was removed to initiate labour induction with oxytocin/amniotomy regardless of cervical status. Oxytocin perfusion did not start until at least 30 minutes after device removal. Induction of labour with oxytocin followed French national guidelines for this procedure [START_REF]De ´clenchement artificiel du travail à partir de 37 semaines d'ame ´norrhe ´e[END_REF].

Setting

Obstetrics professionals (midwives and physicians) responsible for inserting the devices were accustomed to using both options in their daily practice as participating obstetrics hospital units all used both the silicone double balloon catheter and the Propess vaginal delivery system regularly. A meeting was held in each participating unit before inclusions began to ensure homogeneity of practices for the use of the 2 devices. The 2015 FIGO classification for fetal heart rate interpretation was also reviewed with onsite physicians during this meeting to ensure homogeneous interpretation of FHR between different maternity units [START_REF] Ayres-De-Campos | FIGO consensus guidelines on intrapartum fetal monitoring: Cardiotocography[END_REF].

Outcomes

The primary outcome was the cesarean section rate for nonreassuring fetal status, with this status determined by a blinded adjudication committee. This independent committee comprised 3 physicians with a high level of expertise in FHR interpretation. When inclusions were over and all the data collected, members of the committee adjudicated the primary outcome, by independently reviewing the 2 hours of fetal heart rate preceding the cesarean section for all women with cesarean deliveries to determine if nonreassuring fetal status was the main indication for the cesarean. The 3 committee members discussed the cases for which they had discordant opinions to reach a consensus about whether or not the fetal heart rate was reassuring. Among the secondary outcomes (which were not adjudicated) were those related to delivery, including time from cervical ripening to delivery in hours and delivery rates within 12 and 24 hours after cervical ripening began, need for induction with oxytocin, total oxytocin dose before delivery, uterine hyperstimulation defined as more than 6 contractions per 10 minutes over any 30-minute period, hyperstimulation treated by tocolysis, uterine rupture, suspicious or pathological FHR, and use of analgesics and antibiotics. The obstetricians performing the cesarean deliveries reported they were indicated for nonreassuring fetal status (in their own opinion, before the adjudication committee's decision) or for other reasons, which were specified. The type of vaginal delivery (spontaneous or instrumental) and the indication for operative vaginal deliveries were reported. The cesarean delivery rate was added as a secondary outcome after the registration of the trial on clinicaltrials.gov.

Outcomes related to maternal morbidity were suspected maternal intra-or postpartum infection, postpartum haemorrhage defined as estimated blood loss >500 ml and blood transfusion. Perineal complications and admission to intensive care were added as secondary outcomes after the registration of the trial on clinicaltrials.gov.

Outcomes related to neonatal morbidity included the Apgar score (presented only at 5 minutes, the timing most relevant for prognosis), umbilical arterial pH at delivery, admission to a neonatal unit or an intensive care unit, respiratory distress with need for any respiratory support, and neonatal asphyxia. Suspected neonatal infection was added as a secondary outcome after the registration of the trial on clinicaltrials.gov.

Sample size calculation

We hypothesised that the cesarean rate for nonreassuring FHR would be 17.7% in the pharmacological group (pessary for the slow release of dinoprostone) [START_REF] Schmitz | Outpatient cervical ripening by nitric oxide donors for prolonged pregnancy: a randomized controlled trial[END_REF] and that mechanical cervical ripening (silicone double balloon catheter) would reduce the rate to 12%, which was considered to be a sufficient difference to justify recommending this method. With a power of 80% and a 2-tailed type I error of 5%, this would require to include 1,220 women (610 in each group).

Statistical analysis

A statistical analysis plan was finalised before the database was frozen. Statistical analyses were performed according to the intention-to-treat principle. Baseline characteristics were reported per group with numbers and percentages for categorical variables and with means and standard deviation and medians and interquartile ranges for continuous variables. For the primary outcome, missing data were managed by simple imputation (as multiple imputation was not possible): Women were considered to have had a cesarean for nonreassuring FHR. Rates were then compared with the chi-squared test. The between-group difference in proportions was estimated as well as its 95% confidence interval (CI) (Wald method). Results were also presented as crude and adjusted odd ratios (ORs) with their 95% CIs; the adjusted OR was estimated from a random logistic regression model to take into account the centre effect. Secondary outcomes were analysed by the χ 2 or Fisher exact test, as appropriate, for qualitative data and by the Student or Wilcoxon test for quantitative data. The difference in the proportion or median was estimated for each secondary outcome, along with its associated 95% CI. Statistical analyses were performed with SAS 9.4 and R 3.3.1 software.

Ethics and dissemination

The study protocol was approved by the competent authorities (Agence Nationale de Se ´curite du Me ´dicament et des produits de sante ´and Comite ´de Protection des Personnes de TOURS -Region Centre; 2016-R23, 29/11/2016) and registered at ClinicalTrials.gov (NCT02907060) and in the European EudraCT database (2016-A00952-49).

Results

Between January 27, 2017, and December 23, 2018, 8,850 women were assessed for eligibility in 15 maternity units (S1 Data), 1,700 met the inclusion and exclusion criteria, and 1,220 were randomised (S1 Fig) . Due to 2 revocations of consent (n = 2) and 2 issues with consent forms (n = 2), 1,216 women were analysed: 607 in the mechanical cervical ripening group (silicone double balloon catheter) and 609 in the pharmacological group (pessary for the slow release of dinoprostone). In the end, the primary outcome was missing for 2 cases in the mechanical group (which prevented us from doing multiple imputations).

Baseline characteristics are described in the S1 Table . Cervical ripening with a silicone double balloon catheter was not associated with a lower rate of cesareans for nonreassuring fetal status (as determined by the adjudication committee): 35/607 (5.8%), compared with 32/609 (5.3%) with the pessary for the slow release of dinoprostone (crude OR 1.10, 95% CI 0.67 to 1.81; the difference in proportions was 0.5%, 95% CI -2.1% to 3.1%, p = 0.70). No maternity unit effect was observed (adjusted OR for maternity unit effect 1.10, 95% CI 0.75 to 1.61). A complete-case analysis observed no significant difference between the 2 groups (5.5% in the silicone double balloon catheter group compared versus 5.3% in the pessary for the slow release of dinoprostone group, difference in proportions 0.2%, 95% CI -2.3% to 2.7%, p = 0.88). Other outcomes related to cervical ripening and delivery are reported in S2 Table .  Time from cervical ripening to delivery was shorter in the pharmacological ripening group (23 hours versus 32 hours, median difference 6.5 95% CI 5.0 to 7.9, p < 0.001), and fewer women required analgesics in the mechanical ripening group (27.5% versus 35.4%, difference in proportion -7.9%, 95% CI -13.2% to -2.7%, p = 0.003). Maternal and neonatal morbidity did not differ significantly between the groups (S3 and S4 Tables). Three neonatal deaths occurred: 1 case of an unknown bilateral diaphragmatic hernia not identified antenatally, 1 extensive necrotizing volvulus, and 1 case of severe neonatal hypoxia complicated by intestinal perforation.

Discussion

Our results did not show that mechanical cervical ripening with a silicone double balloon catheter was associated with a lower rate of cesarean delivery for nonreassuring fetal status in pregnancies that reached 41 weeks. It was associated with a lower rate of analgesic use and of delivery within 24 hours and with a greater need for oxytocin in the second phase of induction.

MAGPOP is, to our knowledge, the first multicentre randomised trial to compare mechanical and pharmacological cervical ripening in pregnancies that reach 41 weeks, and its results are consistent with those from previous meta-analysis [START_REF] Du | Double-balloon catheter versus prostaglandin E2 for cervical ripening and labour induction: a systematic review and meta-analysis of randomised controlled trials[END_REF][START_REF] Alfirevic | Which method is best for the induction of labour? A systematic review, network meta-analysis and cost effectiveness analysis[END_REF].

Our trial has several strengths. First, our inclusion of a large population from heterogeneous settings in different French regions in both university and general hospitals with public and private units that differ in size ensures strong external validity. A second strength lies in the choice of the rate of cesarean delivery for nonreassuring fetal status for the primary outcome as we wanted an outcome measure for both mother and fetus, or at least implying both maternal and fetal morbidity, without using a composite outcome. Although these outcomes are often used in obstetrics to enable significant results to be obtained with fewer patients, they are usually composed of an aggregate of endpoints of varying importance and are accordingly difficult to interpret [START_REF] Freemantle | Composite outcomes in randomized trials: greater precision but with greater uncertainty?[END_REF][START_REF] Montori | Validity of composite end points in clinical trials[END_REF]. A third strength is that the primary outcome has been adjudicated. Although cesarean delivery is an objective measure, the decision to perform a cesarean is not objective. Physicians often disagree about the need for cesarean delivery [START_REF] Althabe | Mandatory second opinion to reduce rates of unnecessary caesarean sections in Latin America: a cluster randomised controlled trial[END_REF], and physicians facing the same situation twice may make different decisions each time: Our primary outcome is thus one that is "objectively measured but potentially influenced by clinician judgment" [START_REF] Savović | Influence of reported study design characteristics on intervention effect estimates from randomized, controlled trials[END_REF]. To avoid bias due to this physician influence on outcome, especially in view of the impossibility of blinding them to the intervention, a blinded independent committee adjudicated the primary outcome. The final strength of the trial is the stratification of the randomisation by centre, which helped to limit bias due to possible differences between units in practices for oxytocin management and cesarean indications [START_REF] Coulm | Obstetric interventions for low-risk pregnant women in France: do maternity unit characteristics make a difference?[END_REF].

The main limitation of the trial is that the observed rate of cesarean section for nonreassuring fetal status in the group treated pharmaceutically was much lower than expected. As a consequence, the a priori specified 5.7 percentage point difference (i.e., from 17.7% to 12%) appears debatable a posteriori. Nevertheless, the trial is large with 1,216 women included in the analysis, and point estimates are very close (5.8% versus 5.3%) and higher in the mechanical cervical ripening than in the pharmacological group. Our a priori hypothesis was based on data from a trial conducted between 2009 and 2012 among women with prolonged pregnancies undergoing pharmaceutical cervical ripening in French maternity units, some of which took part in this trial [START_REF] Schmitz | Outpatient cervical ripening by nitric oxide donors for prolonged pregnancy: a randomized controlled trial[END_REF]. In that earlier trial, the authors observed a global cesarean rate fairly similar to ours. The rate indicated for nonreassuring fetal status here may have been lower in part because this trial was conducted 7 years later, and practices for the use of oxytocin have changed over the years in France, with nationwide surveys in 2010 and 2016 showing that physicians tend to use less oxytocin [START_REF] Blondel | National Coordination Group of the National Perinatal Surveys. Trends in perinatal health in metropolitan France from 1995 to 2016: Results from the French National Perinatal Surveys[END_REF]. More appropriate management of uterine hyperstimulation with more frequent use of tocolysis during labour over the years may also explain the changes in indications for cesareans. Otherwise, we note that the rates of cesarean deliveries for nonreassuring fetal status determined by the adjudication committee were lower than those reported by the obstetricians at the delivery. This may be explained by the level of expertise for FHR interpretation of members of the committee, combined with the anxiety that may be associated with being on call and facing the patient but also by the fact that the committee's information for making these judgements was essentially limited to the 2 hours of fetal rate recordings before the decision to perform a cesarean.

Conclusion

Mechanical ripening with a silicone double balloon catheter was not found to be superior to pharmacological cervical ripening with a pessary for the slow release of dinoprostone in reducing the rate of cesarean deliveries for nonreassuring fetal status in prolonged pregnancies. This result does not provide evidence that justify preferring 1 strategy over the other.

PLOS Medicine | https://doi.org/10.1371/journal.pmed.1003448February 11, 2021

Acknowledgments

The authors thank women who participated in the study and members of the adjudication committee Charles Garabedjan, Muriel Doret, and Philipe Deruelle.

Participating members/collaborators of the Groupe de Recherche en Obste ´trique et Gyne ´cologie (GROG) were Thomas Schmitz, Elie Azria, Catherine Deneux-tharaux Anne Ego, Franc ¸ois Goffinet, Cyril Huissoud, Gilles Kayem, Bruno Langer, Camille Le Ray, Olivier Morel, Marie-Victoire Senat, Loïc Sentilhes, Damien Subtil, and Christophe Vayssiere. Participating members of the GROG had a role in the design of the study. They have not received any compensation for their role in the study.

They also wish to thank the research team from the University Hospital of Tours, which included Celine Lengelle, Renaud Respaud, Aure ´lie Darmarillacq, Yoann Desvignes Martine Gardin, and Elie Guichard.

Funding: MAGPOP was funded by the French Ministry of Health (Programme Hospitalier de Recherche Clinique 2015, PHRCN-2015). The funder had no role in study design, data collection, data analysis, data interpretation or writing of the report.

• Mechanical cervical ripening leads to less uterine tachysystole and less fetal heart rate anomalies than pharmacological methods.

• Whether mechanical methods are associated with reduced perinatal morbidity in prolonged pregnancies in comparison with pharmacological methods needed to be investigated by a sufficiently powered randomised trial.

What did the researchers do and find?

• We conducted a trial to compare cervical ripening with a silicone double-balloon catheter (mechanical method) to cervical ripening with a vaginal dinoprostone slow-release system (pharmacological method) among women with prolonged pregnancies.

• We did not find that cervical ripening with a silicone double-balloon catheter was superior to cervical ripening with a vaginal dinoprostone slow-release system to reduce the rate of cesarean for nonreassuring fetal heart rate and overall maternal and neonatal morbidity.

What do these findings mean?

• There is no evidence to justify preferring mechanical cervical ripening over pharmacological cervical ripening in pregnancies that have reached 41 weeks.

Supporting information


Gwendal Jouneaux
email: gwendal.jouneaux@irisa.fr

Olivier Barais
email: olivier.barais@irisa.fr

Benoit Combemale
email: benoit.combemale@irisa.fr

Gunter Mussbacher
email: gunter.mussbacher@mcgill.ca

SEALS: A framework for building Self-Adaptive Virtual Machines

Over recent years, self-adaptation has become a major concern for software systems that evolve in changing environments. While expert developers may choose a manual implementation when self-adaptation is the primary concern, selfadaptation should be abstracted for non-expert developers or when it is a secondary concern. We present SEALS, a framework for building self-adaptive virtual machines for domainspecific languages. This framework provides first-class entities for the language engineer to promote domain-specific feedback loops in the definition of the DSL operational semantics. In particular, the framework supports the definition of (i) the abstract syntax and the semantics of the language as well as the correctness envelope defining the acceptable semantics for a domain concept, (ii) the feedback loop and associated trade-off reasoning, and (iii) the adaptations and the predictive model of their impact on the trade-off. We use this framework to build three languages with self-adaptive virtual machines and discuss the relevance of the abstractions, effectiveness of correctness envelopes, and compare their code size and performance results to their manually implemented counterparts. We show that the framework provides suitable abstractions for the implementation of self-adaptive operational semantics while introducing little performance overhead compared to a manual implementation.

Introduction

Software systems increasingly need dynamic self-adaptation to best deliver their expected services [START_REF] Betty | Software Engineering for Self-Adaptive Systems: A Research Roadmap[END_REF], because these systems are evolving in complex environments on which they possibly are highly dependent. Self-adaptation requires a feedback loop to react to changes and trade-off analysis to determine the best course of action in the current context [START_REF] Kephart | The vision of autonomic computing[END_REF].

Expert developers may choose a manual implementation of the self-adaptation functionality, when self-adaptation is the primary system concern (e.g., systems like autonomous cars (e.g., Waymo1 ) and large-scale video streaming platforms (e.g., Netflix2 )). However, there are many systems where self-adaptation is a secondary but nevertheless important concern for language users 3 to provide more tailored services to end users. In those cases, language users may not have the expertise or may not need (want) to explicitly deal with this complex concern. Hence, there is a need to abstract the self-adaption concern into high level language constructs for system development in the same way as software languages abstracted concerns like concurrency and parallelism [START_REF] Goetz | Java Concurrency in Practice[END_REF][START_REF] Williams | C++ Concurrency in Action[END_REF]. Language users of such systems can then exploit the enhanced support for this emerging concern, i.e., the implementation of feedback loops and trade-off reasoning. For example, in the context of green IT [START_REF] Manotas | An Empirical Study of Practitioners' Perspectives on Green Software Engineering[END_REF], many systems like e-commerce applications can benefit from tradeoffs related to sustainability and balance their provided services accordingly. More generally, there is a growing trend to provide systems capable of reasoning about trade-offs (e.g., energy, time, cost, quality) to a large audience [START_REF] Kienzle | Toward Model-Driven Sustainability Evaluation[END_REF][START_REF] Mussbacher | The Relevance of Model-Driven Engineering Thirty Years from Now[END_REF].

We argue that language engineers will be expected to provide functionality for self-adaptation in their domainspecific languages. Therefore, language engineers can benefit from a framework at the language level, i.e., a more formal approach to the specification of feedback loops and trade-off analyses to adapt a software language and better support the implementation of complex self-adaptable software systems. Over the last decades, the software engineering community proposed an important body of knowledge about the design and implementation of self-adaptable systems [START_REF] Betty | Software Engineering for Self-Adaptive Systems: A Research Roadmap[END_REF]. This body of knowledge is now mature enough to understand well the main concepts and associated architectures for feedback loops and trade-off analyses. Architectural patterns such as the MAPE-K loop have been proposed to structure their implementation [START_REF] Kephart | The vision of autonomic computing[END_REF]. Trade-off analysis is supported with dedicated modeling infrastructure (e.g., models@runtime [START_REF] Bencomo | Models@run.time: foundations, applications, and roadmaps[END_REF], goal modeling [40,[START_REF] Van Lamsweerde | Requirements Engineering: From System Goals to UML Models to Software Specifications[END_REF][START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF]).

This paper presents the SElf-Adaptive LanguageS Framework (SEALS), where the main objective is to abstract from the feedback loop of the self-adaptive system as much as possible, so as to free the language users from the detailed specification or implementation of the feedback loop. While not being model-driven approach per se, we choose to use appropriate models to describe parts of the framework (e.g. goal models for trade-off analysis). SEALS supports the definition of (i) the abstract syntax and the semantics of the language as well as the correctness envelope defining the acceptable semantics for a domain concept, (ii) the feedback loop and associated trade-off reasoning, and (iii) the adaptations and the predictive model of their impact on the trade-off. We use SEALS to build three languages with self-adaptive virtual machines: MiniJava (a representative of imperative general purpose languages), RobLANG (a representative of imperative domain-specific languages), and HTML (a representative of declarative domain-specific languages). We further discuss the relevance of the introduced abstractions, the effectiveness of the correctness envelopes, and compare their code size and performance results to their manually implemented counterparts. We conclude that the framework provides suitable abstractions for the implementation of self-adaptive operational semantics while introducing little performance overhead compared to a manual implementation.

In the remainder of the paper, we introduce the concept of Self-Adaptable Virtual Machines (SAVMs) and provide a motivating example in Section 2. We then present SEALS, our proposed framework, by giving an overview in Section 3 and detailing the implementation in Section 4. We report on the experiments we performed and the resulting evaluation of our framework in Section 5, respectively. Finally, we discuss related work in Section 6 and conclude the paper in Section 7.

Background and motivating example

In this section, we introduce the concept of Self-Adaptable Virtual Machines. SAVMs are a sub-set of Self-Adaptable Languages (SAL) [START_REF] Jouneaux | Towards Self-Adaptable Languages[END_REF] that incorporate a feedback loop in language operational semantics. Hence, we first provide background information on the implementation of language operational semantics and self-adaptive system design. Second, we present the self-adaptable HTML language which will be used as an example in the remainder of the paper.

Language operational semantics implementation

From a language user's point of view, a software language (for specification, modeling, or programming) is a specific syntax and a set of associated services (editor, checkers, simulator, compiler...). However, from a language engineer's point of view, all these services are usually obtained from abstract specifications of the language concerns that include the abstract syntax to define the language constructs, the concrete syntax to attach a textual or graphical representation to these constructs, and the semantics to provide precise meaning to these constructs. Since semantics, and more precisely operational semantics, are at the core of our approach, we review their implementation in this section.

Operational semantics are often defined as an interpreter that performs the computation by traversing the Abstract Syntax Tree (AST) and reports the result from the leaves of the tree to the root. Multiple patterns were proposed by the community and differ from one to another for reasons like performance, modularity, or reusability. Classical patterns such as Interpreter and Visitor patterns [START_REF] Gamma | Design patterns: elements of reusable object-oriented software[END_REF] provide a straight-forward way to implement the interpreter. The former facilitates the extension of the abstract syntax and the latter the extension of the operational semantics. The Eclipse Modeling Framework (EMF) also provides an implementation pattern, EMF's Switch, based on the Visitor pattern but uses Run-Time Type Information (RTTI) to select the method to call rather than the accept method . However, while patterns like Visitor or EMF's Switch ease the extension of the semantics, they hamper the extension of the abstract syntax (and vice versa for the Interpreter pattern). This problem called The language extension problem [START_REF] Leduc | The Software Language Extension Problem[END_REF] led to the emergence of more modular ways to define semantics through new patterns (e.g., Object Algebras [START_REF] Bruno | Extensibility for the Masses[END_REF], Revisitor [START_REF] Leduc | Revisiting visitors for modular extension of executable DSMLs[END_REF]) or dedicated meta-languages (e.g., MSOS [START_REF] Peter | Modular structural operational semantics[END_REF], Kermeta [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF]).

Our proposed framework relies on parts of those design patterns and meta-languages to (1) have a base pattern in which we introduce the adaptation concern and (2) provide abstractions to the language engineer aligned with the existing interpreter implementation patterns.

Design of Self-Adaptive Systems

Self-Adaptive Systems are systems capable of adapting their behavior in response to changes in the environment or in the system itself, hence, can be classified as intelligent agents [START_REF] Russell | Artificial intelligence: a modern approach[END_REF]. Intelligent agents perceive their environment through sensors, decide their actions with respect to the current environment, and act upon the environment through effectors. This succession of steps define a classic feedback loop scheme of Collect, Analyze, Decide, and Act [START_REF] Dobson | A survey of autonomic communications[END_REF].

The definition of a feedback loop has been investigated in the context of Self-Adaptive Systems [START_REF] Betty | Software Engineering for Self-Adaptive Systems: A Research Roadmap[END_REF], with a field mature enough to provide time-honored patterns such as the MAPE-K loop [START_REF] Kephart | The vision of autonomic computing[END_REF]. The MAPE-K loop provides a pattern to implement a feedback loop in terms of four main functions (Monitoring, Analysis, Planning, and Excecution) and a common Knowledge. All the functions can be supported by models, with each model playing one or more roles with respect to the model's purpose. It is descriptive, if its purpose is the documentation of current or past system aspects, thus facilitating understanding and enabling analysis. It is predictive, if its purpose is the prediction of information that one cannot or does not want to measure, hence creating new knowledge and allowing for decision-making and trade-off analyses. It is prescriptive, if its purpose is the description of the system to be built, hence driving the constructive process including runtime evolution in the case of self-adaptive systems. These roles apply to models of all types (e.g., engineering models, scientific models, and machine learning models), and has been exemplified in the context of the MAPE-K loop [START_REF] Combemale | A Hitchhiker's Guide to Model-Driven Engineering for Data-Centric Systems[END_REF].

In our approach, we use the MAPE-K Loop pattern to abstract the feedback loop implementation from the language engineer. This abstraction allows a good separation of concern between the steps performed and their interactions, and between the four main functions themselves.

Self-Adaptable HTML

Nowadays more than ever, information and communications technology (ICT) electricity consumption grows higher and higher. The electricity demand of the ICT is expected to represent 21% of the world electricity demand in 2030, ranging from 8% in the best case to 51% in the worst case [START_REF] Anders | On global electricity usage of communication technology: trends to 2030[END_REF]. Comparatively, the web electricity demand was representing around 2% of 2015 world electricity demand [START_REF] Kamiya | Data Centres and Data Transmission Networks[END_REF]. For this reason, we choose to build an HTML interpreter as a self-adaptable virtual machine that performs a trade-off between energy consumed to display the web page and the quality of the page rendering. The energy consumption to display a web page (display and data transfer) is difficult to assess due to the networking part. However, WebsiteCarbonCalculator [START_REF]Website Carbon[END_REF] provides an algorithm that estimates this consumption, and this consumption is proportional to the size of the transferred data. Hence, the effective trade-off performed is between rendering quality and the size of data transferred. The expected trade-off is specified by the end-user due to the subjective character of the rendering quality.

Consider three adaptations for the self-adaptable HTML that serve as examples, two with loss of information and one without. The first is the conditional loading of resources depending on their URL. The idea for this adaptation is to keep the content from the website and remove external resources that are less prone to deliver important content. The second is HTML lists perforation according to their size. In HTML, lists tends to represent sets of items that are semantically similar. Often, those lists are generated from data that share the same nature, but are independent and self-sufficient, e.g., blog posts or emails. The goal is to reduce the number of these elements and subsequent data requests like images. The last one is the degradation of an image to reduce its size. The idea is to request a degraded version of an image if its size exceeds a certain threshold.

Approach overview

This section presents a general overview of our approach and describes the conceptual model of the framework. The HTML language introduced in Section 2 will be used in the remainder of this section to illustrate the use of the framework. Figure 1 presents the general overview of our approach on this example. In this figure, the three colors represent the three types of elements used to define a self-adaptable virtual machine with SEALS. The color blue is used to represent elements defined in the framework, the purple elements represent specializations of generic components provided by the framework, and red elements represent domain concepts defined using the framework constructs.

This section is structured around the self-adaptable virtual machine implementation workflow. First, we present the modeling of the domain concepts (Section 3.1). Then, the specialization of the adaptation process (Section 3.2). Finally, we discuss the coordination of all these components by the framework (Section 3.3).

In our approach, adaptations are developed as modules and are not attached to a fixed position in the presented workflow. To better understand their integration and considering that adaptations are domain-specific, we choose to present them with the modeling of the domain concepts in Section 3.1.

Modeling of domain concepts

The definition of a software language includes the definition of domain concepts in the form of an abstract syntax and semantics. To illustrate this aspect of the approach, we take the HTML domain concept of BlockTag (i.e., a tag that contains child elements) as an example. In SEALS, a domain concept can be either a normal concept or an adaptable concept.

For each concept of the language, the language engineer starts by defining the abstract syntax using the Node and AdaptableNode constructs. The BlockTag concept abstract syntax is defined as an AdaptableNode named HTMLNode-BlockTag. In addition, an adaptable concept also needs to define its correctness envelope, i.e., the set of acceptable variations in its semantics, using the SemanticsAdaptationInterface abstraction. Since BlockTag is an adaptable concept, the BlockTagInterface needs to be defined. Finally, the language engineer implements the operational semantics using the Operation and AdaptableOperation constructs. An Adapt-ableOperation has access to a SemanticsAdaptationInterface, i.e., a valid configuration conforming to the correctness envelope and resulting from an adaptation and uses it to define the adaptable semantics of the concept. In our example, HTM-LOperationBlockTag use the configuration specified by Block-TagInterface to define an adaptable operational semantics for the BlockTag concept. Those operations will be used by the framework to generate a concrete Self-Adaptable Visitor for the language, like the HTML Self-Adaptable Visitor.

In our approach, we consider adaptations to be domainspecific, as they apply to the semantics of domain-specific concepts. To help with the definition of those adaptations, we provide a construct (AdaptationModule) to define adaptations as modules by specifying the adaptation and in which case one should call this adaptation. The Conditional Loading Module is an example of such a module that defines the condition to skip the loading of some elements, and this module is applied, among others, on the script elements represented as HTMLNodeBlockTag.

Specializing the adaptation process

At the core of self-adaptable virtual machines, there is a feedback loop that performs trade-off analysis based on a monitored environment. To support the language engineer in the conception of this adaptation process, we provide two constructs that need to be specialized. They represent the Feedback Loop and its Adaptation Context.

First, the language engineer needs to specialize the Adaptation Context by defining the monitored environment, the properties of interests, and the expected trade-off. The HTML Adaptation Context is the specialization for the HTML language. It specifies the "quality" and "energy" properties of interest, a void monitored environment, and delegates the expected trade-off to the end-user. In addition, the HTML Adaptation Context benefits from the capabilities of the generic Adaptation Context to register and manage the adaptation modules. These capabilities take the form of a Module Registry. Then, the language engineer specializes the Feedback Loop to implement how to perform the trade-off analysis for the language. For instance, the HTML Feedback Loop represents this implementation for the HTML language.

Coordination of all components

In order to coordinate and initialize the SAVM , the language engineer has to specialize the Self-Adaptable Language concept. This specialization needs to define how to instantiate the concrete Feedback Loop, Adaptation Context, and Self-Adaptable Visitor. Hence, the HTML Self-Adaptable Language defines how to create the HTML Feedback Loop, HTML Adaptation Context, and HTML Self-Adaptable Visitor. The interactions of all the components presented in this section occur during the execution of a Node. Figure 2 presents the interactions of components during the execution of a node semantics in the form of two sequence diagrams, one for AdaptableNodes and the other for Nodes. Since our operational semantics implementation pattern is based on the Visitor pattern, the execution is launched by the call to an accept function. This accept function implementation is abstracted from the language engineer and implemented at the AdaptableNode and Node level. First, the accept function will trigger the feedback loop to perform, if needed, the monitoring and trade-off analysis. Then, if the node is an AdaptableNode, the function will call the activated adaptation modules that offer adaptations for this type of node to obtain an adapted configuration for the node semantics conforming to its correctness envelope. Finally, the accept function calls the semantics for this node in the visitor generated from the specified Operation and AdaptableOperation. In the case of an AdaptableNode, the function will also provide the configuration proposed by the modules to the visitor and the underlying AdaptableOperation.

Implementation

In this section, we detail the current Java implementation of the SEALS framework. Figure 3 presents the class diagram of the whole framework. Colored boxes represent Java packages with particular functions. Purple (decision.model) encompasses the elements related to the decision model including, in yellow (visitor), the processing of the model. Blue (lang) represents the definition of the language with, in red (domain), the definition of the domain abstract syntax and semantics and, in green (adaptation), the language components related to the adaptation (e.g., feedback loop, adaptation modules). In this section, the use of emphasis denotes a references to a concept defined in Figure 3. The remainder of this section presents these elements and their interactions. As for Section 3, this section is structured around the workflow for the implementation of a self-adaptable virtual machine. First, we present the implementation of the domain concepts, using abstractions defined in the red lang.domain package of Figure 3 (Section 4.1). Second, we detail the specialization of the Feedback Loop and its Adaptation Context presented in Figure 3 as part of the green lang.adaptation package (Section 4.2). Then, we detail the implementation of adaptation modules, the second green module.adaptation package in Figure 3 (Section 4.3). Finally, we discuss the connection of all these components using the Self-Adaptable Language concept, presented in the blue lang package of Figure 3, and how to use a Self-Adaptable Language to create an executable for the language (Section 4.4).

Implementation of domain concepts

This section presents the concrete methodology to implement the domain concepts in SEALS, i.e., implementing the abstract syntax, the correctness envelope, and the operational semantics as presented in Section 3.1. The abstractions used to define those concepts are regrouped in the domain package represented in red in Figure 3.

Abstract Syntax. The definition of the abstract syntax is done by defining classes that represent the concepts of the language. These classes will later be instantiated in the form of an Abstract Syntax Tree (AST) to represent a program to compute. SEALS proposes two Java interfaces to define the classes that represent a node of the AST: Node and AdaptableNode. The former does not provide anything to the language engineer but is needed by the framework to understand that the specialization represents an AST node. On the other hand, the latter asks the language engineer to parameterize the node (using Java generics) by the Java type representing its correctness envelope. In addition, Adapt-ableNode also needs the language engineer to implement the defaultInterface function that returns an instance of the correctness envelope representing its values for the normal execution of the current instance of the node. This default interface represents the configuration that can be changed by adaptation modules and will be provided to the visitor, as mentioned in Section 3.1.

Correctness Envelope. The correctness envelope defined for an AdaptableNode takes the form of a Java class implementing the SemanticsAdaptationInterface. This class represents the variation points for the semantics of the node and provides the capabilities to manipulate them. For instance, Listing 1 presents a possible correctness envelope for a ForNode. The variation point presented is the progression of the loop represented by the variable increment. The changeIncrement function allows adaptations to manipulate the increment while a guard for the proposed value ensures a coherent value (e.g., do not change the sign of the increment to avoid going the wrong way). To manipulate this envelope, the adaptations need an instance of this type for the current node. The goal of the defaultInterface function is to provide this instance, with the particularity that the variation points are set to reflect the normal semantics of the current node. For instance, in Listing 2 the value of increment represents the value specified in the code (e.g., one if the progression is i++). The signature for normal semantics contains (1) the visitor to execute children of the current node in the Abstract Syntax Tree, (2) the current node to perform the semantics depend-ing on the node attributes, and (3) the execution context. On the other hand, the signature for adaptable semantics also includes an instance of the correctness envelope representing the configuration of the semantics for this node's current execution. The configuration provided to the AdaptableOperation is the defaultInterface after potential transformation performed by adaptation modules as presented in Figure 2a.

To link the operations to the concerned node and to a concrete visitor, we provide the Operationalize Java annotation for the Operation class. This annotation takes two arguments: the operationalized node class and the fully qualified name of the visitor to generate including this operation. This generated visitor implements the Self-AdaptableVisitor interface and provides two dispatch functions, one for nodes and one for adaptable nodes, allowing the generic call to the operations from the Node and AdaptableNode interfaces and freeing the language engineer from implementing the dispatch by hand.

Implementing adaptation and decision process

At the core of self-adaptable virtual machines, there is a feedback loop. To abstract the implementation of this concern from the language engineer, we provide an abstract feedback loop based on the MAPE-K pattern that need to be specialized. This abstraction allows the language engineer to define the feedback loop in the form of the four steps of the MAPE-K loop, Monitor, Analyse, Plan, Execute when specializing the FeedbackLoop abstract class, and the Knowledge when specializing the AdaptationContext. Those abstractions are part of the lang.adaptation package represented in green in Figure 3. This AdaptationContext specialization needs to provide information on (1) a way to read the expected tradeoff, (2) the environment monitored, and (3) the managed properties of interest. The first point allows the language engineer to specify directly a trade-off for the language in this function, or to delegate the trade-off definition to other stakeholders (e.g., language users, end users) by implementing the configuration system here. The other two points are specified using the modeling framework (purple box in Figure 3) that will be used to perform the trade-off analysis. The managed properties of interest are defined through a trade-off model, while the environment monitored is defined in the environment model.

For this modeling framework, we choose to use goal models to model the satisfaction of high-level goals depending on the contribution of other elements (e.g., adaptations, resources). These goal models are defined using GRL [40] to model the trade-off, as well as the contribution of the adaptations to the satisfaction of the underlying properties of interests. Three types of goal models are involved in the analysis: a trade-off model, an environment model, and one or more impact models. The first two are the previously mentioned parts of the adaptation context, while the last ones are defined within the modules and will be detailed in Section 4.3. When merged together those models form a global model representing the system allowing to perform the trade-off analysis on it. Our modeling framework uses goal models, however, any trade-off analysis process could replace it. The generalization of the modeling framework to use other trade-off analysis strategies is left as future work.

In addition to the AdaptationContext specialization, the FeedbackLoop specialization requires the language engineer to implement the four steps of the MAPE-K loop. Monitoring consists of observing the system and updating the environment model, Analysis and Planning consists of performing the trade-off analysis and choosing the adaptation modules to be applied, and Execution activates or deactivates the modules. Moreover, the language engineer is also in charge of implementing the isTriggered function. In Figure 2, this function is hidden in the "Trigger" arrow and informs the framework if the monitor, analyze, plan, and execute functions need to be executed. The dynamic evaluation of the iteration launching condition allows the language engineer to define conditions based on the nodes executed or to be executed, as well as time related properties. In the end, the FeedbackLoop abstraction frees the language engineer from the interactions between the steps of the MAPE-K loop as well as the explicit calls to the MAPE-K loop.

Design of adaptation modules

In addition to the language in itself and the feedback loop, a self-adaptable virtual machine is composed of adaptations. To allow different stakeholders to implement the domainspecific adaptations, we choose a modular approach for the definition of the adaptations. To do so, we provide an abstract class representing a module that performs an adaptation (in the green module.adaptation package in Figure 3). When specializing, the adaptation developer specifies the class of the targeted nodes and needs to implement: (1) the initialization of the module, (2) the exposition of a predictive model of the impact on the properties of interest, (3) an additional filter on the targeted nodes, and (4) the adaptation.

The predictive model exposed by the module is an impact model representing how the activation of this module will affect the properties of interest. This model is connected at runtime to the trade-off model and environment model, allowing the adaptation developer to specify the impact on the properties of interest in the trade-off model based on the monitored resources of the environment model.

When calling the accept function of an adaptable node, the framework will prepend the call to the visitor with the module calls as presented in Figure 2a. First, we ask for the default correctness envelope instance and for the list of modules applicable on this node. Then, for each module, if the module is active and the additional filter allows the adaptation, the module adaptation function will transform the current instance of the correctness envelope. Finally, this instance is passed to the visitor during the call to the dispatch In addition, this mechanism allows fine-grained control over the nodes targeted by the adaptation, but also over the nodes that can be adapted by a module. In the first case, the filtering function allows the module developer to check properties of the node and apply or not the adaptation (Figure 4). Listing 5. Implementation of defaultInterface filter For the second case, the language engineer can define two types of correctness envelopes. The first to represent the adaptation possibilities, and the second that overrides it to remove the capacity to change values. Listing 4 presents the two correctness envelopes for the ForNode.

In addition to the definition of the correctness envelopes, the language engineer needs to filter the targetable nodes in the defaultInterface function to return the mutable/immutable version of the correctness envelope. Listing 5 provides an example of the implementation of this function.

As mentioned before, the adaptation is performed through the transformation of an instance of a correctness envelope. There are multiple ways to define and transform a correctness envelope, but we want to highlight two possible ways that cover the majority of the possible adaptations. The first one is the semantics parameterization. The correctness envelope defines parameters for the semantics that can be changed by the adaptations (see Figure 5).

The second allows the injection of commands. In addition to the correctness envelope, the language engineer also defines a Command class with a run function to be called in the semantics. In this case, the module developer has more freedom to implement the adaptation, but the language engineer still controls the information given to the module and when to call it in the semantics. This pattern can be used to add commands before and after the semantics, in the middle, or even replace the whole semantics by re-implementing the operation in the command. Figure 6 depicts a sequence diagram for a generic use case of the command injection.

Assembly and execution

The Self-Adaptable Language abstract class has two roles in the design of a self-adaptable virtual machine: assemble all the component together and ensure a correct initialization, and provide an interface to interact with the language runtime to create a standalone executable of the virtual machine or integrate the language in another application. The first role, already explained in Section 3.3, is achieved by defining how to instantiate the concrete Feedback Loop, Adaptation Context, and Self-Adaptable Visitor in the specialization.

For the second role, Listing 6 provides an example wrapper to create a standalone executable for a language. The first step is to create a language instance, this will set up the Adaptation Context, then the Feedback Loop, and create an instance of the visitor. A Self-Adaptable Language exposes two components, the Adaptation Context to transfer the module registration to the Module Registry (l.5) and the visitor to start the execution (l.7).

Evaluation

In this section, we present the evaluation of our approach. Section 5.1 details the studied languages, their manually implemented Self-Adaptable Virtual Machines (SAVMs), and SEALS-based counterparts. Then, we present our experimental setup and research questions in Section 5.2. Finally, the results are detailed in Section 5.3 and discussed in Section 5.4.

Studied Self-Adaptable Virtual Machines

This section presents the three studied languages : HTML, RobLANG, and MiniJava.

HTML allows to describe the structure of a web page and its content. RobLANG is a domain-specific language (DSL) to specify the actions of a robot (e.g., use sensors, movement). MiniJava is an imperative and object-oriented language, subset of Java. In addition, we present for each language: the trade-off, the environment model, the adaptations, and the implementations of the two Self-Adaptable Virtual Machines (SAVMs), i.e., using the framework or not. For some of the SAVMs we rely on other tools (e.g. Truffle, EMF, Xtext). However, the SEALS framework can be used without them and therefore should be seen as a contribution in itself. The pairs of Self-Adaptable Virtual Machines (Handcrafted/SEALS-based) were built to achieve the same trade-off analysis. However, when the feedback loop is called periodically, the time at which a decision is made can differ due to delay induced by the framework.

These three examples describe a broad range of application domains for Self-Adaptable Virtual Machines and are complementary in terms of language characteristics (from general-purpose to DSL, imperative to declarative) as well as the discussed feedback loop. A summary of this information is presented in Table 1. HTML. is a representative of declarative domain-specific languages. As presented in Section 2.3, the trade-off for this language is between the quality of the page rendering and the size of data transferred, which is proportional to the energy consumption (see Section 2.3). Moreover, the environment model is empty, i.e., we do not need to monitor the environment. We consider three modules for this language: conditional loading, HTML lists perforation, and image degradation, also detailed in Section 2.3.

HTML engines being complex hand-crafted pieces of software, we did not modify an existing engine nor did we create our own. Instead, we built the SAVMs as Pretty-Printers that change the HTML code received by the browser.

The handcrafted HTML pretty printer is built using the Truffle DSL [START_REF] Humer | A domain-specific language for building self-optimizing AST interpreters[END_REF], benefiting from its instrumentation framework [START_REF] Van De | Fast, flexible, polyglot instrumentation support for debuggers and other tools[END_REF] to provide the modularity required to call the adaptation modules (i.e., using, among others, the framework's module registration and the dynamic injection capabilities in the interpreter of the VM). The feedback loop is implemented as a Truffle instrument (Truffle instrumentation clients who can observe and inject behavior into interpreters written using the Truffle DSL) and is called automatically by the instrumentation framework before each processed page. In addition, the adaptation context contains the trade-off model (between quality and consumption), but not the environment model which is unused in this case.

On the other hand, SEALS offers the same capabilities of module registration and frees the language engineer from the dynamic injection of module calls. Hence, the prettyprinter implemented using the framework does not need to rely on the Truffle DSL anymore. The adaptation process, i.e., the trade-off analysis and the MAPE-K loop logic, remains the same but is now built with the framework constructs.

RobLANG. is also a representative of domain-specific languages, where the trade-offs are often more specialized and tailored to the application domain supported by the DSL. With RobLANG being a language for robotics, we choose to do a trade-off between time and energy spent to perform actions. For this trade-off, we choose a speed regulation adaptation. This adaptation is interesting because the consumption of a motor is deeply impacted by its speed:

𝑃𝑜𝑤𝑒𝑟 𝑖 = 𝑃𝑜𝑤𝑒𝑟 𝑚𝑎𝑥 ( 𝑆𝑝𝑒𝑒𝑑 𝑖 𝑆𝑝𝑒𝑒𝑑 𝑚𝑎𝑥 ) 3 [1].
The handcrafted RobLANG SAVM was implemented on top of the abstract syntax generated from an Xtext [START_REF] Bettini | Implementing domain-specific languages with Xtext and Xtend[END_REF] project. The adaptation context contains the list of modules, the tradeoff model between time and energy, and the environment model containing the battery level. The feedback loop is triggered when a certain period of time has elapsed, to periodically monitor and adapt to the current battery level. At each iteration, the battery level is updated in the environment model. Then, we use the arithmetic semantics of goal models [START_REF] Fan | An arithmetic semantics for GRL goal models with function generation[END_REF] to convert the goal model to a constraint model to find the relevant speed percentage to use. In our implementation, we use the Choco Solver [START_REF] Jussien | Choco: an open source java constraint programming library[END_REF] to solve this problem. Using the solution of this problem, we configure the adaptation modules in the adaptation context.

Similarly, the SAVM implemented with SEALS uses the parser and abstract syntax generated by Xtext. The generated abstract syntax was modified to use the Node /AdaptableNode constructs. The adaptation process is converted to use SEALS' constructs, but keeps using the conversion to a constraint model for the Choco Solver as it is also part of SEALS.

MiniJava. represents the class of general-purpose languages, where trade-offs often revolve around the execution or analysis performance of the language versus the quality of the output taking the availability of computing resources into account. This trade-off is addressed by approximate computing techniques [START_REF] Mittal | A Survey of Techniques for Approximate Computing[END_REF][START_REF] Xu | Approximate Computing: A Survey[END_REF]. Hence, we propose to apply the approximate loop unrolling technique [START_REF] Rodriguez-Cancio | Approximate loop unrolling[END_REF] with a perforation rate depending on the CPU load of the computer.

The handcrafted MiniJava interpreter was designed on top of EMF [START_REF] Steinberg | EMF: eclipse modeling framework[END_REF] technologies. We created an adaptation context with a set of modules, a trade-off model with two properties of interest (accuracy and time), and the environment model containing the CPU load. The implemented feedback loop is triggered periodically to regularly monitor the CPU load.

As well as RobLANG, the framework-based SAVM implementation leverages on the EMF code generated for the handcrafted version and has been similarly modified. However, unlike the previous examples, the framework-based implementation of the adaptation process was slightly changed compared to the handcrafted implementation to reduce the number of expensive resolutions of the decision model.

Experimental Setup

The goal of the SEALS framework is to provide first class constructs for the language engineer to support the definition of domain-specific feedback loops in the definition of the DSL operational semantics. To validate the relevance of the abstraction provided, we propose to discuss:

1. The framework's applicability to the three examples 2. The assurances provided by the correctness envelopes 3. The reduction of the development costs 4. The performance overhead To support the discussion on the reduction of the development costs, we propose to compare the code size, in terms of lines of code, of framework-based SAVMs to their equivalent handcrafted versions. While performance is not the goal of the SEALS framework, we propose to also compare the performance of SAVMs implemented using SEALS to their manually implemented counterparts. This first estimation of the overhead of the framework will provide insight on the usability of the SAVMs created. However, the optimization of this framework is left as future work.

To compute correctly the number of lines of code, all the sources use the same coding conventions. The performance measurements are run on a computer with 31Gb of RAM and an Intel(R) Core(TM) i7-10850H CPU (12 cores at 2.70GHz) with Manjaro 21.1.0. The SAVMs are run alone on the computer, and using GraalVM CE version 20.3.2 as JVM due to its necessity for the handcrafted HTML pretty-printer. For each SAVM, we measure 30 program runs in a row repeated three times with reboot between each repetitions.

Results

Based on our experimentation, we are evaluating 1) the applicability of the approach on the aforementioned examples, 2) the assurances provided by the correctness envelopes, 3) the benefits of our approach in terms of reduction of the development costs, and 4) the performance overhead due to the use of the framework.

5.

3.1 Applicability of the approach. When evaluating the applicability of the approach, we look at the use of the constructs of the language. In particular, are all the constructs used and has the language engineer fall back to handcrafted solutions for uncovered parts of the development? When implementing the Self-Adaptable Virtual Machines using the framework, the two mandatory components to define are the feedback loop and the operational semantics. For the first, we provide 1st-class entities to define the feedback loop in the form of a MAPE-K Loop with the associated Adaptation Context that acts as the Knowledge of the MAPE-K Loop. On the other hand, SEALS supports the definition of operational semantics through the Operation and AdaptableOperation concepts. These concepts require the language engineer to use the Node and AdaptableNode constructs to define the abstract syntax of the languages, and consequently, the Seman-ticsAdaptationInterface construct for AdaptableNode. With the SelfAdaptiveVisitor generated from the operation and Self-Adaptable Language required by the framework, we use all the constructs provided to define the language. In addition, this definition of the language implies the use of the Module Registry construct and the Adaptation Module construct to implement the adaptations. The SAVMs studied thus use all the concepts provided by the framework.

Moreover, in our implementations, we relied on the decision model concepts provided to implement the decision process, hence, we did not have to manually implement the complex analysis of the model. More generally, the parts of the implemented SAVMs that were manually implemented are out of the scope of the framework (e.g., parsers). In other words, we did not need other constructs to implement the self-adaptable behavior with SEALS.

Correctness envelopes assurances.

To ensure the validity of the possible adapted semantics, the framework provides the concept of correctness envelope in the form of an arbitrarily complex Java type definition. The definition of AdaptableOperation according to a proposed configuration of these semantics (i.e., an instance of the correctness enve-lope) ensures that the semantics changes are bounded by the set of possible instances of the correctness envelope. On the other hand, the definition of the correctness envelope as a Java type definition protects the language semantics from invalid configuration by blocking all adaptations by default. The language engineer has to define subjects of adaptation (i.e., attributes) and operators to manipulate them (i.e., methods) for the type representing the correctness envelope, thus explicitly allowing some adaptation to be made.

Impact on development costs.

To evaluate the impact of the framework on the development costs of the SAVMs, we measure the number of lines of code needed to define the language and the adaptation process. When comparing code size of Handcrafted versus SEALS-based implementation, we compare similar implementations, i.e., the RobLANG implementation is based on Xtext in both cases but uses the SEALS framework conjointly in the second implementation. The same applies to the EMF-based MiniJava. On the other hand for HTML, we do not use Truffle and SEALS at the same time because the structure of SEALS is not fully compatible with the Truffle implementation. Those measurements are summarized in For HTML we observe a relatively high reduction in size. However, most of this reduction is due to the verbosity of the tag system of the Truffle instrumentation framework [START_REF] Van De | Fast, flexible, polyglot instrumentation support for debuggers and other tools[END_REF] (~700 lines of code), and Truffle DSL specific code. In the case of RobLANG, the reduction is very representative of the impact of the use of the framework because almost all the code in the framework-based implementation is identical to the handcrafted version. This reduction is mainly due to the abstraction of the components interaction and decision model implementation. Finally, MiniJava sees its size grow by ~600 lines. This augmentation is mainly due to the change in the operational semantics definition. The handcrafted version of MiniJava operational semantics is defined using the interpreter design patterns, hence, is defined as functions whereas SEALS requires to create a new class for each concept semantics. The overhead introduced by the classes' definition represent ~900 lines. In the end, it means that SEALS reduces the number of lines of code to implement the adaptation process by ~300 lines which is in line with what we observe for RobLang.

Introduced performance overhead.

This performance study aims only at observing the overhead related to the use of the framework. We measure for each SAVM the time spent to run a program with adaptations registered but not applied. We do not apply the adaptations to measure the overhead introduced by the framework, i.e., feedback loop abstractions and general architecture of the framework, to avoid being influenced by the difference in modules implementations. Table 3 summarize the average time measured and the time factor between handcrafted and frameworkbased versions (𝐻𝑎𝑛𝑑𝑐𝑟𝑎𝑓 𝑡𝑒𝑑 * 𝑇 𝑖𝑚𝑒 𝑓 𝑎𝑐𝑡𝑜𝑟 = 𝐹𝑟𝑎𝑚𝑒𝑤𝑜𝑟𝑘). These results are very different from one another and cannot be used to describe a general trend. However, even for MiniJava which introduces the highest overhead of the three experiments, its 16% overhead seems to be acceptable for the framework. Furthermore, the results for HTML provide anecdotal evidence for significant performance gains when compared to approaches that rely on general purpose capabilities. Yet, the results for MiniJava emphasize the limits of our framework abstractions compared to handcrafted adaptation processing. These results point to future work on performance to determine the reasons for the introduced overhead and find optimizations.

Discussion

Based on the applicability to the three examples studied and the gain in development costs granted by the abstractions, we conclude that our framework provides useful constructs to support the development of Self-Adaptive Virtual Machines. However, as for any framework, the gain in development costs needs to be balanced with the time necessary to understand and master the framework, which needs to be investigated in future work. In addition, the correctness envelopes provides control over the possible adaptations that can be performed on the language semantics to the language engineer. This mechanism allows a safe delegation of the adaptations' implementation to language users not involved in the language development. Finally, the results show a reasonable overhead for the framework, but further investigations into the performance of SEALS and possible optimizations are definitely needed.

Related Work

Abstracting non-functional features as first level entities of a programming language or a domain specific language is a common source of evolution. Thus Modula [START_REF] Wirth | Programming in MODULA-2 (3rd Corrected[END_REF], followed by the first object-oriented languages [START_REF] Cox | Object-Oriented Programming[END_REF], allowed to think about the notion of modular programming. ArchJava [START_REF] Aldrich | ArchJava: connecting software architecture to implementation[END_REF], twenty years later, showed the interest to put forward architectural features as an entity of programming languages. For another non-functional concern, taking variability into account has introduced particular abstract concepts within programming languages [START_REF] Liebig | An analysis of the variability in forty preprocessor-based software product lines[END_REF]. The Erlang language [START_REF] Armstrong | erlang[END_REF] finds its specificity among others in having introduced at the heart of its semantics the problem of concurrency and fault tolerance. If we take example from general purpose programming languages, it is common to see the same trend in DSLs. Our work is clearly part of this trend, aiming at introducing a non-functional concern (i.e., self-adaptation) at the heart of the semantics of new programming languages in providing a framework for building self-adaptive virtual machines.

The techniques used to build self-adaptable software systems have been widely studied for more than 20 years. Several surveys [START_REF] Kell | A Survey of Practical Software Adaptation Techniques[END_REF][START_REF] Krupitzer | A Survey on Engineering Approaches for Self-Adaptive Systems[END_REF] summarize the main techniques that have been designed. Then, the definition of a feedback loop has been investigated in the context of Self-Adaptive Systems [START_REF] Betty | Software Engineering for Self-Adaptive Systems: A Research Roadmap[END_REF], with a field mature enough to provide time-honored patterns such as the MAPE-K loop [START_REF] Kephart | The vision of autonomic computing[END_REF]. Within the taxonomy defined by Krupitzer et al. [START_REF] Krupitzer | A Survey on Engineering Approaches for Self-Adaptive Systems[END_REF] to classify self-adaptive techniques, the authors propose five main criteria to classify self-adaptation approaches (Reason, Level, Time, Technique, Adaptation control). For the Technique part, the authors introduce three sub-categories: Parameter, Structure, and Context. Parameter refers to adaptation through the change of parameters. Structure subsumes change in the structure of the technical system, e.g., new composition of components, removal/addition of components. Further, changes in the relation between elements, technical resources, or the environment/user(s) are also structural adaptations.Context refers to any changes in the context, e.g., modifying the state of context variables via actuators. The main approaches interested in adaptation techniques used at the implementation level are: Architecture-based, Reflection, Programming Paradigms (Component-Based Software Engineering [START_REF] Kozaczynski | Component-based software engineering[END_REF][START_REF] Zhang | Enabling safe dynamic component-based software adaptation[END_REF], Generative Programming [START_REF] Czarnecki | Generative Programming: Methods, Tools, and Applications[END_REF][START_REF] Scott D Fleming | An approach to implementing dynamic adaptation in c++[END_REF], Context-Oriented Programming [START_REF] Hirschfeld | Context-oriented programming[END_REF], and Aspect Oriented Programming [START_REF] Kiczales | Aspectoriented programming[END_REF][START_REF] Yang | An aspect-oriented approach to dynamic adaptation[END_REF]).

Introducing self adaptation as a first class entity in a new programming language could be seen in a way quite close to Aspect Oriented Programming (AOP). We share the vision of removing the concern of self-adaptation for the language user when she is defining her program. However while the use of AOP is a good way to abstract the concern of adaptation [START_REF] Yang | An aspect-oriented approach to dynamic adaptation[END_REF], it has limitations. First, the approach relies on a pointcut definition which is focused on method call only. In this context, adaptation of language domain-specific primitives is impossible. Second, because it relies on function calls, the adaptation can only be written by the domain expert (language user) that knows which ones to target. Finally, the domain expert will have to deal manually with the feature interaction of the different aspects used. In proposing a framework allowing within a virtual machine (VM) to specialize the semantics of a language feature in order to adapt to the execution context, we could easily change the normal behavior of a program running on top of our specialized VM. Thus, a language engineer can specify the semantics of her language but also the validity envelope of the language. This allows either another language engineer or a domain expert to specialize the semantics of the language, while ensuring by construction that the semantics remain within a correctness envelope defined by the original language designer. Besides, this semantics variation becomes available for all the programs running on top of this VM.

Conclusion

The SElf-Adaptive LanguageS Framework (SEALS) aims to support the building of self-adaptive virtual machines for domain-specific languages. This framework provides firstclass entities for the language engineer to promote domainspecific feedback loops in the definition of the DSL operational semantics. In particular, the framework supports the definition of (i) the abstract syntax and the semantics of the language as well as the correctness envelope defining the acceptable semantics for a domain concept, (ii) the feedback loop and associated trade-off reasoning, and (iii) the adaptations and the predictive model of their impact on the trade-off. In building three languages with self-adaptive virtual machines, we highlight the relevance of the abstractions and the effectiveness of correctness envelopes. The implementation of the adaptive behavior in these three languages used all constructs provided by the framework and did not need additional constructs. We also discuss the cost in terms of lines of code and provide a first comparison of the performance results with their manually implemented counterparts.

This initial performance study aimed only at observing the overhead related to the use of the framework. However, the HTML use case led us to discuss the potential benefits of using the framework for an implementation on top of Truffle/GraalVM rather than relying on its instrumentation framework. These first experiments pave the path to investigate performance benefits for integrating the autonomic loop at the level of the operational semantics of DSLs. Furthermore, future work has to be done at the level of concrete syntax or language tooling (editor) in order to make the language user aware of the parts of the program impacted by adaptable semantics. Finally, the problem of feature interactions [START_REF] Apel | Detection of Feature Interactions Using Feature-Aware Verification[END_REF] between adaptation modules remains. For the moment, the application order of the modules impacting the same AST node must be specified by the language designer.

Figure 1 .

 1 Figure 1. Approach overview on the HTML use case

  (a) Execution of an AdaptableNode (b) Execution of a Node

Figure 2 .

 2 Figure 2. Sequence diagrams representing components interactions when executing a node semantics

Figure 3 .

 3 Figure 3. Class diagram of the SEALS framework

4 5public 7 } 8 public 12 } 13 }

 4781213 ForInterface ( int increment ) { 6 this . increment = increment ; void changeIncrement ( int inc ) { 9 if ( inc * increment > 0) { // do not change sign 10 increment = inc ; 11 } Listing 1. Example of correctness envelope for a ForNode

1Listing 2 .

 2 public ForInterface defaultInterface () { 2 int inc = getIncrementFromExpression ( 3 this . getProgression () ) ; 4 return new ForInterface ( inc ) ; 5 } Example of defaultInterface implementation 1 public Object execute ( SelfAdaptiveVisitor vis , 2 Node n , Object execCtx ) ; 3 public Object execute ( SelfAdaptiveVisitor vis , 4 AdaptableNode n , Object execCtx , Interface config );Listing 3. Signatures of normal and adaptive operationsOperational Semantics. Complementary to the abstract syntax Node and AdaptableNode, the semantics of the language is defined by specializing the Operation and Adaptable-Operation abstract classes. These classes define the signatures for the semantics of a normal node and for an adaptable node, respectively (see Listing 3).

Figure 4 .

 4 Figure 4. Sequence diagram of the module additional filter function of adaptable nodes. This call mechanism frees the developers from calling the adaptation modules explicitly.In addition, this mechanism allows fine-grained control over the nodes targeted by the adaptation, but also over the nodes that can be adapted by a module. In the first case, the filtering function allows the module developer to check properties of the node and apply or not the adaptation (Figure4).

15 @Listing 4 . 2 int

 1542 Override public void changeIncrement ( int inc ) {} 16 } Mutable and immutable correctness envelopes 1 public ForInterface defaultInterface () {

Figure 5 .Figure 6 .

 56 Figure 5. Sequence diagram of the node semantics parameterization

1Listing 6 .

 6 SelfAdaptiveLang l = new SelfAdaptiveLang () ; 2 String source = readFile ( filePath ) ; 3 Parser parser = new Parser ( source ) ; 4 RootNode root = parser . parse () ; 5 l. getAdaptationContext () . registerModule ( new Module () ) ; 6 Object out = root . accept ( Example wrapper to create a standalone executable language

Table 1 .

 1 Summary of the languages, their type and trade-offs

	VMs	Type of Language	Trade-off
	HTML	Declarative DSL	Quality / Transfer size
	RobLANG	Imperative DSL	Time / Energy consumption
	MiniJava	Imperative GPL	Accuracy / Execution time

Table 2 Table 2 .

 22 Summary of the number of lines of code for handcrafted and framework-based SAVMs, and size factor for each language.

	Language Handcrafted Framework Size factor
	HTML	1969	543	x0.276
	RobLANG	2069	1682	x0.813
	MiniJava	13096	13672	x1.044

Table 3 .

 3 Performance of the handcrafted and frameworkbased SAVMs and associated time factor.

	Language	Handcrafted	Framework	Time factor
	HTML	0.944 ± 0.010	0.685 ± 0.006	x0.726
	RobLANG 1.095 ± 0.005	1.044 ± 0.007	x0.953
	MiniJava 17.115 ± 0.521 19.829 ± 0.519	x1.159

Cf. https://waymo.com/

Cf. https://www.netflix.com/

We use language users as a broad term that includes modelers and programmers using a given software (modeling or programming) language.