1

00:00:00,990  -->  00:00:08,160
In the last lesson we discussed glassblowing which is a first page in the lifetime offered by a class

2

00:00:08,250  -->  00:00:14,010
or an interface on gender's the corresponding class object which is the input to the next page which

3

00:00:14,010  -->  00:00:22,590
is linking not it's get an in-depth understanding of the linking process linking is the most complicated

4

00:00:22,680  -->  00:00:25,270
of the three stages of the LifeGem effect.

5

00:00:25,800  -->  00:00:31,490
And as we discussed earlier it includes three steps verification preparation and the optional resolution

6

00:00:31,500  -->  00:00:32,390
step.

7

00:00:32,520  -->  00:00:40,260
And let's begin with the verification step the verification step verifies that the Nordic class is not

8

00:00:40,260  -->  00:00:41,040
malformed.

9

00:00:41,400  -->  00:00:48,180
That is it conforms to the Java language to us and this is needed as the class file might have been

10

00:00:48,190  -->  00:00:54,360
lorded from across the network or it could be a user defined class from the local file system itself

11

00:00:54,360  -->  00:00:55,080
.

12

00:00:55,110  -->  00:01:01,190
In either case JVM does not trust those classes as they come from less trustworthy resources.

13

00:01:01,200  -->  00:01:07,650
As we discussed earlier there is there could have been generated by a hostile compiler whose intention

14

00:01:07,740  -->  00:01:14,220
is to perform some malicious actions to Gibeon subjects them through some stringent security checks

15

00:01:14,460  -->  00:01:20,900
through the verification process under the same verification is already done during compilation.

16

00:01:21,210  -->  00:01:28,560
Generally speaking user defined classes are mostly well-formed process but GBM has to stick to its process

17

00:01:28,560  -->  00:01:29,660
.

18

00:01:29,660  -->  00:01:34,730
We know that the classes from Java library are not very fight as they're considered trustworthy and

19

00:01:34,820  -->  00:01:42,300
recall that they are looked at by the bootstrap classloader bytecode verification is done by the component

20

00:01:42,360  -->  00:01:43,040
bytecode.

21

00:01:44,370  -->  00:01:50,310
Once the code is successfully verified by the bytecode welfare only then the code is considered safe

22

00:01:50,310  -->  00:01:54,110
to be run by JVM on it with a log it's execution engine.

23

00:01:54,210  -->  00:02:00,140
The poor form at optimum level as it doesn't have to perform any further security checks.

24

00:02:00,390  -->  00:02:06,780
But if it finds a problem it rejects the malformed class and throws an exception on hit.

25

00:02:06,780  -->  00:02:14,420
For example verification checks that bytecode that performs final process must not be subclassed right

26

00:02:14,480  -->  00:02:14,980
.

27

00:02:15,200  -->  00:02:22,980
Final methods must not be overridden under must not be any illegal method overloading and the final

28

00:02:22,980  -->  00:02:25,380
one ensures that statements like.

29

00:02:25,410  -->  00:02:33,960
If condition does not send the control beyond the methods Bhandari So that's verification nextstep is

30

00:02:33,960  -->  00:02:36,690
preparation and Ixtoc is pretty straightforward.

31

00:02:36,940  -->  00:02:41,430
I look at space post Arctic fields and initialize them with default values.

32

00:02:41,430  -->  00:02:46,570
If there isn't enough memory then an out of memory error will be generated.

33

00:02:46,590  -->  00:02:52,410
Not that if the class is loaded because an instance of it is created then space will be a look at it

34

00:02:52,410  -->  00:02:52,430
.

35

00:02:52,440  -->  00:02:57,630
For instance fields also and they would also be initialized the default values.

36

00:02:58,050  -->  00:03:03,900
However this would be done only after all stocktake fields are initialized properly with the actual

37

00:03:03,900  -->  00:03:06,010
user defined values.

38

00:03:06,260  -->  00:03:09,480
And this happens across the class hierarchy.

39

00:03:09,480  -->  00:03:16,530
We know that super classes will be loaded before the subclasses so all the stocktake fields across the

40

00:03:16,530  -->  00:03:23,730
class hierarchy will be initialized before the instance fields are initialized.

41

