JIT hotspot compiler

The Java JIT compiler compiles Java bytecode to native executable code during the runtime of your program. This increases the runtime of your program significantly. The JIT compiler uses runtime information to identify part in your application which are runtime intensive. These so-called “hot spots” are then translated native code. This is the reason why the JIT compiler is also called “Hot-spot” compiler.

JIT is store the original bytecode and the native code in memory because JIT can also decide that a certain compilation steps must be revised.

Java volatile again


The Java programming language also has the volatile keyword, but it is used for a somewhat different purpose. When applied to a field, the Java volatile guarantees that:

    (In all versions of Java) There is a global ordering on the reads and writes to a volatile variable. This implies that every thread accessing a volatile field will read its current value before continuing, instead of (potentially) using a cached value. (However, there is no guarantee about the relative ordering of volatile reads and writes with regular reads and writes, meaning that it's generally not a useful threading construct.)
    (In Java 5 or later) Volatile reads and writes establish a happens-before relationship, much like acquiring and releasing a mutex.[9]

Using volatile may be faster than a lock, but it will not work in some situations.[citation needed] The range of situations in which volatile is effective was expanded in Java 5; in particular, double-checked locking now works correctly.[10]


In computer science, the happened-before relation (denoted: \to \;) is a relation between the result of two events, such that if one event should happen before another event, the result must reflect that.

Fail fast vs fail safe

fail fast, throw exception if any concurrent modification.

fail safe, work on seperate/clean copy for modification, dont throw exception.


A thread-safe variant of java.util.ArrayList in which all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array. 

This is ordinarily too costly, but may be more efficient than alternatives when traversal operations vastly outnumber mutations, and is useful when you cannot or don't want to synchronize traversals, yet need to preclude interference among concurrent threads. The "snapshot" style iterator method uses a reference to the state of the array at the point that the iterator was created. This array never changes during the lifetime of the iterator, so interference is impossible and the iterator is guaranteed not to throw ConcurrentModificationException. The iterator will not reflect additions, removals, or changes to the list since the iterator was created. Element-changing operations on iterators themselves (remove, set, and add) are not supported. These methods throw UnsupportedOperationException. 

All elements are permitted, including null. 

Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a CopyOnWriteArrayList happen-before actions subsequent to the access or removal of that element from the CopyOnWriteArrayList in another thread. 

This class is a member of the Java Collections Framework.

Fail-Safe vs Fail-Fast Iterator in Java Collections
Fail-Safe Iterator (java.util.concurrent – ConcurrentSkipListSet, CopyOnWriteArrayList, ConcurrentMap)

Fail-safe Iterator is “Weakly Consistent” and does not throw any exception if collection is modified structurally during the iteration. Such Iterator may work on clone of collection instead of original collection – such as in CopyOnWriteArrayList. While ConcurrentHashMap’s iterator returns the state of the hashtable at some point at or since the creation of iterator. Most collections under java.util.concurrent offer fail-safe Iterators to its users and that’s by Design. Fail safe collections should be preferred while writing multi-threaded applications to avoid conurrency related issues. Fail Safe Iterator is guaranteed to list elements as they existed upon construction of Iterator, and may reflect any modifications subsequent to construction (without guarantee).

Fail-Fast Iterator (java.util package – HashMap, HashSet, TreeSet, etc)

Iterator fails as soon as it realizes that the structure of the underlying data structure has been modified since the iteration has begun. Structural changes means adding, removing any element from the collection, merely updating some value in the data structure does not count for the structural modifications. It is implemented by keeping a modification count and if iterating thread realizes the changes in modification count, it throws ConcurrentModificationException. Most collections in package java.util are fail-fast by Design.

Observor and Observable


This class represents an observable object, or "data" in the model-view paradigm. It can be subclassed to represent an object that the application wants to have observed. 

An observable object can have one or more observers. An observer may be any object that implements interface Observer. After an observable instance changes, an application calling the Observable's notifyObservers method causes all of its observers to be notified of the change by a call to their update method. 

The order in which notifications will be delivered is unspecified. The default implementation provided in the Observable class will notify Observers in the order in which they registered interest, but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or may guarantee that their subclass follows this order, as they choose. 

Note that this notification mechanism is has nothing to do with threads and is completely separate from the wait and notify mechanism of class Object. 

When an observable object is newly created, its set of observers is empty. Two observers are considered the same if and only if the equals method returns true for them.


A class can implement the Observer interface when it wants to be informed of changes in observable objects

ajax the file input

I am trying to submit multiple forms on same page at same time; with one of them being a file input.

The key is to wrap the form, using a new FormData.

    url: 'saveAttachment.do',
    type: 'POST',
    data: new FormData($('#saveAttachment')[0]),
    async: false,
    cache: false,
    contentType: false,
    processData: false,
    success: function (returndata) {

subresource and prefetch

both seems would try cache first, then http request if not yet cached.

At the same time, subresource could result in duplicate http retrieval, if same resources (eg. image) initiated again from another (eg.css). Because, subresource always force to download.

While, as prefetch is low priority, since it’s supposed for next page. So it waits for current page loading finish. And prefetch could be cancelled by subresource or any other initiation of same resource.

for example, with below source code:

<!-- below would be reinitiated/requested by css later -->
<link rel="subresource" href="images/header_brs.jpg" />
<link rel="subresource" href="images/float_bar_lg.gif" />
<link rel="prefetch" href="images/grad.jpg" />
<link rel="prefetch" href="images/brs_C.jpg" />
<!-- JS for next page -->
<link rel="prefetch" href="js/summaryPage.js" />
<link rel="subresource" href="js/summaryPage.js" />

it would render as below