search
Log In
37 votes
6.1k views

Which of the following is NOT an advantage of using shared, dynamically linked libraries as opposed to using statistically linked libraries?

  1. Smaller sizes of executable files

  2. Lesser overall page fault rate in the system

  3. Faster program startup

  4. Existing programs need not be re-linked to take advantage of newer versions of libraries

in Compiler Design 6.1k views
0
and what about the draw back of static linked libraries
1

@jatin khachane 1 "overall" page fault rate is said. Even if there is page fault by one module, that shared lib will be brought into main memory and then no other module will cause page fault because of it. So yes option b is an advantage.

1

@tusharp 

@Shubhgupta

Other advantages of shared libraries are as follows

:Load time might be reduced because the shared library code might already be in memory.

as given in above link

So faster program startup should be an advantage of DLL right?

​​

0
yes
0

i found dynamic loading and dynamic linking videos quite useful

4 Answers

60 votes
 
Best answer

option C: DLL takes more time in program setup (in loading and linking phase to set up the global offset table and load and link the required libraries)

  • Since DLLs are separated from executable, the size of executable becomes smaller. Since DLLs are shared among multiple executables, the total memory usage of the system goes down and hence overall page fault rate decreases.
  • Dynamic linking takes place during program runtime. So, if a DLL is replaced to a new version, it will automatically get linked during runtime. There is no explicit relinking required as in the case of static linking. (This works by linking the DLL calls to Global Offset Table and the contents of this table is filled during program run. A simple jump in static linking becomes an indirect jump in dynamic linking).

Refer: Galvin section 8.1.5, Dynamic Linking and Shared Libraries


edited by
1
Why is B) wrong?
1
it is true
0
So what is the final  answer ? b or c?
0
though during mid of execution static linking will be faster because everything is already linked, so no kernal involvement, no system calls, no unnecessary overheads, but during startup DLL should be faster than static linking, because there will be less overhead to link everything at startup..and program can start without linking everything..
0
so,you are suggesting b as answer?
3
@Arjun Sir,

The answer explains about dynamic and static library but I have read some resources and Galvin also but it does not say anything about page fault. My understanding is that in case of static linking we will load everything at one time and there will be no dependency at run time and all required library are there in Main memory but in case of dynamic linking everytime we need to refer library it will load and run time which creates page fault.So Dynamic linking will have more page faults.

No coming to start up time,i think as static linking will load all the referenced library at compile time so it should take more time and as dynamic library will defer all references to external library till run time so it should take less time at start up.

So B should be correct answer.
0
In made easy book the answer is given as C.
9

Ref: 

0
dynamic linking causes more page fault rate because we don 't load everything  with program  as library may not present in main memory ,they are referred seperately

in static linking we load library along with process hence it has less number of page fault
28 votes

The shared library code is not present in the executable image on disk, but is kept in a separate library file. So size of executable file is smaller.

Operating system is less likely to page out shared library code that is being used by several applications, or copies of an application, rather than code that is only being used by a single application. This causes less page fault. 

But sometimes you may be interested in only a few of the routines in a library, and these routines may be scattered widely in the virtual address space of the library. Thus, the total number of pages you need to touch to access all of your routines is significantly higher than if these routines were all bound directly into your executable program. One impact of this situation is that, if you are the only user of these routines, you experience more page faults to get them all into real memory.

Faster program startup as load time might be reduced because the shared library code might already be in memory.

The routines are not statically bound to the application but are dynamically bound when the application is loaded. This permits applications to automatically inherit changes to the shared libraries, without recompiling or rebinding.

So option A, C and D are always the advantage of the shared DLL. Only option B is not always an advantage.

Reference: http://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.performance/when_dyn_linking_static_linking.htm

0
But sometimes you may be interested in only a few of the routines in a library, and these routines may be scattered widely in the virtual address space of the library. Thus, the total number of pages you need to touch to access all of your routines is significantly higher than if these routines were all bound directly into your executable program. One impact of this situation is that, if you are the only user of these routines, you experience more page faults to get them all into real memory.

 

yes, option (b) seems to be incorrect.

 

and also (a)smaller sizes of executables; supports the fact that (b) faster program startup
15 votes
More Page faults in dynamic linked libraries so solution is "B"
0 votes
I dont know about C but B is true.

As in dynamic linked libraries only required files are called upon so locality of reference reduces . The routines that are called may be spread across the virtual address so more number of pages are required to access itso more page fault is there.
Answer:

Related questions

29 votes
6 answers
1
3.7k views
The following program fragment is written in a programming language that allows global variables and does not allow nested declarations of functions. global int i=100, j=5; void P(x) { int i=10; print(x+10); i=200; j=20; print (x); } main() {P(i+j);} If the ... scoping and call by name parameter passing mechanism, the values printed by the above program are $115, 220$ $25, 220$ $25, 15$ $115, 105$
asked Apr 24, 2016 in Compiler Design jothee 3.7k views
27 votes
5 answers
2
3.4k views
The following program fragment is written in a programming language that allows global variables and does not allow nested declarations of functions. global int i=100, j=5; void P(x) { int i=10; print(x+10); i=200; j=20; print (x); } main() {P(i+j);} If the ... and call by need parameter passing mechanism, the values printed by the above program are: $115, 220$ $25, 220$ $25, 15$ $115, 105$
asked Sep 17, 2014 in Programming Kathleen 3.4k views
19 votes
3 answers
3
4.3k views
Assume that the SLR parser for a grammar G has $n_1$ states and the LALR parser for G has $n_2$ states. The relationship between $n_1$ and $n_2$ is $n_1$ is necessarily less than $n_2$ $n_1$ is necessarily equal to $n_2$ $n_1$ is necessarily greater than $n_2$ None of the above
asked Sep 16, 2014 in Compiler Design Kathleen 4.3k views
45 votes
10 answers
4
9.4k views
Which of the following suffices to convert an arbitrary CFG to an LL(1) grammar? Removing left recursion alone Factoring the grammar alone Removing left recursion and factoring the grammar None of the above
asked Sep 16, 2014 in Compiler Design Kathleen 9.4k views
...