Research ArticleAn Object Proxy-Based Dynamic Layer Replacement toProtect IoMT Applications

Bo Han 1 Zhao Yin-Liang1 and Zhu Chang-Peng 2

1School of Electronic and Information Engineering Xirsquoan Jiaotong University Xirsquoan 710049 China2School of Liangjiang Articial Intelligence Chongqing University of Technology Chongqing 400054 China

Correspondence should be addressed to Bo Han bohanxjtueducn

Received 24 May 2019 Accepted 26 August 2019 Published 30 September 2019

Guest Editor Kuan Zhang

Copyright copy 2019 Bo Han et alis is an open access article distributed under the Creative Commons Attribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

e Internet of medical things (IoMT) has become a promising paradigm where the invaluable additional data can be collected bythe ordinary medical devices when connecting to the Internet e deep understanding of symptoms and trends can be providedto patients to manage their lives and treatments However due to the diversity of medical devices in IoMT the codes of healthcareapplications may be manipulated and tangled by malicious devices In addition the linguistic structures for layer activation inlanguages cause controls of layer activation to be part of programrsquos business logic which hinders the dynamic replacement oflayers erefore to solve the above critical problems in IoMT in this paper a new approach is rstly proposed to support thedynamic replacement of layer in IoMTapplications by incorporating object proxy into virtual machine (VM) Secondly the heapand address are used to model the object and object evolution to guarantee the feasibility of the approach After that we analyzethe inuences of eld access and method invocation and evaluate the risk and safety of the application when these constraints aresatised Finally we conduct the evaluations by extending Java VM to validate the eectiveness of the proposal

1 Introduction

Internet of medical things (IoMT) which plays an importantrole in healthcare industry to construct the safety andhealthy system in human society [1] is becoming the criticalpart in reducing healthcare costs providing timely medicalresponses and increasing the quality of medical treatmentIoMT in fact is an ecosystem of connected dierent kinds ofsensors including the wearable devices medical devices andclinical systems Each part in the ecosystem has its ownparticular context which is dierent from others On onehand various contexts should be managed by the healthcareapplication to provide context-based services For exampleto avoid patientsrsquo information leakage a function compo-nent of a healthcare application is used to describe themedical histories of patients to doctor in detail instead ofcollecting the sensitive information On the other hand thecomponent can be applied in smart watches to regulate thepatientsrsquo personal information However due to crosscut thecodes are easily scattered and tangled by context which

increase the costs of healthcare applicationsrsquo developmentand maintenance

Recently some researchers have introduced the tech-nologies from academic and industry to improve the ef-fectiveness and performance of IoMT applications Forexample the dynamic layered-recurrent neural network wasdeveloped by Turabieh et al [2] to recover missing dataData mashup-based web technology was proposed byElmisery et al [3] to serve a centralized environmentalmonitoring service

In addition the programming languages are compiler-based which means that all layers and their activationde-activation are determined in a development stage econtexts cannot be completely predicted at the developmentstage [4] healthcare applications which limit the applica-tions of language erefore in this paper we introduce anencapsulation mechanism-based context-orient pro-gramming paradigm (COP) in IoMT to reduce the occur-rences of above-mentioned crosscuts In COP theapplicationrsquos codes are divided into dierent parts (ie

HindawiSecurity and Communication NetworksVolume 2019 Article ID 2798571 9 pageshttpsdoiorg10115520192798571

layers) which is a new block-structured construction Eachlayer is related to other contexts where the layer activationand deactivation mechanism is provided to ensure that thecodes in different layers can be executed As a result theapplication can adjust its behaviors according to contextSome extensions of Java for COP such as JCOP [5] andEventCJ [6] have been implemented

Virtual machine (VM) which has been considered as anintermediate layer between the executing application and thehardware [7] is widely used in big data process and analysis[8 9] as well as increasing the possibility for dynamic codeevolution Object proxy [10] is advocated as a flexiblemechanism to dynamically adapt behavior of objects toadapt the behavior of a single object erefore this paperproposes a new approach which incorporates object proxyinto VM to enhance the flexibility of applications in terms ofcontext-based dynamical behavior adjustment Unlikeabove-mentioned COP languages based on VM layer ac-tivation and deactivation in our approach are used tomonitor the changes of context and dynamically activate ordeactivate layers so that the application can adapt its be-havior in context

In the perspective of VM a layer is a Java class In orderto support layer activation and deactivation mechanism onVM level the object proxy is used in our approach An objectat runtime is actually an object list which is composed of anobject of a base class and objects of layer classes e baseclass object is considered as a proxy object where eachmethod invocation is redirected to other objects in the objectlist As a result codes in the layer are executed to achieve thelayer activation Similarly the layer deactivation is alsoachieved by removing or deactivating other objects in thelist

Furthermore dynamic layer replacement can beachieved in our approach via object evolution As an object isrepresented as a list when VM monitors the changes ofcontext VM can evolve an object at runtime by inserting anew object of a layer class into it or deleting an object from itOnce the layer is replaced VM removes the objects oflayered classes in the removed layer from object lists andinserts new objects of layered class in the new loaded layeredclasses in the new layer into object lists As a result theapplication can adjust its behavior to fit the changes ofcontexts through dynamic layer replacement

On the other hand the heap and stack need to bescanned by the VM to find out all objects that to be evolvedwhich leads to a lot of overhead for the object evolution atruntime To relieve the overhead the objects are evolvedlazily in our approach Furthermore object evolution canlead to type violation [11]erefore this paper incorporatesheap and address into RFT-FJ [12] to model the objects andevolutions where the semantics of field access and methodinvocation on objects are described in detail Next theimpact of the evolution on type safety is analyzed After-wards the constraints on object evolution are proposed toavoid the type violation Finally the object evolution ispresented by extending Java VM to verify our application

e remainder of this paper is structured as follows InSection 2 we illustrate our approach by an application In

Section 3 the related work is given In Section 4 our ap-proach is described In Section 5 we present the imple-mentation and evaluation of our approach Conclusion isfinally presented in Section 6

2 Related Work

21 -e Internet of Medical -ings Rodrigues et al [13]reviewed technological advances made so far which can beused in IoMT and then analyzed the challenges to beovercome Ullah et al [14] presented a new semantic modelfor patientsrsquo e-health based on existing technologies whichare used to deploy IoT in the field of medical and smarthealth care Turabieh et al [2] introduced a dynamic L-RNNfrom artificial intelligence to recover missing data fromIoMT applications to guarantee high quality of services tothe end users Kernec et al [15] presented place of radar forassisted living in the context of IoT for health and pointedout how important the context is Elmisery et al [3] useddata mashup from web technology to serve a centralizedenvironmental monitoring service Haoyu et al [16] usedcloud computing to provide real-time sleep apnea detectioney both introduced technologies from other researchareas to IoMT Similarly we introduce COP programmingparadigm from programming language area to reduce codesrsquoscatter and tangle in IoMT applications Joyia et al [1]pointed out some challenges in IoMT where softwareimplementation is still full of challenges We believe ourwork makes an important step toward resolving thesechallenges

22ObjectEvolution In order to support context awarenessobject composition has been used to represent objects withsome dynamic behaviors [7 17]

An object evolution approach is proposed in [7] eapproach is based on composition and delegation while ourapproach is based on composition and proxy is is themost important difference between them Compared withdelegation proxy is easier to achieve semantic analysis andimplementation of layer activation and deactivation al-though it suffers from a little less flexibility

In [18] an evolution approach based on version con-sistency is proposed which is similar to our evolution ap-proach However its version consistency is applied for theevolution of components in distributed system while ours isapplied for objects is is the most important differencebetween the two approaches in terms of version consistency

In [17] object composition and delegation with a statictype discipline are also used for dynamic behavior adap-tation of objects However the object in [17] is only explicitlycomposed while the composition is implicit in our approachFurthermore object composition in [17] is used for dynamicinheritance and code reuse while object composition in ourapproach is used for dynamic behavior adaptation of theprogram

Granule-oriented programming [19] uses fitness to de-termine which components are available for applications In[12] predicate is applied to determine the applicability of

2 Security and Communication Networks

context-specific methods Our approach also uses predicatefor the similar purpose However there are some differencesbetween them Predicate in [19] is not formally defined whilefitness in [12] and our approach is formally defined as apredicate method Moreover fitness in [12] is applied toselect context-specific methods of composed classes whilepredicate in our approach is applied to select context-specificmethods of composed objects

In [20] various problems of software evolution and theircorresponding solutions are presented and classified intoseveral types Some required operations on evolution areformally described and analyzed to ensure the consistencybefore and after evolution

23 Context-Oriented Programming In [6] an approachthat incorporates features of AOP is presented to implementfeatures of COP Both it and our approach share somecommon features Firstly the predicate is used to determinethe applicability of the context-specific method Secondlylayer activation is on a per-instance basis rather than a per-thread basis However our approach is VM-based while theapproach presented in [6] is compiler-based Although theapproach incorporates features of AOP dynamic aspectweaving is not incorporated erefore the approach doesnot support dynamic layer addition while our approachsupports it is is a significant difference between the twoapproaches

