Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
/*
* Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation. Oracle designates this
* particular file as subject to the "Classpath" exception as provided
* by Oracle in the LICENSE file that accompanied this code.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*/
package org.openjdk.nashorn.internal.runtime;
import java.util.Collection;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;
import org.openjdk.nashorn.internal.runtime.options.Options;
/**
* Immutable hash map implementation for properties. Properties are keyed on strings
* or symbols (ES6). Copying and cloning is avoided by relying on immutability.
*
* When adding an element to a hash table, only the head of a bin list is updated, thus
* an add only requires the cloning of the bins array and adding an element to the head
* of the bin list. Similarly for removal, only a portion of a bin list is updated.
*
* For large tables with hundreds or thousands of elements, even just cloning the bins
* array when adding properties is an expensive operation. For this case, we put new
* elements in a separate list called {@link ElementQueue}.
* The list component is merged into the hash table at regular intervals during element
* insertion to keep it from growing too long. Also, when a map with a queue component
* is queried repeatedly, the map will replace itself with a pure hash table version
* of itself to optimize lookup performance.
*
* A separate chronological list is kept for quick generation of keys and values, and,
* for rehashing. For very small maps where the overhead of the hash table would
* outweigh its benefits we deliberately avoid creating a hash structure and use the
* chronological list alone for element storage.
*
* Details:
*
* The main goal is to be able to retrieve properties from a map quickly, keying on
* the property name (String or Symbol). A secondary, but important goal, is to keep
* maps immutable, so that a map can be shared by multiple objects in a context.
* Sharing maps allows objects to be categorized as having similar properties, a
* fact that call site guards rely on. In this discussion, immutability allows us
* to significantly reduce the amount of duplication we have in our maps.
*
* The simplest of immutable maps is a basic singly linked list. New properties
* are simply added to the head of the list. Ancestor maps are not affected by the
* addition, since they continue to refer to their own head. Searching is done by
* walking linearly though the elements until a match is found, O(N).
*
* A hash map can be thought of as an optimization of a linked list map, where the
* linked list is broken into fragments based on hashCode(key) . An array is use
* to quickly reference these fragments, indexing on hashCode(key) mod tableSize
* (tableSize is typically a power of 2 so that the mod is a fast masking
* operation.) If the size of the table is sufficient large, then search time
* approaches O(1). In fact, most bins in a hash table are typically empty or
* contain a one element list.
*
* For immutable hash maps, we can think of the hash map as an array of the shorter
* linked list maps. If we add an element to the head of one of those lists, it
* doesn't affect any ancestor maps. Thus adding an element to an immutable hash
* map only requires cloning the array and inserting an element at the head of one
* of the bins.
*
* Using Java HashMaps we don't have enough control over the entries to allow us to
* implement this technique, so we are forced to clone the entire hash map.
*
* Removing elements is done similarly. We clone the array and then only modify
* the bin containing the removed element. More often than not, the list contains
* only one element (or is very short), so this is not very costly. When the list
* has several items, we need to clone the list portion prior to the removed item.
*
* Another requirement of property maps is that we need to be able to gather all
* properties in chronological (add) order. We have been using LinkedHashMap to
* provide this. For the implementation of immutable hash map, we use a singly
* linked list that is linked in reverse chronological order. This means we simply
* add new entries to the head of the list. If we need to work with the list in
* forward order, it's simply a matter of allocating an array (size is known) and
* back filling in reverse order. Removal of elements from the chronological list
* is trickier. LinkedHashMap uses a doubly linked list to give constant time
* removal. Immutable hash maps can't do that and maintain immutability. So we
* manage the chronological list the same way we manage the bins, cloning up to the
* point of removal. Don't panic. This cost is more than offset by the cost of
* cloning an entire LinkedHashMap. Plus removal is far more rare than addition.
*
* One more optimization. Maps with a small number of entries don't use the hash
* map at all, the chronological list is used instead.
*
* So the benefits from immutable arrays are; fewer objects and less copying. For
* immutable hash map, when no removal is involved, the number of elements per
* property is two (bin + chronological elements). For LinkedHashMap it is one
* (larger element) times the number of maps that refer to the property. For
* immutable hash map, addition is constant time. For LinkedHashMap it's O(N+C)
* since we have to clone the older map.
*/
public final class PropertyHashMap implements Map