00:03:23,730  -->  00:03:30,120
Next is the last step which is resolution and we know that it is an optional step that is it need not

42

00:03:30,120  -->  00:03:36,850
strictly happen after Operation step on it can be performed later after initialization stage.

43

00:03:36,930  -->  00:03:42,280
Now in the current class we typically reference fields on methods from other classes and also interfaces

44

00:03:42,310  -->  00:03:42,630
.

45

00:03:42,960  -->  00:03:46,560
So this step is about resolving those references.

46

00:03:46,620  -->  00:03:50,410
That is to load them so that the current class can use them.

47

00:03:50,430  -->  00:03:57,330
No such references are referred to as symbolic references and symbolic references are nothing but logical

48

00:03:57,330  -->  00:04:04,590
references or symbolic references are stored in one area of the doc class file called Constant bullet

49

00:04:04,600  -->  00:04:05,140
.

50

00:04:05,640  -->  00:04:06,380
If you recall.

51

00:04:06,420  -->  00:04:14,550
We looked at constant pool in a demo we did in the method binding lesson did we used the jalopy disassembler

52

00:04:14,550  -->  00:04:20,600
tool to examine the bytecode and we actually looked at the contents of constant Gwinn.

53

00:04:20,880  -->  00:04:24,780
So you can go back and review that video if needed.

54

00:04:24,780  -->  00:04:31,380
Note that apart from symbolic references constant as its name suggests can also include constants such

55

00:04:31,410  -->  00:04:37,230
as compile time constants and stringless in the resolution step.

56

00:04:37,230  -->  00:04:43,050
The referenced classes are loaded into memory and once they are loaded into memory their corresponding

57

00:04:43,050  -->  00:04:50,130
symbolic references to the current class will be replaced with direct references to their actual locations

58

00:04:50,130  -->  00:04:56,960
in the memory so that support resolution is about this look at an example here.

59

00:04:57,120  -->  00:04:59,240
Here the box at the top has the source code.

60

00:04:59,310  -->  00:05:03,970
Well the one at bottom shows the corresponding byte order in the source code.

61

00:05:03,990  -->  00:05:09,870
We have a single statement creating the whole object and in the bytecode we can see the corresponding

62

00:05:09,870  -->  00:05:16,490
bytecode instruction and it is referencing an entry in the constant pull and constant pull.

63

00:05:16,500  -->  00:05:22,850
It's like an army and has entries that can be accessed by some in mixed numbers.

64

00:05:22,920  -->  00:05:30,090
So what is the object creation instruction is referencing the entry at the index number two within the

65

00:05:30,090  -->  00:05:38,190
constant pull on this entry is interned affronting the create index number 19 which basically is a symbolic

66

00:05:38,190  -->  00:05:41,270
reference not at runtime.

67

00:05:41,340  -->  00:05:48,060
GBM creates an internal notion of this constant which is referred to as a runtime constant.

68

00:05:48,480  -->  00:05:54,540
And then the resolution step the component doing resolution would look at the symbolic reference within

69

00:05:54,560  -->  00:05:59,770
Tintern time constant ball and would then load the class handle that is class.

70

00:05:59,790  -->  00:06:06,620
Hello would be taken through all three stages of the lifetime off it would be stored on the heap.

71

00:06:06,750  -->  00:06:12,210
The symbolic reference will now be replaced with a direct reference to that hello instance on the heap

72

00:06:12,210  -->  00:06:12,830
.

73

00:06:13,440  -->  00:06:19,740
And this form of the solution is known as dynamic linking as linking is being done at runtime in certain

74

00:06:19,740  -->  00:06:22,520
languages such linking is done at compile time itself.

75

00:06:22,620  -->  00:06:29,510
And does it refer to start acting uninstructed linking the contents of the reference file or copied

76

00:06:29,510  -->  00:06:32,750
into the final executable.

77

00:06:32,750  -->  00:06:39,170
No advantage of dynamic linking is that you can make easy objects that is replace a class file with

78

00:06:39,170  -->  00:06:41,950
a more newer updated class.

79

00:06:42,420  -->  00:06:47,660
However the software would also cease to work if updates are incompatible.

80

00:06:48,030  -->  00:06:55,800
For instance in the new class file it previously available method might be missing on the class might