ContextFJ [21] is an extension of Featherweight Javawhich models language mechanisms for context-orientedprogramming Although ContextFJ and our approach bothdirectly express context-dependent behavior there are stillsome differences between them Firstly ContextFJ and ourapproach use block-structured constructs and object proxyfor dynamic behavior adaptation respectively SecondlyContextFJ does not allow layers to introduce new methodsbut our approach does

3 System Model

In this section we first describe problems caused by Java-based COP languages by a simple healthcare application andthen propose object evolution approach a VM-centric ap-proach to solve them

A healthcare application code snippet written in a Java-based COP language is shown in Figure 1 which is used todisplay healthcare schedule information for users If thecurrent device is a doctorrsquos computer the application canshow more details about medical histories of their patientsand must not show patientsrsquo sensitive personal informationprotecting their personal privacy On the other hand ifrunning on patientsrsquo smart watches the application canbriefly show important medical schedule including somepersonal information

e basic part of the application is a Java program andclasses in the part are called basic ones not consideringruntime context e rest are two layers L1 and L2 A layer isdefined by the keyword layer consisting of a predicator anda Java class called layered class e predictor is used to

check whether or not the layer matches current executioncontext If so the methods in the layered class can beexecuted

In compiler-based COP languages layer activation anddeactivation are part of codes which means if some layers nolonger match the current context an application has torewrite recompile and re-executeis not only shortens itslife cycle but also makes it not adjust its behaviors to thecontext well

For solving such problems our approach proposes thatVM is responsible for layer activation and deactivationatis each time methods in basic classes are invoked VM isresponsible for selecting and executing methods in properlayers which match the current execution context As aresult each time a layer has bugs or no longer matches newexecution context a new layer can easily be dynamicallyloaded by VM to replace the old layer

To achieve our approach the object structure is ex-tended as shown in Figure 2 An object at runtime isrepresented into a double linked list e first element of theliked list is an object of a based class e other elements areobjects of layer classes For example when the layer L1 isactivated a runtime object O is composed of Ob and OL1 anobject of the base class calendar and that of the layered classrespectively VM redirects all method invocations on Ob tothese OL1 as long as L1 matches the current execution en-vironment Actually Ob is considered as an object proxy

On the other hand if L1 is replaced with L1prime VM evolvesO to Oprime by replacing Ol1 with Ol1prime a new object created byVM Since only Ob points to OL1 the redirection can avoidscan heap and stack

Furthermore if there are many objects containing ob-jects of L1 they must be not immediately evolved becausethey may be accessed very soon erefore our approachevolves these objects in a lazy manner that is an object is

Figure 1 Dynamic layer replacement

Security and Communication Networks 3

evolved only when it is accessed To check whether or not anobject is evolved a version number is added to structures of aclass and an object e version numbers of a classes and anobject are initialized when they are loaded and created re-spectively Specifically when a layer is replaced due to contextmismatch the version number of a base class is increased by 1only if the same name layered class in the layer is loaded Andthe version number of the layered class is initialized with that ofthe base class When an object is created its version number isinitialized with that of its class If version numbers of a class andan object are different then the object will be evolved when it isaccessed and version numbers of all elements in the object areupdated As a result our approach may avoid scan heap andstack to evolve objects and improve object evolution efficiency

Our object evolution approach is summarized as follows

(1) For an object O represented as Ob OCL if there is amethod invocation on it the version numbers of Obare firstly compared with those of its base class C

(2) If equal the object O is not evolved and the in-vocation will be executed Specifically if the fieldldquoreal_objrdquo in Ob points to null which means OCL isnull the method will be resolved in C and executedOtherwise the method will resolve the object CLpointed by the real_obj field in Ob As a resultmethods which defined layered classes are executed

(3) If not equal which means at least a layer replacementhas occurred then the object O has to be evolved byVM Specifically

(i) If OCL is null then an object of a layered classnamed C is firstly created and composed adouble linked list with Ob Furthermore theversion number of Ob will be updated FinallyVM executes step 1 again

(ii) If OCL is not null then OCL will be replaced witha new object OCLprime of a new layered class C from anew layer is is achieved by redirecting thereal_obj field in Ob to the newly created objectOCLprime and the field proxy_obj in OCLprime to ObFigure 2(b) shows the evolution process Fur-thermore the version number of Ob will beupdated Finally VM executes step 1 again

At runtime objects may be replaced according to Step 3which results in type violation In the next section we model

objects and their evolutions and then formally describe fieldaccess and method invocation on objects Afterwards someconstraints are proposed to ensure that object evolution doesnot cause type violation

4 Object Evolution

We first formally describe classes objects and field accessand method invocation on objects Afterwards we analyzethe impact of objectsrsquo evolutions on them and make someconstraints to ensure such evolutions do not result in typeviolation In this paper classes are defined as sets and objectsare formally described as a set of addresses in a heap

Definition 1 (class definition) A class C can be representedby a set Tf T⟶ Tprimem1113966 1113967 composed of fields and methodswhere Tf is the abbreviation of T1f1 Tnfn and T and fdenote a type and a field name respectively T⟶ Tprimem issimilar

Two auxiliary functions Sf and Sm return the field set andthe method set of a specific class C whose definitions aregiven as follows

Sf(C) empty if C empty

f1113966 1113967 if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

Sm(C) empty if C empty

m if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

(1)

Definition 2 (combination class) C CL is a combination oftwo same name classes where C and CL denote a base class Cand a layered class C respectivelye combination containsall elements of C and CL Ob OL is an object of C CLwhich can be described as the two-tuple langC CL f lrang andf Sf(C)cup Sf(CL)

Definition 3 (object definition) An object is represented as atwo-tuple langC f lrang or langC CL f lrang e first element isthe type of the object and the second one is its fields andaddresses of these fields where l denotes an address

real_obj

proxy_obj

An object of a layered class

versionflag

real_obj

proxy_objversion

flag

An object of a base class

(a)

(1)

(2)o

L1 L1prime

VM

Display calendaritem

(b)

Figure 2 Object list (a) Proxy-based object structure (b) Object evolution

4 Security and Communication Networks

Based on the above definitions we formally describe fieldaccess and method invocation on objects by a computationstate A computation state can be described as the pair of anexpression and heap (e H) where an expression may be afield access lf or a method invocation lm(l) erefore thereduction relationship can be described by e H⟶ eprime Hwhich indicates that a computation state eH can be reducedto another state eprime H Furthermore ⟶lowast denotes thereflexive transitive closure of ⟶

e rule for field access (E-PROJ1 and E-PROJ2) for anobject if its address in the heapH is l its type is C or C CLand the field f has been defined then the field access can bereduced to its value

e rule for the method invocation (E-LINVKE-LINVK2 E-LINVK3 and E-CINVK) compared withfield access the method invocations are more complexsince they contain context match and object evolutioneir main ideas are (1) if the receiver of a method in-vocation is only an object of the base class C the invocationis directly reduced to its method body where parametersare replaced by arguments and this is replaced by thereceiver and (2) if the receiver of a method invocation is anobject of a combination class C CL the method in-vocation will be redirected to the same type method in alayered class CL If the layer which contains CL matches thecurrent context then the invocation can be reduced to themethod body of the method Otherwise the object has to beevolved Specifically rules for method invocation are de-scribed as follows

(i) E-INVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a base class C If the method m is resolved in Cthen the invocation is directly reduced to its methodbody where parameters x are replaced by argu-ments l and this is replaced by l

(ii) E-LINVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL and the layer containing CL matchesthe current context then the invocation can bereduced to the method body in CL where param-eters x are replaced by arguments l and this isreplaced by l

(iii) E-LINVK2 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL but the layer does not match thecurrent context and a proper layer which matchesthe current context cannot be found out or pro-vided then the invocation can be reduced to themethod body of the same type method in the baseclass C where parameters x are replaced by argu-ments l and this is replaced by l

(iv) E-LINVK3 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m is

resolved in CL but the layer does not match thecurrent and a proper layer can be found out orprovided then the object is firstly evolved by VMthat is an new object of CLprime is created and replacesthe object of CL in O and then the objectrsquos type isalso updated to C CLprime Afterwards the invocationis reduced to the method body of the same typemethod in CLprime where parameters x are replaced byarguments l and this is replaced by l

(v) E-CINVK rule for an object O represented asOb OCL its address in the heapH is l and its type isa combination class C CL If a methodm is invokedby another method in the same layer class then thecontext match is not checked and the invocation isreduced to its body where parameters x are replacedby arguments l and this is replaced by l

In the above-mentioned rules the function mbdoy ()models the semantic of themethod resolution in Java It returnsa method body of a method in a class More details about it areshown in [7 12] ldquopredicate() true IN CLrdquo represents the layer Lthatmatches the current context while ldquopredicate() false INCLrdquorepresents the layer L that does not match

e notation⟹ in the E-LINVK3 rule denotes objectevolution Object evolution may result in the type violationwhen evolved object is being accessed For example ifE-LINVK1 is interrupted after it executes for a moment thenE-LINVK3 is executed and an object l is evolved WhenE-LINVK1 is executed again the method may not exist dueto lrsquos change yielding the type violation erefore someconstraints should be proposed for object evolution so thatthe type violation can be avoided

Next we firstly formally describe object evolution andpresent some constraints on it which are shown in thefollowing definition

Definition 4 (valid object evolution) Assume that an object lis evolved to l denoted by l⟹ l since a layered class CL isreplaced by another well-formed CLprime we have H(l)

