The machine execJavaC of execJava extends the machine execJavaI by the rules which de_ne the semantics of the new JavaC-expressions and JavaCstatements.
Therefore like execJavaI it consists of two submachines, for expression evaluation and statement execution, which are de_ned below.
For the initial state of JavaC we assume that the environment of the respective lookup functions and predicates is de_ned by the given program which consists of a list of classes and interfaces. All class _elds of all classes are set to their default or constant values. The run of JavaC starts with meth being the class method
which is supposed to be part of the environment; pos denotes the _rst position of the body of main which de_nes restbody, locals is unde_ned (because main is invoked without parameters). The run terminates, if no rule of JavaC can be applied any more.
The machine execJavaExpC is de_ned in Fig.below. We _rst look at its e_ect for expressions belonging to initialized classes. In this case the evaluation of class _elds is de_ned similarly to the evaluation of local variables in execJavaExpI , but using the memory function globals instead of locals. The value of a class _eld access is the value bound under the name of the class and of the _eld in the global environment [18, x15.10]. To execute a class _eld assignment is to compute the value of its right-hand side [18, x15.25], followed by binding it as new value to the class and _eld name in the global environment. When a class method is called [18, x15.11], exec JavaExpC triggers the evaluation of the actual arguments of the invocation, respecting the left-to-right strategy; their values are then bound by invokeMethod (see below) to the parameters of the method, to start the execution of the called method and at the same time preparing the return to up(pos) in the calling method.
Now we explain the class initialization mechanism in execJavaExpC . The program execution starts in a state in which no class or interface is initialized (except for Object). The initialization is required to be done at the _rst active use of any class or interface C, namely by executing its static initializer. The _rst active use
of C can occur in the following situations:
Execution of JavaC expressions
A primitive constant is a _eld that is both static and final, and that is initialized with a compile-time constant expression. A constant expression is built up from literals and other primitive constants using unary and binary operators. Primitive constants are replaced in the source code, at compiletime, by the corresponding literals with the same value (so called inlining of primitive constants).
Before a class is initialized, its superclasses must be initialized. As a consequence, when execJavaExpC accesses _elds, or assigns to _elds, or calls methods, as _rst active use of a not yet initialized class C, it invokes the class initializer of C which is described by the following rule initialize(C).
This rule records that starting from now, the initialization of class C is InProgress. All static _elds (staticFields) of the class are initialized with their default value. Through the macro invokeMethod de_ned below, the rule pushes the current computation state on the frame stack, with unchanged pos (since after the initialization the computation has to proceed where the initialization was started) and without parameters (since class initialization methods have no arguments), and it transfers the control to the _rst position of the body of the static initialization code (where _rstPos can be considered as a system constant).
The statement execution submachine execJavaStmC of execJavaC , de- _ned in Fig.below, starts the execution of static initialization blocks|unless the current class has a superclass which is not yet initialized, in which case execJavaStmC invokes the initialization of that superclass. When a static block of class C is executed, accesses to the _elds of C and invocations of methods of C should not trigger a new _rst use of C. This is the reason why InProgress is included in the de_nition of the predicate initialized.
When returning from a method, in case an expression is returned, the submachine execJavaStmC _rst transfers the control to the expression evaluation submachine execJavaExpC ; in case no expression is returned, or after the value val of the returned expression has been computed, the computation abrupts, with the possible return value encoded into the reason Return(val ) for abruption, and the current method has to be exited. In the extension execJavaE of execJavaC , this method exit will be subject to prior execution of so called _nally code, which may be present in the current method.
Therefore, instead of transferring the control from a return statement directly to the invoker, we let execJavaStmC propagate the return abruption up to the starting point _rstPos of the current method body, from where the method will be exited. However, the return from a class initialization method has to be excluded from
this propagation. Therefore we re_ne the predicate propagatesAbr from execJavaI in execJavaC as follows:propagatesAbr(phrase) = phrase 6= lab : s ^ phrase 6=static s
In execJavaE propagatesAbr will be further re_ned to take also _nally code into account. The rule invokeMethod, which is used in Fig. below, pushes the current frame, with the position given as parameter, on the frame stack and creates a new current frame to start executing the body of the invoked method. The argument values are bound to the formal parameters of the method in the new local environment. We use the submachine invokeNative which describes the invocation of native methods. The function modi_ers returns the method modi_ers (Native; Public; : : :), as speci_ed in the
Upon return from the execution of a method, the rule exitMethod(result) passes control back to the current position of the invoker, reestablishes the
Execution of JavaC statements
method and local variables of the invoker and replaces in its restbody the method invocation statement by the result of the invoked method (i.e., the value to be returned if there is one or the information on normal completion of the method body)|except for the normal return from a class initialization whereupon the execution proceeds with the previous restbody and the class state is updated to Initialized.
JVM Related Interview Questions
|Java Script Interview Questions||Adv Java Interview Questions|
|Core Java Interview Questions||AJAX Interview Questions|
|Android Interview Questions||Java applet Interview Questions|
|Java 8 Interview Questions||JBOSS Interview Questions|
|Advanced jQuery Interview Questions||Apache Tomcat Interview Questions|
|Application Virtualization Interview Questions||Java 9 Interview Questions|
The Imperative Core Javai Of Java
The Procedural Extension Javac Of Javai
The Object-oriented Extension Javao Of Javac
The Exception-handling Extension Javae Of Javao
The Concurrent Extension Javat Of Javae
Java Is Type Safe
The Jvmi Submachine
The Procedural Extension Jvmc Of Jvmi
The Object-oriented Extension Jvmo Of Jvmc
The Exception-handling Extension Jvme Of Jvmo
Correctness Of The Compiler
The Defensive Virtual Machine
Bytecode Type Assignments
The Diligent Virtual Machine
The Dynamic Virtual Machine
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.