Set - 8

Question 21 :

Why Thread is faster compare to process?

Answer :

A thread is never faster than a process. If you run a thread(say there's a process which has spawned only one thread) in one JVM and a process in another and that both of them require same resources then both of them would take same time to execute. But, when a program/Application is thread based(remember here there will be multiple threads running for a single process) then definetly a thread based appliation/program is faster than a process based application. This is because, when ever a process requires or waits for a resource CPU takes it out of the critical section and allocates the mutex to another process.
Before deallocating the ealier one, it stores the context(till what state did it execute that process) in registers. Now if this deallocated process has to come back and execute as it has got the resource for which it was waiting, then it can't go into critical section directly. CPU asks that process to follow scheduling algorithm. So this process has to wait again for its turn. While in the case of thread based application, the application is still with CPU only that thread which requires some resource goes out, but its co threads(of same process/apllication) are still in the critical section. Hence it directly comes back to the CPU and does not wait outside. Hence an application which is thread based is faster than an application which is process based.
Be sure that its not the competion between thread and process, its between an application which is thread based or process based.


Question 22 :

When and How is an object considered as Garbage by a GC?

Answer :

An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms simply iterate over every reachable object. Any objects left over are then considered garbage.


Question 23 :

What are generations in Garbage Collection terminology? What is its relevance?

Answer :

Garbage Collectors make assumptions about how our application runs. Most common assumption is that an object is most likely to die shortly after it was created: called infant mortality. This assumes that an object that has been around for a while, will likely stay around for a while. GC organizes objects into generations (young, tenured, and perm). This tells that if an object lives for more than certain period of time it is moved from one generation to another generations( say from young -> tenured -> permanent). Hence GC will be run more frequently at the young generations and rarely at permanent generations. This reduces the overhead on GC and gives faster response time.


Question 24 :

What is a Throughput Collector?

Answer :

The throughput collector is a generational collector similar to the default collector but with multiple threads used to do the minor collection. The major collections are essentially the same as with the default collector. By default on a host with N CPUs, the throughput collector uses N garbage collector threads in the collection. The number of garbage collector threads can be controlled with a command line option.


Question 25 :

When to Use the Throughput Collector?

Answer :

Use the throughput collector when you want to improve the performance of your application with larger numbers of processors. In the default collector garbage collection is done by one thread, and therefore garbage collection adds to the serial execution time of the application. The throughput collector uses multiple threads to execute a minor collection and so reduces the serial execution time of the application. A typical situation is one in which the application has a large number of threads allocating objects. In such an application it is often the case that a large young generation is needed