langC CL1 f lrang H(l) langC CL2 fprime lprimerang f Sf(C)capSf(CL1 )fprime Sf(C)cup Sf(CL2) Furthermore the evolution isvalid only if the following conditions hold

(1) forallm m is in stack if m isin l then m isin l

(2) forallf f isin Sf(CL) f is only accessed by m isin Sm(CL)

(3) Sm(CL1)sube Sm(CL2) and forallm m isin Sm(CL1) then mtype(m CL2)ltmtype(m CL1)

e first constraint requires that object evolution cannothave influence on running methods is ensures thesemethods still exist after object evolution avoiding runtimeerrors e second constraint ensures fields in a layered classare only accessed by methods in the class which ensuresaccessing fields do not lose after object evolution efunctionmtype [7 12] returns the type of a method in a classe third constraint requires CL2 to have the same methodsas CL1 which ensures there are no dynamic-type violationsafter objectsrsquo evolution

Security and Communication Networks 5

Based on the above definition if base classes and layerclasses are well typed the following theorem can ensure typeviolation does not occur after object evolution We denoteexpressions before and after objection evolution by e and erespectively

Theorem 1 Assume that e contains l and that l⟹ l resultsin e⟹ e if e has the property of type-safe and all layer classCL in each replacement are well typed then e has the propertyof type-safe too

e theorem intuitively indicates that if any componentof a well-typed expression e is replaced with another well-typed component then e is still well typed is is verysimilar to industrial products in the real world For exampleif a component of a qualified car is replaced with anotherqualified one then the car is still qualified

Proof We prove the theorem by induction

(1) Basic if l is unchanged then e is unchangedAccording to the assumption the theorem holds

(2) Reduction assume that e⟹ e results from l⟹ lwhich is caused by CL2 replacing CL1 If e is type-safee is type-safe

Proof by Contradiction If e has type violation caused byl⟹ l Without loss of generality assume that H(l)

langC CL1 f lrang H(l) langC CL1 fprime lprimerang

(i) If l contains a static-type violation according to thestatic-type violation definition [11] we have l f andf isin fandf notin fprime or l m(l) and m isin Sm(C)cup Sm(CL1)

andm notin Sm(C)cup Sm(CL2)

(a) Firstly if there exists l m(l) and the method m isbeing executed then according to the first con-straint of valid object evolution m is not in thestack eg l m(l) is not being executed which iscontradicted with the assumption

(b) Secondly if there exists l m(l) and m is not beinginvoked then according to the condition that e andCL are well typed only base method invocationscan be redirected to the corresponding methods oflayered classes erefore we have m isin Sm(C)which contradicts with the assumption

(c) If lprimef and f isin fandf notin fprime then f isin Sf(CL1)

andm notin Sf(CL2) According to the second con-straint of valid object evolution fields in a layeredclass only are accessed only by methods in thesame class Becausem is not in the stack the fieldf is not accessed e result is contradicted withthe assumption Finally the theorem holds

E-PROJ1 lfiH⟶ li if H(l) langC f lrang

E-PROJ2 lfiH⟶ li if H(l) langC CL f lrang

E-INVK lm(l)H⟶ [this⟼ l x⟼l]e H if H(l) langC f lrang andmbody(mC) (x e)