81

00:06:55,800  -->  00:07:00,740
be referencing that method and that JVM would generate an error.

82

00:07:01,230  -->  00:07:06,530
Note that this resolution of symbolic references in the current class happens only once.

83

00:07:06,650  -->  00:07:13,050
There is a symbolic reference maybe a reference from multiple locations within the same class but that

84

00:07:13,050  -->  00:07:15,800
reference would be resolved only once.

85

00:07:15,810  -->  00:07:21,930
So if Hello instance is created at multiple locations in the same class then it is resolved only once

86

00:07:22,350  -->  00:07:27,770
and thereafter the direct reference is used not dynamic linking.

87

00:07:27,770  -->  00:07:31,850
Can happen in two ways depending on the JVM implementation.

88

00:07:31,880  -->  00:07:35,850
It can be either to be either loading or we are lazy loading.

89

00:07:36,060  -->  00:07:42,080
If it is either loading then it means that resolution happens right after the operation step.

90

00:07:42,330  -->  00:07:48,690
That is all classes are referenced by the current class will also be loaded which means that they get

91

00:07:48,690  -->  00:07:53,410
loaded on initialized before the current class is itself initialized.

92

00:07:53,790  -->  00:07:55,690
So they are loaded upfront.

93

00:07:55,980  -->  00:07:58,270
That is they are eagerly loaded.

94

00:07:58,490  -->  00:08:04,770
If it is lazy loading then it means resolution is postponed to a later time after the next stage which

95

00:08:04,760  -->  00:08:09,350
is initialization to be more precise when missing a later time.

96

00:08:09,360  -->  00:08:16,070
It implies to the time when the statement that includes the reference is actually executed so at that

97

00:08:16,080  -->  00:08:22,290
point the reference is loaded on demand and the symbolic reference is replaced with the direct reference

98

00:08:22,290  -->  00:08:23,570
.

99

00:08:23,700  -->  00:08:30,590
Typically DBMS implement lazy loading and that's because you don't have to load a class until you're

100

00:08:30,650  -->  00:08:32,120
really needed.

101

00:08:32,120  -->  00:08:38,150
Sometimes certain statements may never get executed and so there is no point loading the references

102

00:08:38,310  -->  00:08:41,720
appearing in those statements.

103

00:08:41,730  -->  00:08:48,900
Finally just note that when resolving differences resolution also ensures that the current class has

104

00:08:48,890  -->  00:08:54,580
permission to access the reference to class a what with regards to freezing other classes.

105

00:08:54,770  -->  00:09:01,750
Resolution ensures that the fields exist in those classes under how to the a type also under current

106

00:09:01,760  -->  00:09:02,340
class.

107

00:09:02,350  -->  00:09:09,470
Once again has the permission to access them as you can see these paths are pretty fiction related and

108

00:09:09,570  -->  00:09:13,600
so resolution does form some form of verification.

109

00:09:13,940  -->  00:09:15,730
So that's about linking.

110

00:09:15,780  -->  00:09:17,770
So once the classes form would be safe.

111

00:09:17,900  -->  00:09:23,280
Next stage would be initialization after which JVM can freely executed.

112

00:09:23,660  -->  00:09:28,350
As discussed earlier initialization step simply initialize a static field.

113

00:09:28,640  -->  00:09:31,520
But the actual user defined initial values.

114

00:09:31,880  -->  00:09:35,310
Earlier they were initialized with different values.

115

00:09:35,390  -->  00:09:40,810
If you recall one thing note about initialization was with regards to interfaces.

116

00:09:40,940  -->  00:09:47,970
Interfaces will be initialized only if one of its documents is accessed or one off its fields.

117

00:09:48,030  -->  00:09:51,510
That is a non compile time constant is accessed.

118

00:09:51,750  -->  00:09:59,260
That is a field is initialized via a method or a constructor under is initialization and so we will

119

00:09:59,260  -->  00:10:01,610
not be discussing it any more.

120

00:10:01,830  -->  00:10:03,040
So that's about it.

121

00:10:03,090  -->  00:10:05,790
Next we will be a demo of the lifetime effect.

122

00:10:06,240  -->  00:10:06,660
Thank you