E-CINVK lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang andmbody mC CL( 1113857 (x e)

E-LINVK lm(l)H⟶ [this⟼ l x⟼l]e if H(l) langC CL f lrang mbody mC CL( 1113857 (x e)

predicate ( ) true INCL

E-LINVK2 lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang predicate ( ) false INCL

existCLprime predicate( )true INCLprime andm isin CandL( 1113857 mbody(mC) (x e)

E minus LINVK3 lm(l)H⟶ lm(l) l⟹langC CLprime fprime lrang1113876 1113877Hwherefprime Sf(C)cup Sf CLprime( 1113857 if H(l) langC CL f lrang

predicate ( ) false INCLexistCLprime predicate ( ) true INCLprime andm isin CLprime safe( )

(2)

(ii) If l contains a dynamic-type violation then we haveC CL1≮ C CL1 Assume that lrsquos type is C CL1and lrsquos type is C CL2 According to the third con-straint of valid object evolution and the subclass

relationship record we have C CL1 lt C CL2which is contradicted with the assumption So thedynamic-type violation is nonexistent e theoremholds

6 Security and Communication Networks

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

context-specific methods Our approach also uses predicatefor the similar purpose However there are some differencesbetween them Predicate in [19] is not formally defined whilefitness in [12] and our approach is formally defined as apredicate method Moreover fitness in [12] is applied toselect context-specific methods of composed classes whilepredicate in our approach is applied to select context-specificmethods of composed objects

In [20] various problems of software evolution and theircorresponding solutions are presented and classified intoseveral types Some required operations on evolution areformally described and analyzed to ensure the consistencybefore and after evolution

23 Context-Oriented Programming In [6] an approachthat incorporates features of AOP is presented to implementfeatures of COP Both it and our approach share somecommon features Firstly the predicate is used to determinethe applicability of the context-specific method Secondlylayer activation is on a per-instance basis rather than a per-thread basis However our approach is VM-based while theapproach presented in [6] is compiler-based Although theapproach incorporates features of AOP dynamic aspectweaving is not incorporated erefore the approach doesnot support dynamic layer addition while our approachsupports it is is a significant difference between the twoapproaches

ContextFJ [21] is an extension of Featherweight Javawhich models language mechanisms for context-orientedprogramming Although ContextFJ and our approach bothdirectly express context-dependent behavior there are stillsome differences between them Firstly ContextFJ and ourapproach use block-structured constructs and object proxyfor dynamic behavior adaptation respectively SecondlyContextFJ does not allow layers to introduce new methodsbut our approach does

3 System Model

In this section we first describe problems caused by Java-based COP languages by a simple healthcare application andthen propose object evolution approach a VM-centric ap-proach to solve them

A healthcare application code snippet written in a Java-based COP language is shown in Figure 1 which is used todisplay healthcare schedule information for users If thecurrent device is a doctorrsquos computer the application canshow more details about medical histories of their patientsand must not show patientsrsquo sensitive personal informationprotecting their personal privacy On the other hand ifrunning on patientsrsquo smart watches the application canbriefly show important medical schedule including somepersonal information

e basic part of the application is a Java program andclasses in the part are called basic ones not consideringruntime context e rest are two layers L1 and L2 A layer isdefined by the keyword layer consisting of a predicator anda Java class called layered class e predictor is used to

check whether or not the layer matches current executioncontext If so the methods in the layered class can beexecuted

In compiler-based COP languages layer activation anddeactivation are part of codes which means if some layers nolonger match the current context an application has torewrite recompile and re-executeis not only shortens itslife cycle but also makes it not adjust its behaviors to thecontext well

For solving such problems our approach proposes thatVM is responsible for layer activation and deactivationatis each time methods in basic classes are invoked VM isresponsible for selecting and executing methods in properlayers which match the current execution context As aresult each time a layer has bugs or no longer matches newexecution context a new layer can easily be dynamicallyloaded by VM to replace the old layer

To achieve our approach the object structure is ex-tended as shown in Figure 2 An object at runtime isrepresented into a double linked list e first element of theliked list is an object of a based class e other elements areobjects of layer classes For example when the layer L1 isactivated a runtime object O is composed of Ob and OL1 anobject of the base class calendar and that of the layered classrespectively VM redirects all method invocations on Ob tothese OL1 as long as L1 matches the current execution en-vironment Actually Ob is considered as an object proxy

On the other hand if L1 is replaced with L1prime VM evolvesO to Oprime by replacing Ol1 with Ol1prime a new object created byVM Since only Ob points to OL1 the redirection can avoidscan heap and stack

Furthermore if there are many objects containing ob-jects of L1 they must be not immediately evolved becausethey may be accessed very soon erefore our approachevolves these objects in a lazy manner that is an object is

Figure 1 Dynamic layer replacement

Security and Communication Networks 3

evolved only when it is accessed To check whether or not anobject is evolved a version number is added to structures of aclass and an object e version numbers of a classes and anobject are initialized when they are loaded and created re-spectively Specifically when a layer is replaced due to contextmismatch the version number of a base class is increased by 1only if the same name layered class in the layer is loaded Andthe version number of the layered class is initialized with that ofthe base class When an object is created its version number isinitialized with that of its class If version numbers of a class andan object are different then the object will be evolved when it isaccessed and version numbers of all elements in the object areupdated As a result our approach may avoid scan heap andstack to evolve objects and improve object evolution efficiency

Our object evolution approach is summarized as follows

(1) For an object O represented as Ob OCL if there is amethod invocation on it the version numbers of Obare firstly compared with those of its base class C

(2) If equal the object O is not evolved and the in-vocation will be executed Specifically if the fieldldquoreal_objrdquo in Ob points to null which means OCL isnull the method will be resolved in C and executedOtherwise the method will resolve the object CLpointed by the real_obj field in Ob As a resultmethods which defined layered classes are executed

(3) If not equal which means at least a layer replacementhas occurred then the object O has to be evolved byVM Specifically

(i) If OCL is null then an object of a layered classnamed C is firstly created and composed adouble linked list with Ob Furthermore theversion number of Ob will be updated FinallyVM executes step 1 again

(ii) If OCL is not null then OCL will be replaced witha new object OCLprime of a new layered class C from anew layer is is achieved by redirecting thereal_obj field in Ob to the newly created objectOCLprime and the field proxy_obj in OCLprime to ObFigure 2(b) shows the evolution process Fur-thermore the version number of Ob will beupdated Finally VM executes step 1 again

At runtime objects may be replaced according to Step 3which results in type violation In the next section we model

objects and their evolutions and then formally describe fieldaccess and method invocation on objects Afterwards someconstraints are proposed to ensure that object evolution doesnot cause type violation

4 Object Evolution

We first formally describe classes objects and field accessand method invocation on objects Afterwards we analyzethe impact of objectsrsquo evolutions on them and make someconstraints to ensure such evolutions do not result in typeviolation In this paper classes are defined as sets and objectsare formally described as a set of addresses in a heap

Definition 1 (class definition) A class C can be representedby a set Tf T⟶ Tprimem1113966 1113967 composed of fields and methodswhere Tf is the abbreviation of T1f1 Tnfn and T and fdenote a type and a field name respectively T⟶ Tprimem issimilar

Two auxiliary functions Sf and Sm return the field set andthe method set of a specific class C whose definitions aregiven as follows

Sf(C) empty if C empty

f1113966 1113967 if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

Sm(C) empty if C empty

m if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

(1)

Definition 2 (combination class) C CL is a combination oftwo same name classes where C and CL denote a base class Cand a layered class C respectivelye combination containsall elements of C and CL Ob OL is an object of C CLwhich can be described as the two-tuple langC CL f lrang andf Sf(C)cup Sf(CL)

Definition 3 (object definition) An object is represented as atwo-tuple langC f lrang or langC CL f lrang e first element isthe type of the object and the second one is its fields andaddresses of these fields where l denotes an address

real_obj

proxy_obj

An object of a layered class

versionflag

real_obj

proxy_objversion

flag

An object of a base class

(a)

(1)

(2)o

L1 L1prime

VM

Display calendaritem

(b)

Figure 2 Object list (a) Proxy-based object structure (b) Object evolution

4 Security and Communication Networks

Based on the above definitions we formally describe fieldaccess and method invocation on objects by a computationstate A computation state can be described as the pair of anexpression and heap (e H) where an expression may be afield access lf or a method invocation lm(l) erefore thereduction relationship can be described by e H⟶ eprime Hwhich indicates that a computation state eH can be reducedto another state eprime H Furthermore ⟶lowast denotes thereflexive transitive closure of ⟶

e rule for field access (E-PROJ1 and E-PROJ2) for anobject if its address in the heapH is l its type is C or C CLand the field f has been defined then the field access can bereduced to its value

e rule for the method invocation (E-LINVKE-LINVK2 E-LINVK3 and E-CINVK) compared withfield access the method invocations are more complexsince they contain context match and object evolutioneir main ideas are (1) if the receiver of a method in-vocation is only an object of the base class C the invocationis directly reduced to its method body where parametersare replaced by arguments and this is replaced by thereceiver and (2) if the receiver of a method invocation is anobject of a combination class C CL the method in-vocation will be redirected to the same type method in alayered class CL If the layer which contains CL matches thecurrent context then the invocation can be reduced to themethod body of the method Otherwise the object has to beevolved Specifically rules for method invocation are de-scribed as follows

(i) E-INVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a base class C If the method m is resolved in Cthen the invocation is directly reduced to its methodbody where parameters x are replaced by argu-ments l and this is replaced by l

(ii) E-LINVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL and the layer containing CL matchesthe current context then the invocation can bereduced to the method body in CL where param-eters x are replaced by arguments l and this isreplaced by l

(iii) E-LINVK2 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL but the layer does not match thecurrent context and a proper layer which matchesthe current context cannot be found out or pro-vided then the invocation can be reduced to themethod body of the same type method in the baseclass C where parameters x are replaced by argu-ments l and this is replaced by l

(iv) E-LINVK3 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m is

resolved in CL but the layer does not match thecurrent and a proper layer can be found out orprovided then the object is firstly evolved by VMthat is an new object of CLprime is created and replacesthe object of CL in O and then the objectrsquos type isalso updated to C CLprime Afterwards the invocationis reduced to the method body of the same typemethod in CLprime where parameters x are replaced byarguments l and this is replaced by l

(v) E-CINVK rule for an object O represented asOb OCL its address in the heapH is l and its type isa combination class C CL If a methodm is invokedby another method in the same layer class then thecontext match is not checked and the invocation isreduced to its body where parameters x are replacedby arguments l and this is replaced by l

In the above-mentioned rules the function mbdoy ()models the semantic of themethod resolution in Java It returnsa method body of a method in a class More details about it areshown in [7 12] ldquopredicate() true IN CLrdquo represents the layer Lthatmatches the current context while ldquopredicate() false INCLrdquorepresents the layer L that does not match

e notation⟹ in the E-LINVK3 rule denotes objectevolution Object evolution may result in the type violationwhen evolved object is being accessed For example ifE-LINVK1 is interrupted after it executes for a moment thenE-LINVK3 is executed and an object l is evolved WhenE-LINVK1 is executed again the method may not exist dueto lrsquos change yielding the type violation erefore someconstraints should be proposed for object evolution so thatthe type violation can be avoided

Next we firstly formally describe object evolution andpresent some constraints on it which are shown in thefollowing definition

Definition 4 (valid object evolution) Assume that an object lis evolved to l denoted by l⟹ l since a layered class CL isreplaced by another well-formed CLprime we have H(l)

langC CL1 f lrang H(l) langC CL2 fprime lprimerang f Sf(C)capSf(CL1 )fprime Sf(C)cup Sf(CL2) Furthermore the evolution isvalid only if the following conditions hold

(1) forallm m is in stack if m isin l then m isin l

(2) forallf f isin Sf(CL) f is only accessed by m isin Sm(CL)

(3) Sm(CL1)sube Sm(CL2) and forallm m isin Sm(CL1) then mtype(m CL2)ltmtype(m CL1)

e first constraint requires that object evolution cannothave influence on running methods is ensures thesemethods still exist after object evolution avoiding runtimeerrors e second constraint ensures fields in a layered classare only accessed by methods in the class which ensuresaccessing fields do not lose after object evolution efunctionmtype [7 12] returns the type of a method in a classe third constraint requires CL2 to have the same methodsas CL1 which ensures there are no dynamic-type violationsafter objectsrsquo evolution

Security and Communication Networks 5

Based on the above definition if base classes and layerclasses are well typed the following theorem can ensure typeviolation does not occur after object evolution We denoteexpressions before and after objection evolution by e and erespectively

Theorem 1 Assume that e contains l and that l⟹ l resultsin e⟹ e if e has the property of type-safe and all layer classCL in each replacement are well typed then e has the propertyof type-safe too

e theorem intuitively indicates that if any componentof a well-typed expression e is replaced with another well-typed component then e is still well typed is is verysimilar to industrial products in the real world For exampleif a component of a qualified car is replaced with anotherqualified one then the car is still qualified

Proof We prove the theorem by induction

(1) Basic if l is unchanged then e is unchangedAccording to the assumption the theorem holds

(2) Reduction assume that e⟹ e results from l⟹ lwhich is caused by CL2 replacing CL1 If e is type-safee is type-safe

Proof by Contradiction If e has type violation caused byl⟹ l Without loss of generality assume that H(l)

langC CL1 f lrang H(l) langC CL1 fprime lprimerang

(i) If l contains a static-type violation according to thestatic-type violation definition [11] we have l f andf isin fandf notin fprime or l m(l) and m isin Sm(C)cup Sm(CL1)

andm notin Sm(C)cup Sm(CL2)

(a) Firstly if there exists l m(l) and the method m isbeing executed then according to the first con-straint of valid object evolution m is not in thestack eg l m(l) is not being executed which iscontradicted with the assumption

(b) Secondly if there exists l m(l) and m is not beinginvoked then according to the condition that e andCL are well typed only base method invocationscan be redirected to the corresponding methods oflayered classes erefore we have m isin Sm(C)which contradicts with the assumption

(c) If lprimef and f isin fandf notin fprime then f isin Sf(CL1)

andm notin Sf(CL2) According to the second con-straint of valid object evolution fields in a layeredclass only are accessed only by methods in thesame class Becausem is not in the stack the fieldf is not accessed e result is contradicted withthe assumption Finally the theorem holds

E-PROJ1 lfiH⟶ li if H(l) langC f lrang

E-PROJ2 lfiH⟶ li if H(l) langC CL f lrang

E-INVK lm(l)H⟶ [this⟼ l x⟼l]e H if H(l) langC f lrang andmbody(mC) (x e)

E-CINVK lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang andmbody mC CL( 1113857 (x e)

E-LINVK lm(l)H⟶ [this⟼ l x⟼l]e if H(l) langC CL f lrang mbody mC CL( 1113857 (x e)

predicate ( ) true INCL

E-LINVK2 lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang predicate ( ) false INCL

existCLprime predicate( )true INCLprime andm isin CandL( 1113857 mbody(mC) (x e)

E minus LINVK3 lm(l)H⟶ lm(l) l⟹langC CLprime fprime lrang1113876 1113877Hwherefprime Sf(C)cup Sf CLprime( 1113857 if H(l) langC CL f lrang

predicate ( ) false INCLexistCLprime predicate ( ) true INCLprime andm isin CLprime safe( )

(2)

(ii) If l contains a dynamic-type violation then we haveC CL1≮ C CL1 Assume that lrsquos type is C CL1and lrsquos type is C CL2 According to the third con-straint of valid object evolution and the subclass

relationship record we have C CL1 lt C CL2which is contradicted with the assumption So thedynamic-type violation is nonexistent e theoremholds

6 Security and Communication Networks

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

evolved only when it is accessed To check whether or not anobject is evolved a version number is added to structures of aclass and an object e version numbers of a classes and anobject are initialized when they are loaded and created re-spectively Specifically when a layer is replaced due to contextmismatch the version number of a base class is increased by 1only if the same name layered class in the layer is loaded Andthe version number of the layered class is initialized with that ofthe base class When an object is created its version number isinitialized with that of its class If version numbers of a class andan object are different then the object will be evolved when it isaccessed and version numbers of all elements in the object areupdated As a result our approach may avoid scan heap andstack to evolve objects and improve object evolution efficiency

Our object evolution approach is summarized as follows

(1) For an object O represented as Ob OCL if there is amethod invocation on it the version numbers of Obare firstly compared with those of its base class C

(2) If equal the object O is not evolved and the in-vocation will be executed Specifically if the fieldldquoreal_objrdquo in Ob points to null which means OCL isnull the method will be resolved in C and executedOtherwise the method will resolve the object CLpointed by the real_obj field in Ob As a resultmethods which defined layered classes are executed

(3) If not equal which means at least a layer replacementhas occurred then the object O has to be evolved byVM Specifically

(i) If OCL is null then an object of a layered classnamed C is firstly created and composed adouble linked list with Ob Furthermore theversion number of Ob will be updated FinallyVM executes step 1 again

(ii) If OCL is not null then OCL will be replaced witha new object OCLprime of a new layered class C from anew layer is is achieved by redirecting thereal_obj field in Ob to the newly created objectOCLprime and the field proxy_obj in OCLprime to ObFigure 2(b) shows the evolution process Fur-thermore the version number of Ob will beupdated Finally VM executes step 1 again

At runtime objects may be replaced according to Step 3which results in type violation In the next section we model

objects and their evolutions and then formally describe fieldaccess and method invocation on objects Afterwards someconstraints are proposed to ensure that object evolution doesnot cause type violation

4 Object Evolution

We first formally describe classes objects and field accessand method invocation on objects Afterwards we analyzethe impact of objectsrsquo evolutions on them and make someconstraints to ensure such evolutions do not result in typeviolation In this paper classes are defined as sets and objectsare formally described as a set of addresses in a heap

Definition 1 (class definition) A class C can be representedby a set Tf T⟶ Tprimem1113966 1113967 composed of fields and methodswhere Tf is the abbreviation of T1f1 Tnfn and T and fdenote a type and a field name respectively T⟶ Tprimem issimilar

Two auxiliary functions Sf and Sm return the field set andthe method set of a specific class C whose definitions aregiven as follows

Sf(C) empty if C empty

f1113966 1113967 if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

Sm(C) empty if C empty

m if C Tf T⟶ Tprimem1113966 1113967

⎧⎨

⎩

(1)

Definition 2 (combination class) C CL is a combination oftwo same name classes where C and CL denote a base class Cand a layered class C respectivelye combination containsall elements of C and CL Ob OL is an object of C CLwhich can be described as the two-tuple langC CL f lrang andf Sf(C)cup Sf(CL)

Definition 3 (object definition) An object is represented as atwo-tuple langC f lrang or langC CL f lrang e first element isthe type of the object and the second one is its fields andaddresses of these fields where l denotes an address

real_obj

proxy_obj

An object of a layered class

versionflag

real_obj

proxy_objversion

flag

An object of a base class

(a)

(1)

(2)o

L1 L1prime

VM

Display calendaritem

(b)

Figure 2 Object list (a) Proxy-based object structure (b) Object evolution

4 Security and Communication Networks

Based on the above definitions we formally describe fieldaccess and method invocation on objects by a computationstate A computation state can be described as the pair of anexpression and heap (e H) where an expression may be afield access lf or a method invocation lm(l) erefore thereduction relationship can be described by e H⟶ eprime Hwhich indicates that a computation state eH can be reducedto another state eprime H Furthermore ⟶lowast denotes thereflexive transitive closure of ⟶

e rule for field access (E-PROJ1 and E-PROJ2) for anobject if its address in the heapH is l its type is C or C CLand the field f has been defined then the field access can bereduced to its value

e rule for the method invocation (E-LINVKE-LINVK2 E-LINVK3 and E-CINVK) compared withfield access the method invocations are more complexsince they contain context match and object evolutioneir main ideas are (1) if the receiver of a method in-vocation is only an object of the base class C the invocationis directly reduced to its method body where parametersare replaced by arguments and this is replaced by thereceiver and (2) if the receiver of a method invocation is anobject of a combination class C CL the method in-vocation will be redirected to the same type method in alayered class CL If the layer which contains CL matches thecurrent context then the invocation can be reduced to themethod body of the method Otherwise the object has to beevolved Specifically rules for method invocation are de-scribed as follows

(i) E-INVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a base class C If the method m is resolved in Cthen the invocation is directly reduced to its methodbody where parameters x are replaced by argu-ments l and this is replaced by l

(ii) E-LINVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL and the layer containing CL matchesthe current context then the invocation can bereduced to the method body in CL where param-eters x are replaced by arguments l and this isreplaced by l

(iii) E-LINVK2 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL but the layer does not match thecurrent context and a proper layer which matchesthe current context cannot be found out or pro-vided then the invocation can be reduced to themethod body of the same type method in the baseclass C where parameters x are replaced by argu-ments l and this is replaced by l

(iv) E-LINVK3 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m is

resolved in CL but the layer does not match thecurrent and a proper layer can be found out orprovided then the object is firstly evolved by VMthat is an new object of CLprime is created and replacesthe object of CL in O and then the objectrsquos type isalso updated to C CLprime Afterwards the invocationis reduced to the method body of the same typemethod in CLprime where parameters x are replaced byarguments l and this is replaced by l

(v) E-CINVK rule for an object O represented asOb OCL its address in the heapH is l and its type isa combination class C CL If a methodm is invokedby another method in the same layer class then thecontext match is not checked and the invocation isreduced to its body where parameters x are replacedby arguments l and this is replaced by l

In the above-mentioned rules the function mbdoy ()models the semantic of themethod resolution in Java It returnsa method body of a method in a class More details about it areshown in [7 12] ldquopredicate() true IN CLrdquo represents the layer Lthatmatches the current context while ldquopredicate() false INCLrdquorepresents the layer L that does not match

e notation⟹ in the E-LINVK3 rule denotes objectevolution Object evolution may result in the type violationwhen evolved object is being accessed For example ifE-LINVK1 is interrupted after it executes for a moment thenE-LINVK3 is executed and an object l is evolved WhenE-LINVK1 is executed again the method may not exist dueto lrsquos change yielding the type violation erefore someconstraints should be proposed for object evolution so thatthe type violation can be avoided

Next we firstly formally describe object evolution andpresent some constraints on it which are shown in thefollowing definition

Definition 4 (valid object evolution) Assume that an object lis evolved to l denoted by l⟹ l since a layered class CL isreplaced by another well-formed CLprime we have H(l)

langC CL1 f lrang H(l) langC CL2 fprime lprimerang f Sf(C)capSf(CL1 )fprime Sf(C)cup Sf(CL2) Furthermore the evolution isvalid only if the following conditions hold

(1) forallm m is in stack if m isin l then m isin l

(2) forallf f isin Sf(CL) f is only accessed by m isin Sm(CL)

(3) Sm(CL1)sube Sm(CL2) and forallm m isin Sm(CL1) then mtype(m CL2)ltmtype(m CL1)

e first constraint requires that object evolution cannothave influence on running methods is ensures thesemethods still exist after object evolution avoiding runtimeerrors e second constraint ensures fields in a layered classare only accessed by methods in the class which ensuresaccessing fields do not lose after object evolution efunctionmtype [7 12] returns the type of a method in a classe third constraint requires CL2 to have the same methodsas CL1 which ensures there are no dynamic-type violationsafter objectsrsquo evolution

Security and Communication Networks 5

Based on the above definition if base classes and layerclasses are well typed the following theorem can ensure typeviolation does not occur after object evolution We denoteexpressions before and after objection evolution by e and erespectively

Theorem 1 Assume that e contains l and that l⟹ l resultsin e⟹ e if e has the property of type-safe and all layer classCL in each replacement are well typed then e has the propertyof type-safe too

e theorem intuitively indicates that if any componentof a well-typed expression e is replaced with another well-typed component then e is still well typed is is verysimilar to industrial products in the real world For exampleif a component of a qualified car is replaced with anotherqualified one then the car is still qualified

Proof We prove the theorem by induction

(1) Basic if l is unchanged then e is unchangedAccording to the assumption the theorem holds

(2) Reduction assume that e⟹ e results from l⟹ lwhich is caused by CL2 replacing CL1 If e is type-safee is type-safe

Proof by Contradiction If e has type violation caused byl⟹ l Without loss of generality assume that H(l)

langC CL1 f lrang H(l) langC CL1 fprime lprimerang

(i) If l contains a static-type violation according to thestatic-type violation definition [11] we have l f andf isin fandf notin fprime or l m(l) and m isin Sm(C)cup Sm(CL1)

andm notin Sm(C)cup Sm(CL2)

(a) Firstly if there exists l m(l) and the method m isbeing executed then according to the first con-straint of valid object evolution m is not in thestack eg l m(l) is not being executed which iscontradicted with the assumption

(b) Secondly if there exists l m(l) and m is not beinginvoked then according to the condition that e andCL are well typed only base method invocationscan be redirected to the corresponding methods oflayered classes erefore we have m isin Sm(C)which contradicts with the assumption

(c) If lprimef and f isin fandf notin fprime then f isin Sf(CL1)

andm notin Sf(CL2) According to the second con-straint of valid object evolution fields in a layeredclass only are accessed only by methods in thesame class Becausem is not in the stack the fieldf is not accessed e result is contradicted withthe assumption Finally the theorem holds

E-PROJ1 lfiH⟶ li if H(l) langC f lrang

E-PROJ2 lfiH⟶ li if H(l) langC CL f lrang

E-INVK lm(l)H⟶ [this⟼ l x⟼l]e H if H(l) langC f lrang andmbody(mC) (x e)

E-CINVK lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang andmbody mC CL( 1113857 (x e)

E-LINVK lm(l)H⟶ [this⟼ l x⟼l]e if H(l) langC CL f lrang mbody mC CL( 1113857 (x e)

predicate ( ) true INCL

E-LINVK2 lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang predicate ( ) false INCL

existCLprime predicate( )true INCLprime andm isin CandL( 1113857 mbody(mC) (x e)

E minus LINVK3 lm(l)H⟶ lm(l) l⟹langC CLprime fprime lrang1113876 1113877Hwherefprime Sf(C)cup Sf CLprime( 1113857 if H(l) langC CL f lrang

predicate ( ) false INCLexistCLprime predicate ( ) true INCLprime andm isin CLprime safe( )

(2)

(ii) If l contains a dynamic-type violation then we haveC CL1≮ C CL1 Assume that lrsquos type is C CL1and lrsquos type is C CL2 According to the third con-straint of valid object evolution and the subclass

relationship record we have C CL1 lt C CL2which is contradicted with the assumption So thedynamic-type violation is nonexistent e theoremholds

6 Security and Communication Networks

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

Based on the above definitions we formally describe fieldaccess and method invocation on objects by a computationstate A computation state can be described as the pair of anexpression and heap (e H) where an expression may be afield access lf or a method invocation lm(l) erefore thereduction relationship can be described by e H⟶ eprime Hwhich indicates that a computation state eH can be reducedto another state eprime H Furthermore ⟶lowast denotes thereflexive transitive closure of ⟶

e rule for field access (E-PROJ1 and E-PROJ2) for anobject if its address in the heapH is l its type is C or C CLand the field f has been defined then the field access can bereduced to its value

e rule for the method invocation (E-LINVKE-LINVK2 E-LINVK3 and E-CINVK) compared withfield access the method invocations are more complexsince they contain context match and object evolutioneir main ideas are (1) if the receiver of a method in-vocation is only an object of the base class C the invocationis directly reduced to its method body where parametersare replaced by arguments and this is replaced by thereceiver and (2) if the receiver of a method invocation is anobject of a combination class C CL the method in-vocation will be redirected to the same type method in alayered class CL If the layer which contains CL matches thecurrent context then the invocation can be reduced to themethod body of the method Otherwise the object has to beevolved Specifically rules for method invocation are de-scribed as follows

(i) E-INVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a base class C If the method m is resolved in Cthen the invocation is directly reduced to its methodbody where parameters x are replaced by argu-ments l and this is replaced by l

(ii) E-LINVK rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL and the layer containing CL matchesthe current context then the invocation can bereduced to the method body in CL where param-eters x are replaced by arguments l and this isreplaced by l

(iii) E-LINVK2 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m isresolved in CL but the layer does not match thecurrent context and a proper layer which matchesthe current context cannot be found out or pro-vided then the invocation can be reduced to themethod body of the same type method in the baseclass C where parameters x are replaced by argu-ments l and this is replaced by l

(iv) E-LINVK3 rule for an object O represented asOb OCL its address in the heap H is l and its typeis a combination class C CL If a method m is

resolved in CL but the layer does not match thecurrent and a proper layer can be found out orprovided then the object is firstly evolved by VMthat is an new object of CLprime is created and replacesthe object of CL in O and then the objectrsquos type isalso updated to C CLprime Afterwards the invocationis reduced to the method body of the same typemethod in CLprime where parameters x are replaced byarguments l and this is replaced by l

(v) E-CINVK rule for an object O represented asOb OCL its address in the heapH is l and its type isa combination class C CL If a methodm is invokedby another method in the same layer class then thecontext match is not checked and the invocation isreduced to its body where parameters x are replacedby arguments l and this is replaced by l

In the above-mentioned rules the function mbdoy ()models the semantic of themethod resolution in Java It returnsa method body of a method in a class More details about it areshown in [7 12] ldquopredicate() true IN CLrdquo represents the layer Lthatmatches the current context while ldquopredicate() false INCLrdquorepresents the layer L that does not match

e notation⟹ in the E-LINVK3 rule denotes objectevolution Object evolution may result in the type violationwhen evolved object is being accessed For example ifE-LINVK1 is interrupted after it executes for a moment thenE-LINVK3 is executed and an object l is evolved WhenE-LINVK1 is executed again the method may not exist dueto lrsquos change yielding the type violation erefore someconstraints should be proposed for object evolution so thatthe type violation can be avoided

Next we firstly formally describe object evolution andpresent some constraints on it which are shown in thefollowing definition

Definition 4 (valid object evolution) Assume that an object lis evolved to l denoted by l⟹ l since a layered class CL isreplaced by another well-formed CLprime we have H(l)

langC CL1 f lrang H(l) langC CL2 fprime lprimerang f Sf(C)capSf(CL1 )fprime Sf(C)cup Sf(CL2) Furthermore the evolution isvalid only if the following conditions hold

(1) forallm m is in stack if m isin l then m isin l

(2) forallf f isin Sf(CL) f is only accessed by m isin Sm(CL)

(3) Sm(CL1)sube Sm(CL2) and forallm m isin Sm(CL1) then mtype(m CL2)ltmtype(m CL1)

e first constraint requires that object evolution cannothave influence on running methods is ensures thesemethods still exist after object evolution avoiding runtimeerrors e second constraint ensures fields in a layered classare only accessed by methods in the class which ensuresaccessing fields do not lose after object evolution efunctionmtype [7 12] returns the type of a method in a classe third constraint requires CL2 to have the same methodsas CL1 which ensures there are no dynamic-type violationsafter objectsrsquo evolution

Security and Communication Networks 5

Based on the above definition if base classes and layerclasses are well typed the following theorem can ensure typeviolation does not occur after object evolution We denoteexpressions before and after objection evolution by e and erespectively

Theorem 1 Assume that e contains l and that l⟹ l resultsin e⟹ e if e has the property of type-safe and all layer classCL in each replacement are well typed then e has the propertyof type-safe too

e theorem intuitively indicates that if any componentof a well-typed expression e is replaced with another well-typed component then e is still well typed is is verysimilar to industrial products in the real world For exampleif a component of a qualified car is replaced with anotherqualified one then the car is still qualified

Proof We prove the theorem by induction

(1) Basic if l is unchanged then e is unchangedAccording to the assumption the theorem holds

(2) Reduction assume that e⟹ e results from l⟹ lwhich is caused by CL2 replacing CL1 If e is type-safee is type-safe

Proof by Contradiction If e has type violation caused byl⟹ l Without loss of generality assume that H(l)

langC CL1 f lrang H(l) langC CL1 fprime lprimerang

(i) If l contains a static-type violation according to thestatic-type violation definition [11] we have l f andf isin fandf notin fprime or l m(l) and m isin Sm(C)cup Sm(CL1)

andm notin Sm(C)cup Sm(CL2)

(a) Firstly if there exists l m(l) and the method m isbeing executed then according to the first con-straint of valid object evolution m is not in thestack eg l m(l) is not being executed which iscontradicted with the assumption

(b) Secondly if there exists l m(l) and m is not beinginvoked then according to the condition that e andCL are well typed only base method invocationscan be redirected to the corresponding methods oflayered classes erefore we have m isin Sm(C)which contradicts with the assumption

(c) If lprimef and f isin fandf notin fprime then f isin Sf(CL1)

andm notin Sf(CL2) According to the second con-straint of valid object evolution fields in a layeredclass only are accessed only by methods in thesame class Becausem is not in the stack the fieldf is not accessed e result is contradicted withthe assumption Finally the theorem holds

E-PROJ1 lfiH⟶ li if H(l) langC f lrang

E-PROJ2 lfiH⟶ li if H(l) langC CL f lrang

E-INVK lm(l)H⟶ [this⟼ l x⟼l]e H if H(l) langC f lrang andmbody(mC) (x e)

E-CINVK lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang andmbody mC CL( 1113857 (x e)

E-LINVK lm(l)H⟶ [this⟼ l x⟼l]e if H(l) langC CL f lrang mbody mC CL( 1113857 (x e)

predicate ( ) true INCL

E-LINVK2 lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang predicate ( ) false INCL

existCLprime predicate( )true INCLprime andm isin CandL( 1113857 mbody(mC) (x e)

E minus LINVK3 lm(l)H⟶ lm(l) l⟹langC CLprime fprime lrang1113876 1113877Hwherefprime Sf(C)cup Sf CLprime( 1113857 if H(l) langC CL f lrang

predicate ( ) false INCLexistCLprime predicate ( ) true INCLprime andm isin CLprime safe( )

(2)

(ii) If l contains a dynamic-type violation then we haveC CL1≮ C CL1 Assume that lrsquos type is C CL1and lrsquos type is C CL2 According to the third con-straint of valid object evolution and the subclass

relationship record we have C CL1 lt C CL2which is contradicted with the assumption So thedynamic-type violation is nonexistent e theoremholds

6 Security and Communication Networks

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

Based on the above definition if base classes and layerclasses are well typed the following theorem can ensure typeviolation does not occur after object evolution We denoteexpressions before and after objection evolution by e and erespectively

Theorem 1 Assume that e contains l and that l⟹ l resultsin e⟹ e if e has the property of type-safe and all layer classCL in each replacement are well typed then e has the propertyof type-safe too

e theorem intuitively indicates that if any componentof a well-typed expression e is replaced with another well-typed component then e is still well typed is is verysimilar to industrial products in the real world For exampleif a component of a qualified car is replaced with anotherqualified one then the car is still qualified

Proof We prove the theorem by induction

(1) Basic if l is unchanged then e is unchangedAccording to the assumption the theorem holds

(2) Reduction assume that e⟹ e results from l⟹ lwhich is caused by CL2 replacing CL1 If e is type-safee is type-safe

Proof by Contradiction If e has type violation caused byl⟹ l Without loss of generality assume that H(l)

langC CL1 f lrang H(l) langC CL1 fprime lprimerang

(i) If l contains a static-type violation according to thestatic-type violation definition [11] we have l f andf isin fandf notin fprime or l m(l) and m isin Sm(C)cup Sm(CL1)

andm notin Sm(C)cup Sm(CL2)

(a) Firstly if there exists l m(l) and the method m isbeing executed then according to the first con-straint of valid object evolution m is not in thestack eg l m(l) is not being executed which iscontradicted with the assumption

(b) Secondly if there exists l m(l) and m is not beinginvoked then according to the condition that e andCL are well typed only base method invocationscan be redirected to the corresponding methods oflayered classes erefore we have m isin Sm(C)which contradicts with the assumption

(c) If lprimef and f isin fandf notin fprime then f isin Sf(CL1)

andm notin Sf(CL2) According to the second con-straint of valid object evolution fields in a layeredclass only are accessed only by methods in thesame class Becausem is not in the stack the fieldf is not accessed e result is contradicted withthe assumption Finally the theorem holds

E-PROJ1 lfiH⟶ li if H(l) langC f lrang

E-PROJ2 lfiH⟶ li if H(l) langC CL f lrang

E-INVK lm(l)H⟶ [this⟼ l x⟼l]e H if H(l) langC f lrang andmbody(mC) (x e)

E-CINVK lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang andmbody mC CL( 1113857 (x e)

E-LINVK lm(l)H⟶ [this⟼ l x⟼l]e if H(l) langC CL f lrang mbody mC CL( 1113857 (x e)

predicate ( ) true INCL

E-LINVK2 lm(l)H⟶ [this⟼ l x⟼l]eH if H(l) langC CL f lrang predicate ( ) false INCL

existCLprime predicate( )true INCLprime andm isin CandL( 1113857 mbody(mC) (x e)

E minus LINVK3 lm(l)H⟶ lm(l) l⟹langC CLprime fprime lrang1113876 1113877Hwherefprime Sf(C)cup Sf CLprime( 1113857 if H(l) langC CL f lrang

predicate ( ) false INCLexistCLprime predicate ( ) true INCLprime andm isin CLprime safe( )

(2)

(ii) If l contains a dynamic-type violation then we haveC CL1≮ C CL1 Assume that lrsquos type is C CL1and lrsquos type is C CL2 According to the third con-straint of valid object evolution and the subclass

relationship record we have C CL1 lt C CL2which is contradicted with the assumption So thedynamic-type violation is nonexistent e theoremholds

6 Security and Communication Networks

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

5 Implementation and Evaluation

In this section we briefly describe how to extend a Javavirtual machine to implement runtime object evolution aVM-centric approach

51 Implementation JamVM is a compact Java virtualmachine (JVM) which conforms to JVM specification ver-sion 2 In comparison to most other VMs JamVM is ex-tremely small hence it is easier for us to extend In order toimplement object evolution we mainly extend JamVMrsquosclass loader interpreter resolution and memory allocation

JamVM represents objects with the structure object Inorder to support object evolution based on object proxy weadded two pointers real_obj and proxt_obj into the struc-ture e extended structure is shown in Figure 2(a) Eachtime an object is created these pointers are initialized to nullAt runtime they are used to create a double-linked objectlist a runtime object Furthermore a variable of integer typeflag is added into the structure If its value is zero VM doesnot check whether or not a layer matches the currentcontext Otherwise the check is executed

In our approach objects are lazily evolved As men-tioned above in Section 3 lazy evolution is implemented bycomparisons of version numbers of a class and an objecterefore we also added a variable of integer type versioninto the object and classblock which is a structure to rep-resent as loaded classes Afterwards we extend the classloader so that version may correctly initialize each time aclass is loaded In general each time a base class is loaded itsversionrsquos value is initialized with 0 Each time a layered classis loaded or removed due to a layer replacement its versionrsquosvalue is increased by 1 On the other hand each time alayered class is loaded its versionrsquos value is initialized withthat of a base class with the same name We also extend thenew instruction so that when an object is created its ver-sionrsquos value is initialized with the versionrsquos value of its class

e interpreter is responsible for dealing with methodinvocation e normal execution process of method in-vocation is illustrated in the left of Figure 3 Each timedealing with an instruction for method invocation theresolution module firstly resolves the invoked method andthen the execution module executes the resolved methodHowever if the receiver is an object list the process shouldbe changed as shown in Figure 3 Particularly a comparemodule and evolution module is added into method in-vocation process

We extend semantics three instructions in the in-terpreter module of JamVM to achieve the changee threeinstructions are invokevirtual invokespecial and invoke-static respectively which are responsible for doing withmethod invocations in different conditions

(i) If proxy_obj and real_obj of the receiver of theinvocation are null the receiver is only an object of abase class Firstly version numbers of the object andits class are compared If equal the method reso-lution just looks for the invoked method in thebased class and executes its body is is consistent

with the semantic of E-INVK Otherwise the objectis evolved If not equal VM evolves the object Ifevolution succeeds context match is checked If itmatches then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

(ii) For the receiver if its proxy_obj is null but itsreal_obj is not null which means that the receiver isan object list containing at least two objects themethod invocation occurs on the first object of thelist an object of a base class In this case versionnumbers of the first object in the list and its classneed to be compared If they are not equal thereceiver is evolved by VM If the evolution succeedsand context match is checked then the resolutionmodule looks for its method body in real_obj andexecutes it Otherwise the module looks for itsmethod body in the object and executes it

(iii) For the receiver if its a proxy_obj the methodinvocation occurs on an object of layered class Inthis case version numbers of the first object in thelist and its class need to be compared If they are notequal the receiver is evolved by VM If the evolutionsucceeds then the resolution module looks for itsmethod body in real_obj and executes it Otherwisethe module looks for its method body in the objectand executes it

For object evolution by triggering layer replacement theinterpreter searches a specific directory to look for a properlayer which holds the following conditions

(i) Matches the current context(ii) Contains a layer class which has the same type

method with the current invoked method

Once VMfinds out a proper layer layered classes in it areloaded and new objects are created to evolve the receiver ofthe current method invocation

In this section our implementation proves that ourapproach is feasible In the future work we plan to supportobject evolution in a multithread context

52 Evaluation In this section we discuss our runtimemeasurements For illustration purposes methods in classesand layers are called as plain methods and layered methodsrespectively We set up micromeasurements to assess theperformance of the execution of the layered method Ourmeasurements were all run on 22GHz Intel Core2Duo with3GB of RAM running Ubuntu 1004 LTS

Java Grande benchmark framework [14] contains allkinds of method invocations and object creations and accessin Java to evaluate performance of a Java VM for exampleclassinstance method invocations and classinstance objectcreations To evaluate our approach we add at least twolayers for each kind of method invocations and objectcreations and access in Java Grande benchmark frameworkrespectively One of the two layers fits the current execution

Security and Communication Networks 7

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

environment while the others do not fit On the other handboth JamVM and our extension to JamVM run on Ubuntu1004 LTS operation system with Java 16 version

Based on our experiment environment we first evaluatethe performance of the execution of the layered method andthen compare the execution performance of method in-vocations on an extension to JamVM and on standardJamVM e benchmark includes synchronized and non-synchronized plain instance methods that calculate thepower of a given number e main method in thebenchmark contains four types of plain method calls syn-chronized and nonsynchronized instance methods and callsto synchronized and nonsynchronized class methods Eachtype of method call is executed 109 times

521 Performance of Layer Replacement Based on ObjectEvolution After 17 times execution of benchmark the re-sults are shown in Figure 4 e results show that the layerreplacement efficiency caused by class method invocation is468ms e layer replacement efficiency caused by instancemethod invocation is 414ms e difference between thetwo efficiencies are caused by the following reasons Firstlyclass method invocation has nothing to do with objectevolution hence new object creations and object list con-stitutions are unnecessary Moreover compared to thesynchronized method the influence of an asynchronizedmethod on the layer replacement is smaller e reason isbecause execution of unlocking the asynchronized methodneeds more time

522 Performance of Method Call Based on Object Evolutione layer replacement based on object evolution is imple-mented by the extension of a virtual machine which couldimpact the execution performance of method invocations onobjects In order to evaluate the influence we compare theexecution performance of method invocations on thestandard JamVM and its extension by running benchmark17 times on them respectively

e experiment results are shown in Figure 5e resultsshow that the execution performance of method invocation

on the extended virtual machine is from 6 to 10 lowerthan that on the standard JamVM Particularly the exe-cution performance of instance method invocations on theextension is close to 90 of that on standard JamVM eexecution performance of synchronization class methodinvocations on the extension is close to 94 of that onstandard JamVM e main reason for the low performanceis that the extension JamVM has to check whether or not thereceiver of a method invocation contains objects of layeredclasses Furthermore it needs to check whether or not theinvoked method matches the current context

53 Discussion Our approach supports layer replacementby extending object represented in Java VM and semantics ofmethod resolution which gives rise to overhead In spacecomplexity an object in our approach may cost extra tens ofbytes because it contains an object list In time complexity asmentioned above in Implementation section our approachusually does two extra operationse first one is to locate anobject in an object list and the second one is to execute thefitness method ey are the root cause to overhead whichranges from 6 to 10 in our experiment In the future weintend to introduce a cache mechanism to reduce an objectin size and avoid fitness method execution as soon aspossible

6 Conclusion

Healthcare applications have to run on various medicaldevices which have their own particular contexts ese

Resolution

Execution

Interpret

Instruction

Proxy_objnullReal_objnull

Resolution

Execution

Y

N

Compare

The fi

rst o

bjec

t

Evolution

Y

Fitness

YN

N

Figure 3 Method execution process

360

380

400

420

440

460

480

Instancemethod

Synchronizedinstance method

Class method Synchronizedclass method

Laye

r rep

lace

men

t cou

nt p

erm

illise

cond

Method invocation types

Figure 4 Layer replacement performance

0

500

1000

1500

2000

2500

3000

Instancemethod

Class method Synchronizedinstance method

Synchronizedclass method

Calls

per

mill

iseco

nd

Method invocation types

Standard JamVMExtended JamVM

Figure 5 Method execution performance

8 Security and Communication Networks

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

contexts crosscut healthcare applicationsrsquo codes makingthem more scattered and tangled and increasing costs oftheir development and maintenance Some COP languagesaddress crosscut concern however they have some deficitsthat new layers cannot be loaded at runtime to replace layerswhich no longer match the current context

In this paper we propose a new approach to supportcontext-based dynamic behavior adjustment of applicationsUnlike existing COP languages our approach uses objectproxy in the VM level to support layer activation and de-activation Furthermore as our approach is based on VM itmore easily leverages VM to dynamically replace layers sothat applications can better adapt new context In order toverify our approach we first formally describe it and proveit ensuring type-safety properties of applications only ifsome constraints are held Finally we present how to im-plement our approach by extending Java VM

Data Availability

e experiment platform (ie extended JamVM) and resultsused to support the findings of this study have been de-posited in httpsgithubcomzcpjvm_extensiongit andthey are available from the corresponding author uponrequest

Conflicts of Interest

e authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

is research was supported in part by a grant from NSFCunder Grant nos 61571286 and 61640219

References

[1] G J Joyia R M Liaqat A Farooq and S Rehman ldquoInternetof medical things (IOMT) applications benefits and futurechallenges in healthcare domainrdquo Journal of Communica-tions vol 12 no 4 pp 240ndash247 2017

[2] H Turabieh A Abu Salem and N Abu-El-Rub ldquoDynamicL-RNN recovery of missing data in IoMT applicationsrdquoFuture Generation Computer Systems vol 89 pp 575ndash5832018

[3] A M Elmisery M Sertovic and B B Gupta ldquoCognitiveprivacy middleware for deep learning mashup in environ-mental Ioxrdquo IEEE Access vol 6 pp 8029ndash8041 2018

[4] P Geiger M Schickler R Pryss J Schobel and M ReichertldquoLocation-based mobile augmented reality applicationschallenges examples lessons learnedrdquo in Proceedings of the10th International Conference on Web Information Systemsand Technologies (WEBIST 2014) pp 383ndash394 Special Ses-sion on Business Apps Barcelona Spain April 2014

[5] M Appeltauer R Hirschfeld H Masuhara M Haupt andK Kawauchi ldquoEvent-specific software composition in con-text-oriented programmingrdquo in Software Compositionpp 50ndash65 Springer Berlin Germany 2010

[6] T Kamina T Aotani and H Masuhara ldquoEventCJ a context-oriented programming language with declarative event-basedcontext transitionrdquo in Proceedings of the Tenth International

Conference on Aspect-Oriented Software DevelopmentmdashAOSDrsquo11Porto de Galinhas Brazil March 2011

[7] C Zhu Y Zhao B Han Q Zeng and Y Ma ldquoRuntimesupport for type-safe and context-based behavior adaptationrdquoFrontiers of Computer Science vol 8 no 1 pp 17ndash32 2014

[8] MMadsen R Zarifi and O Lhotak ldquoTail call elimination anddata representation for functional languages on the javavirtual machinerdquo in Proceedings of the 27th InternationalConference on Compiler ConstructionmdashCC 2018 pp 139ndash150ACM New York NY USA 2018

[9] S Papadimitriou Scientific Computing with ScalaLab at theJava Platform Scholars Press Riga Latvia 2017

[10] T Cohen and J Y Gil ldquoree approaches to object evolu-tionrdquo in Proceedings of the 7th International Conference onPrinciples and Practice of Programming in JavandashPPPJrsquo09pp 57ndash66 ACM New York NY USA 2009

[11] S Malabarba R Pandey J Gragg E Barr and J F BarnesldquoRuntime support for type-safe dynamic java classesrdquo inProceedings of the European Conference on Object-OrientedProgrammingmdashECOOPrsquo00 pp 337ndash361 Sophia Antipolisand Cannes France June 2000

[12] Y-L Zhao C-P Zhu B Han and Q-H Zeng ldquoA calculususing fitness testing for method redirectionrdquo Journal ofSoftware vol 24 no 7 pp 1495ndash1511 2014

[13] J J P C Rodrigues D B De Rezende SegundoH A Junqueira et al ldquoEnabling technologies for the internetof health thingsrdquo IEEE Access vol 6 pp 13129ndash13141 2018

[14] K Ullah M A Shah and S Zhang ldquoEffective ways to useinternet of things in the field of medical and smart healthcarerdquo in Proceedings of the 2016 International Conference onIntelligent Systems Engineering (ICISE) pp 372ndash379 Islam-abad Pakistan January 2016

[15] J L Kernec F Fioranelli S Yang J Lorandel and O RomainldquoRadar for assisted living in the context of internet of thingsfor health and beyondrdquo in Proceedings of the IFIPIEEE In-ternational Conference on Very Large Scale Integration (VLSI-SoC) pp 163ndash167 Verona Italy October 2018

[16] L Haoyu L Jianxing N Arunkumar A F Hussein andM M Jaber ldquoAn IoMT cloud-based real time sleep apneadetection scheme by using the SpO2 estimation supported byheart rate variabilityrdquo Future Generation Computer Systemsvol 98 pp 69ndash77 2019

[17] L Bettini V Bono and B Venneri ldquoDelegation by objectcompositionrdquo Science of Computer Programming vol 76no 11 pp 992ndash1014 2011

[18] L Baresi C Ghezzi X Ma and V P L Manna ldquoEfficientdynamic updates of distributed components through versionconsistencyrdquo IEEE Transactions on Software Engineeringvol 43 no 4 pp 340ndash358 2017

[19] Y Zhao ldquoGranule-oriented programmingrdquo ACM SIGPLANNotices vol 39 no 12 pp 107ndash118 2004

[20] C Quinton R Rabiser M Vierhauser P Grunbacher andL Baresi ldquoEvolution in dynamic software product lineschallenges and perspectivesrdquo in Proceedings of the 19th In-ternational Conference on Software Product LinendashSPLCrsquo15pp 126ndash130 ACM New York NY USA 2015

[21] R Hirschfeld A Igarashi and H Masuhara ldquoContextFJ Aminimal core calculus for context-oriented programmingrdquo inProceedings of the Foundations of Aspect-Oriented LanguagesFOAL pp 19ndash23 Porto de Galinhas Brazil March 2011

Security and Communication Networks 9

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom