Sharing native JavaScript objects across contexts in Nashorn - javascript

I have a Nashorn engine in which I evaluate some scripts that expose some common utility functions and objects. I want custom scripts to run in their own contexts and not step over each other, so I create new contexts for them using engine.createBindings():
ScriptContext newContext = new SimpleScriptContext();
newContext.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE);
newContext.getBindings(ScriptContext.ENGINE_SCOPE).putAll(engine.getBindings(ScriptContext.ENGINE_SCOPE));
Now I have access to everything that was created in the original scope, but this also creates an entirely-new global-object for the new context, which means that instances of native JS objects like Object, Number, etc. are different from corresponding instances in the original context.
This leads to some strange behavior. For example, assume you have the following code that was evaluated in the engine (i.e., the "parent" context"):
function foo(obj) {
print(JSON.stringify(obj, null, 4));
print(Object.getPrototypeOf(obj) === Object.prototype);
}
Now let's say your custom script is as follows:
function bar() {
foo({a: 10, b: 20});
}
I evaluate this against newContext and then invoke the function:
engine.eval(source, newContext);
ScriptObjectMirror foo = newContext.getAttribute("foo", ScriptContext.ENGINE_SCOPE);
foo.call(null);
This returns:
undefined
false
This is expected behavior because objects created in other contexts are treated as foreign objects.
What I'm trying to do is to expose a common library of functions and maintain that within a single script-engine instance. I don't want to keep recreating script-engine instances because I end up losing JIT optimizations (I read this somewhere, but I can't find the link right now). I do like the fact that objects "remember" their originating global-context, but I'd like that not to happen in the case of native JS objects.
Is there a way to create an entirely-new global context, while still sharing JS global-object instances? I've tried manually copying over these instances (enumerating the properties of this), but when I copy them over to the new context, they are ScriptObjectMirror instances and not the unwrapped versions. I assume this is because they were originally created in a different context and therefore are considered to be "foreign".

It looks like it is not possible to do this unfortunately. I even unwrapped the objects and got back the native objects (I did this from the main thread), and then overwrote the ones in the new context. Unfortunately, this still doesn't work since the Java classes that represent native objects in Java maintain internal references to the original instances that were created (for prototypes of the object).
My workaround for the two cases above was to do this for the object test:
var proto = Object.getPrototypeOf(object);
return (typeof proto.constructor !== "undefined" && (proto.constructor.name === Object.prototype.constructor.name));
For JSON, I overwrote the native JSON object by evaluating Douglas Crockford's JSON library in the main context, and every new context. I did have to make some modifications to get it to work in Nashorn though. The first was to make it redefine the JSON object without check for its existence first (so just remove the if test). The second was to use the hasOwnProperty from the object itself as well, inside stringify. So the following line:
if (Object.prototype.hasOwnProperty.call(value, k))
Changes to:
if (Object.prototype.hasOwnProperty.call(value, k) || (value.hasOwnProperty && value.hasOwnProperty(k)))
With these two changes I was able to get things to work.

Related

ES6 iterators and ##iterator [duplicate]

I've noticed ## used in a few pages about new ES6 features, but I don't know what exactly it means (whether it's actually syntax or just some kind of documentation convention). And it's hard to google. Can someone explain it?
## describes what's called a well-known symbol. (Note that it isn't actually valid syntax in JS.) According to the ES6/ES20151 specification:
Well-known symbols are built-in Symbol values that are explicitly referenced by algorithms of this specification. They are typically used as the keys of properties whose values serve as extension points of a specification algorithm. Unless otherwise specified, well-known symbols values are shared by all Code Realms (8.2).
Code Realms refer to different instances of a JavaScript environment. For example, the Code Realm of the root document would be different to that of JavaScript running in an <iframe>.
An example of where it matter what code realm an object comes from is when trying to use instanceof to determine whether an object is an array (hint: it won't work if it's from another frame). To avoid these kinds of issues from popping up with symbols, they are shared so that references to (say) ##toString will work no matter where the object came from.
Some of these are exposed directly through the Symbol constructor, for example, ##toPrimitive is exposed as Symbol.toPrimitive. That can be used to override the value produced when attempting to convert an object to a primitive value, for example:
let a = { [Symbol.toPrimitive]: () => 1 };
console.log(+a); // 1
console.log(a.valueOf()); // (the same object)
console.log(a.toString()); // "[object Object]"
In general, symbols are used to provide unique properties on an object which cannot collide with a random property name, for example:
let a = Symbol();
let foo = { [a]: 1 };
foo[a]; // 1
There is no way to access the value except by getting the symbol from somewhere (though you can get all symbols for an object by calling Object.getOwnPropertySymbols, so they cannot be used to implement private properties or methods).
1: See this es-discuss topic for some discussion about the different names.

Does Chrome retain each object's constructor?

In Chrome's JavaScript console:
> function create(proto) {
function Created() {}
Created.prototype = proto
return new Created
}
undefined
> cc = create()
Created {}
> cc
Created {}
Created is a function private to the create function; after create completes, there are no (known to me) references to Created. Yet Chrome can show the function's name at any time, starting from the object created by it.
Chrome didn't achieve this by following the "naïve" approach:
> cc.constructor
function Object() { [native code] }
> cc.toString()
"object [Object]"
and anyway, I didn't set constructor on the proto argument passed to create:
> cc.__proto__.hasOwnProperty("constructor")
false
One guess I had is that the JavaScript VM holds on to Created for the sake of the instanceof mechanism. It is said that instanceof
tests whether an object has in its prototype chain the prototype property of a constructor.
But in the above code I typed create(), effectively passing undefined as prototype; consequently Created doesn't even have its prototype set to the actual cc.__proto__. We can verify this if we hack create to expose the Created function:
function create(proto) {
function Created() {}
Created.prototype = proto
GlobalCreated = Created
return new Created
}
now let's type
> cc = create()
Created {}
> GlobalCreated
function Created() {}
> GlobalCreated.prototype
undefined
> cc instanceof GlobalCreated
TypeError: Function has non-object prototype 'undefined' in instanceof check
My questions (all closely related):
What exactly does Chrome's JavaScript engine retain to make that object presentation in the console work? Is it the constructor function, or just the function name?
Is that retention needed for anything more substantial than console printout?
What is the effect of such retention on memory consumption? What if, for example, the constructor function (or even its name) is abnormally huge?
Is it just Chrome? I've retested with Firebug and Safari, their consoles don't present the object that way. But do they still retain the same data, for other possible purposes (e.g. due to a genuine concern inherent to a JavaScript VM)?
Late edit:
I recently revisited this question/answer, and I think I've figured out why chrome seems to "hang on" to the Created name. It's not really something that is exclusive to V8, but I think it's the result of how V8 works behind the scenes (the hidden objects I explained in my initial answer), and what V8 is required to do (to conform to the ECMAScript standard).
Any function, constructor functions or otherwise, share the same constructor and prototype-chain by default:
function Created(){};
console.log(Created.constructor);//function Function() { [native code] }
console.log(Object.getPrototypeOf(Created));//function Empty() {}
console.log(Created.__proto__);//same as above
console.log(Created.prototype);//Created {}
This tells us a few things: All functions share the native Function constructor, and inherit from a specific function instance (function Empty(){}) that is used as their prototype. However, a function's prototype property is required to be an object, that the function would return if it were called as a constructor (see ECMAScript standard).
The value of the prototype property is used to initialise the [[Prototype]] internal property of a newly created object before the Function object is invoked as a constructor for that newly created object. This property has the attribute { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }.
We can verify this easily by looking at the Created.prototype.constructor:
console.log(Created.prototype.constructor);//function Created() {}
Now let's, for a moment, list the hidden classes V8 needs to, and probably will, create in order for it to comply to the standard:
function Created(){}
Hidden classes:
Object, of course: the mother of all objects, of which Function is a specific child
Function: This native object is, as we've demonstrated, the constructor
function Empty: The prototype, from which our function will inherit
Created our empty function that will inherit from all of the above
At this stage, nothing unusual has happened, and it's self-evident that, when we return an instance of this Created constructor, the Created function will get exposed because of its prototype.
Now, because we're reassigning the prototype property you could argue that this instance will be discarded, and is lost, but from what I understand, that's not how V8 will handle this situation. Instead, it'll create an additional hidden class, that simply overrides the prototype property of its parent after this statement is encountered:
Created.prototype = proto;
Its internal structure will end up looking something like this (numbered this time, because I'll refer back to certain stages within this inheritance chain further down):
Object, of course: the mother of all objects, of which Function is a specific child
Function: This native object is, as we've demonstrated, the constructor
function Empty: The prototype, from which our function will inherit
Created our empty function that will inherit from all of the above
Created2: extends the previous class (Created), and overrides prototype
So why is Created still visible?
That's the million dollar question, to which I think I have the answer now: Optimization
V8 simply can't, nor should it be allowed to, optimize out the Created hidden class (stage 4). Why? Because what will override prototype is an argument. It's something that can't be predicted. What V8 will probably do to optimize the code is to store a hidden object 4, and whenever the create function is called, it'll create a new hidden class that extends stage 4, overriding the prototype property with whatever value is passed to the function.
Because of this, Created.prototype will always exist somewhere inside each instance's internal representation. It's also important to note you could replace the prototype property with one that actually referenced an instance of Created (with a mucked-up prototype chain, but still):
cc = create();
console.log(Object.getPrototypeOf(cc))//Object {}
cc = create(new GlobalCreated);
console.log(Object.getPrototypeOf(cc));//Created {}
How's that for a mind-bender? Inception script-writers, eat your hearts out...
Anyway, I hope all of this dribble made some sense to someone out here, if not, I do respond to comments, so corrections to mistakes I may have made, or questions regarding some part of this update that is a bit unclear are welcome...
I'll try to answer question by question, but as you say, they're all closely related, so the answers overlap up to a point.
While reading this, bare in mind that I wrote this in one go, whilst feeling a bit feverish. I am not a V8 expert, and based this on recollections of my doing some digging in the V8 internals some time ago. The link at the bottom is to the official docs, and will of course contain more accurate and up-to-date information on the subject.
What is going on
What chrome's V8 engine actually does is create a hidden class for each object, and this class is mapped to the JS representation of the object.
Or as the people at google say so themselves:
To reduce the time required to access JavaScript properties, V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes.
What happens in your case, extending, creating a new constructor from a particular instance and overriding the constructor property is actually nothing more than what you can see on this graph:
Where hidden class C0 could be regarded as the standard Object class. Basically, V8 interprets your code, builds a set of C++ like classes, and creates an instance if needed. The JS objects you have are set to point to the different instances whenever you change/add a property.
In your create function, this is -very likely- what is going on:
function create(proto)
{//^ creates a new instance of the Function class -> cf 1 in list below
function Created(){};//<- new instance of Created hidden class, which extends Function cf 2
function Created.prototype = proto;//<- assigns property to Created instance
return new Created;//<- create new instance, cf 3 for details
}
Right: Function is a native construct. The way V8 works means that there is a Function class that is referenced by all functions. They reference this class indirectly, though, because each function has its own specifcs, which are specified in a derived hidden class. create, then, should be seen as a reference to create extends HiddenFunction class.
Or, if you wish, in C++ syntax: class create : public Hidden::Function{/*specifics here*/}
The Create function references a hidden function identical to create. However, after declaring it, the class receives 1 propriety property, called prototype, so another hidden class is created, specifying this property. This is the basis of your constructor. Because the function body of create, where all of this happens, this is a given, and V8 will probably be clever enough to create these classes beforehand, anyway: in C++ pseudo-code, it'll look similar to code listing 1 below.
Each function call will assign a reference to a new instance Of the hidden class described above, to the Created name, which is local to create's scope. Of course, the returned instance of create does still retain the reference to this instance, but that's how JS scopes work, and so this applies to all engines... think of closures and you'll get what I mean (I'm really struggling with this nasty fever... sorry to nag about this)
At this stage Create points to an instance of this hidden class, which extends a class that extends a class (as I tried to explain in point 2). Using the new keyword triggers behaviour defined by the Function class, of course (as it's a JS language construct). This results in a hidden class to be created which is probably the same for all instances: it extends the native object, and this has a constructor property, which references the instance of Created we've just made. The instances returned by create though are all alike. Sure their constructors may have a different prototype property, but the objects they churn out all look the same. I'm fairly confident that V8 will only create 1 hidden class for the objects create returns. I can't see why the instances should require different hidden classes: their property names & count are the same, but each instance references another instance, but that's what classes are for
Anyway: code listing for item 2, a pseudo-code representation of what Created might look like in hidden-class terms:
//What a basic Function implementation might look like
namespace Hidden
{//"native" JS types
class Function : public Object
{
//implement new keyword for constructors, differs from Object
public:
Function(...);//constructor, function body etc...
Object * operator new ( const Function &);//JS references are more like pointers
int length;//functions have a magic length property
std::string name;
}
}
namespace Script
{//here we create classes for current script
class H_create : public Hidden::Function
{};
class H_Created : public Hidden::Function
{};//just a function
class H_Created_with_prototype : public H_Created
{//after declaring/creating a Created function, we add a property
//so V8 will create a hidden class. Optimizations may result in this class
// being the only one created, leaving out the H_Created class
public:
Hidden::Object prototype;
}
class H_create_returnVal : public Hidden::Object
{
public:
//the constructor receives the instance used as constructor
//which may be different for each instance of this value
H_create_returnVal(H_Created_with_prototype &use_proto);
}
}
Ignore any (likely) syntax oddities (it's been over a year since I wrote a line of C++), and ignoring namespaces and wacky names, The listed classes are, apart from the Hidden::Function effectively all the hidden classes that will ever need to be created to run your code. All your code then does is assign references to instances of these classes. The classes themselves don't take up much space in memory. And any other engine will create just as many objects, because they, too, need to comply with the ECMAScript specs.
So I guess, looking at it like this, this sort of answers all your questions: no not all engines work like this, but this approach won't cause massive amounts of memory to be used, Yes, this does mean a lot of information/data/references to all objects is retained, but that's just an unavoidable, and in some cases happy side-effect of this approach.
Update: I did a bit more digging, and found an example of how you could add JS functions to V8 using templates, it illustrates how V8 translates JS objects/functions to C++ classes, see the example here
This is just me speculating, but I wouldn't at all be surprized to learn that the way V8 works, and this retention business is heavily used in garbage-collection and memory management in general (EG: deleting a property changing hidden classes and the like)
For example:
var foo = {};//foo points to hidden class Object instance (call id C0)
foo.bar = 123;//foo points to child of Object, which has a property bar (C1)
foo.zar = 'new';//foo points to child of C1, with property zar (C2)
delete foo.zar;//C2 level is no longer required, foo points to C1 again
That last bit is just me guessing, but it could be possible for the GC to do this.
What is this retention used for
As I said, in V8, a JS object is actually a sort-of pointer to a C++ class. Accessing properties (and this includes the magic properties of arrays, too!), is fast. Really, really fast. In theory, accessing a property is an O(1) operation.
That's why, on IE:
var i,j;
for(i=0,j=arr.length;i<j;++i) arr[i] += j;
Is faster than:
for (i=0;i<arr.length;++i) arr[i] += arr.length;
While on chrome, arr.length is faster as shown her. I also answered that question, and it, too, contains some details on V8 you may want to check. It could be that my answer there doesn't (completely) apply anymore, because browsers and their engines change fast...
What about the memory
Not a big problem. Yes, Chrome can be a bit of resource hog at times, but the JS isn't always to blame. Write clean code, and the memory footprint won't be too different on most browsers.
If you create a huge constructor, then V8 will create a larger hidden class, but if that class specifies a lot of properties already, then chances of their being a need for additional hidden classes is smaller.
And of course, each function is an instance of the Function class. This being a native (and very important) type in a functional language will most likely be a highly optimized class anyway.
Anyway: as far as memory usage is concerned: V8 does a pretty good job managing memory. Far better than IE's of old, for example. So much so that the V8 engine is used for server-side JS (as in node.js), if memory really was an issue, then you wouldn't dream of running V8 on a server that must be up and running as much as possible, now would you?
Is this just Chrome
Yes, in a way. V8 does have a special take on how it consumes and runs JS. Rather than JIT-compiling your code to bytecode and running that, it compiles the AST straight into machine code. Again, like the hidden-classes trickery, this is to increase performance.
I know I included this graph in my answer on CR, but just for completeness' sake: Here's a graph that shows the differences between chrome (bottom) and other JS engines (top)
Notice that below the bytecode instructions and the CPU, there's an (orange) interpreter layer. That's what V8 doesn't need, owing to the JS being translated into machine code directly.
The downside being that this makes certain optimizations harder to do, especially concerning the ones where DOM data and user input is being used in the code (for example: someObject[document.getElementById('inputField').value]) and that the initial processing of the code is harder on the CPU.
The upside is: once the code is compiled into machine code, it's the fastest you're going to get, and running the code is likely to cause less overhead. A bytecode interpreter is heavier on the CPU most of the time, that's why busy loops on FF and IE can cause the browser to alert the user of a "running script" asking them if they want to stop it.
more on V8 internals here
I don't know much about Chrome's internals, so this is just a guess, but it seems to me that Chrome is performing some kind of static analysis on the code which created the function, and storing that for debugging purposes.
Take a look at this example:
> function create(proto) {
object = {}
object.x = {}
x = object.x
x.func = function() {}
x.func.prototype = proto
return new object.x.func
}
undefined
> create()
x.func {}
x.func? There's no way JavaScript has any built-in way for you to access the name of the variable a function was initially assigned to. Chrome must be doing that for its own reasons.
Now look at this example:
> function newFunc() {
return function() {}
}
> function create(proto) {
object = {}
object.x = {}
x = object.x
x.func = newFunc()
x.func.prototype = proto
return new object.x.func
}
undefined
> create()
Object {}
In this example, since we created the function in a separate closure before assigning it to a variable, Chrome doesn't know the "name" of the function, so it just says "Object".
These examples lead me to guess the following answers to your questions:
What exactly does Chrome's JavaScript engine retain to make that object presentation in the console work? Is it the constructor function, or just the function name?
It performs a static analysis of the code, and stores a string containing the function's "name" somewhere.
Is that retention needed for anything more substantial than console printout?
Probably not.
What is the effect of such retention on memory consumption? What if, for example, the constructor function (or even its name) is abnormally huge?
I'm not sure, but I'm guessing it's very unlikely to be an issue. Since the name of the function is determined using static analysis, the potential size of the function name is limited by the size of variable names in the script which created it (unless perhaps you're using eval, in which case I'm not sure).
Is it just Chrome? I've retested with Firebug and Safari, their consoles don't present the object that way. But do they still retain the same data, for other possible purposes (e.g. due to a genuine concern inherent to a JavaScript VM)?
I doubt it, this seems to be something specific to Chrome used to make debugging a bit easier. As far as I can tell, there's no other reason for a feature like this to exist.
Disclaimer: I am not a Google Chrome expert, however I think that these are not browser-specific, and can be explained by basic Javascript rules.
What exactly does Chrome's JavaScript engine retain to make that
object presentation in the console work? Is it the constructor
function, or just the function name?
Each Object or Function in Javascript has its inheritance chain, going up, all the way to the basic prototype.
You can not circumvent this by setting the prototype property to undefined, although it may seem like it from the console output.
So it is the whole constructor function that is retained because of inheritance, although not available to be accessed through global scope.
Is that retention needed for anything more substantial than console
printout?
Yes, it is needed for the prototype inheritance system to work.
What is the effect of such retention on memory consumption? What if,
for example, the constructor function (or even its name) is abnormally
huge?
Yes, this can cause a memory leak if used improperly.
This is why you should always delete and clean unused variables, so these and their prototypes can get collected by the garbage collector.
Is it just Chrome? I've retested with Firebug and Safari, their
consoles don't present the object that way. But do they still retain
the same data, for other possible purposes (e.g. due to a genuine
concern inherent to a JavaScript VM)?
This should work the same way across all browsers, because prototypal inheritance works the same. I have however not specifically tested for it. Please note that the console outputs int browsers can differ, and this does not mean anything, as each browser can implement its console in its own way.
//The real method to do clone
function doClone(source, keys, values, result) {
if (source == null || typeof (source) !== "object") {
return source;
}
if (source.Clone instanceof Function) {
return source.Clone();
}
if (source instanceof Date) {
if (!(result instanceof Date)) {
result = new Date();
}
result.setTime(source.getTime());
return result;
}
else if (source instanceof Array) {
if (!(result instanceof Array)) {
result = [];
}
for (var i = 0; i < source.length; i++) {
result[i] = clone(source[i], keys, values, result[i]);
}
return result;
}
try {
if (typeof result !== "object" || result == null) {
result = new source.constructor();
} else {
result.constructor = source.constructor;
}
if (source.prototype) {
result.prototype = source.prototype;
}
if (source.__proto__) {
result.__proto__ = source.__proto__;
}
} catch (e) {
if (Object.create) {
result = Object.create(source.constructor.prototype);
} else {
result = {};
}
}
if (result != null) {
// ReSharper disable once MissingHasOwnPropertyInForeach
for (var property in source) {
if (source.hasOwnProperty(property)) {
try {
var descriptor = Object.getOwnPropertyDescriptor(source, property);
if (descriptor != null) {
if (descriptor.get || descriptor.set) {
Object.defineProperty(result, property, descriptor);
} else {
descriptor.value = clone(descriptor.value, keys, values, result[property]);
Object.defineProperty(result, property, descriptor);
}
} else {
result[property] = clone(source[property], keys, values, result[property]);
}
} catch (e) {
result[property] = clone(source[property], keys, values, result[property]);
}
}
}
}
return result;
}
//The portal of clone method
function clone(source, keys, values, result) {
var index = keys.indexOf(source);
if (index !== -1) {
return values[index];
}
result = doClone(source, keys, values, result);
index = keys.indexOf(source);
if (index !== -1) {
values[index] = result;
} else {
keys.push(source);
values.push(result);
}
return result;
}
/**
* Core functions
*/
var X = {
/**
* Clone indicated source instance
* #param {} source The source instance to be clone
* #param {} target If indicated, copy source instance to target instance.
* #returns {}
*/
Clone: function (source, target) {
return clone(source, [], [], target);
}
}
You return a new instance from create to a object called Created.
create()()
> TypeError: object is not a function
If you were to remove the 'new' keyword, then you would expose the Created function to the caller's scope.

Javascript Object Identities

Objects in JavaScript have unique identities. Every object you create via an expression such as a constructor or a literal is considered differently from every other object.
What is the reason behind this?
{}==={}//output:false
For what reason they are treated differently? What makes them different to each other?
{} creates a new object.
When you try and compare two, separate new objects (references), they will never be equal.
Laying it out:
var a = {}; // New object, new reference in memory, stored in `a`
var b = {}; // New object, new reference in memory, stored in `b`
a === b; // Compares (different) references in memory
If it helps, {} is a "shortcut" for new Object(), so more explicitly:
var a = new Object();
var b = new Object();
a === b; // Still false
Maybe the explicitness of new helps you understand the comparison compares different objects.
On the other side, references can be equal, if they point to the same object. For example:
var a = {};
var b = a;
a === b; // TRUE
They are different instances of objects, and can be modified independently. Even if they (currently) look alike, they are not the same. Comparing them by their (property) values can be useful sometimes, but in stateful programming languages the object equality is usually their identity.
The fact that they're different is important in this scenario:
a={};
b={};
a.some_prop = 3;
At this point you'll obviously know that b.some_prop will be undefined.
The == or === operators thus allow you to be sure that you're not changing some object's properties, that you don't want changed
This question is quite old, but I think the actual solution does not pop out clearly enough in the given answers, so far.
For what reason they are treated differently? What makes them
different to each other?
I understand your pain, many sources in the internet do not come straight to the fact:
Object (complex JS types => objects, arrays and functions) variables store only references (=address of the instances in memory) as their value. Object identity is recognized by reference identity.
You expected something like an ID or reference inside the object, which you could use to tell them apart (maybe that's actually done transparently, under the hood). But every time you instantiate an object, a new instance is created in memory and only the reference to it is stored in the variable.
So, when the description of the ===-operator says that it compares the values, it actually means it compares the references (not the properties and their values), which are only equal if they point to the exactly same object.
This article explains it in detail: https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0
BR
Michael
Both of the objects are created as a separate entities in the memory. To be precise, both of the objects are created as a separate entities on the heap (JavaScript engines use heap and stack memory models for managing running scripts). So, both of the objects may look the same (structure, properties etc.) but under the hood they have two separate addresses in the memory.
Here is some intuition for you. Imagine a new neighborhood where all houses are look the same. You've decided to build another two identical buildings and after finishing the construction both of the buildings are look the same and they even "sit" contiguously but still they are not the same building. They have two separate addresses.
I think that the simplest answer is "they are stored in different locations in memory". Although it is not always clear in languages that hide pointers ( if you know C, C++ or assembly language, you know what pointers are, if not, it is useful study to learn a low level language ) by making everything a pointer, each "object" is actually a pointer to a location in memory where the object exists. In some cases, two variables will point to the same location in memory. In others, they will point to different locations in memory that happen to have similar or identical content. It's like having two different URLs, each of which points to an identical page. The web pages are equal to each other, but the URLs are not.

Google Chrome Heap Snapshots (closure), (array), (system), (compiled code) under programmer control?

I have noticed that the properties I mentioned in the title climb significantly in my page (especially '(closure)').
Is this OS and/or browser controlled? Can I do anything about it?
What exactly is (closure), (array), (compiled code), (system), etc.?
Also, what is the difference between (array) and 'Array'?
Regarding your question:
Q: What exactly is (closure), (array), (compiled code), (system), etc.?
This snippet from an article by Addy Osmani may help:
(global property) – intermediate objects between a global object (like 'window') and an object referenced by it. If an object is created using a constructor Person and is held by a global object, the retaining path would look like [global] > (global property) > Person. This contrasts with the norm, where objects directly reference each other. We have intermediate objects for performance reasons. Globals are modified regularly and property access optimisations do a good job for non-global objects aren't applicable for globals.
(roots) – The root entries in the retaining tree view are the entities that have references to the selected object. These can also be references created by the engine for its own purposes. The engine has caches which reference objects, but all such references are weak and won't prevent an object from being collected given that there are no truly strong references.
(closure) – a count of references to a group of objects through function closures
(array, string, number, regexp) – a list of object types with properties which reference an Array, String, Number or regular expression
(compiled code) – simply, everything related to compiled code. Script is similar to a function but corresponds to a body. SharedFunctionInfos (SFI) are objects standing between functions and compiled code. Functions are usually have a context, while SFIs do not.
HTMLDivElement, HTMLAnchorElement, DocumentFragment etc – references to elements or document objects of a particular type referenced by your code.
The full article has many other valuable nuggets of information regarding heap profiling: http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools
And your other question:
Q: Also, what is the difference between (array) and 'Array'?
Based on Addy's description, my interpretation is as such: (array) is an aggregate of objects (of any type) whom have a property that reference an actual Array. In contrast, Array is a list of actual Array objects.
A closure is a function that is able to refer to data that was declared outside of its immediate scope.
Here is an example:
var closure = (function() {
var a = "some data";
var b = "something else...";
return function Closure() {
// this function retains references to a and b.
}
})();
The most common way that you'd end up with closures in web development is through attaching event listeners to dom nodes.
ex:
$.ready(function() {
var $elems = $("selector");
var tools = new Tools();
$elems.mousedown(function() { // <-- this has created a closure
// We can refer to $elems and tools in here
// and so as long as this function is held on to so are those variables to which
// it has access
});
});
You verify this and actually see the (closure) count go up if you
pop open chrome
take a heap dump
run:
function DistinctName() {}
function DistinctName2() {}
in the javascript console
take another heap dump
select "comparison" from the heap dump options at the very bottom.
You'll see that DistinctName and DistinctName2 show up as new closures under the (closure) category.
v8 has a "JIT" compiler so I'd assume (compiled) refers to JIT compiled source.
I can only guess on (array) and (system).

Why is arr = [] faster than arr = new Array?

I ran this code and got the below result. I curious to know why [] is faster?
console.time('using[]')
for(var i=0; i<200000; i++){var arr = []};
console.timeEnd('using[]')
console.time('using new')
for(var i=0; i<200000; i++){var arr = new Array};
console.timeEnd('using new')
using []: 299ms
using new: 363ms
Thanks to Raynos here is a benchmark of this code and some more possible way to define a variable.
Further expanding on previous answers...
From a general compilers perspective and disregarding VM-specific optimizations:
First, we go through the lexical analysis phase where we tokenize the code.
By way of example, the following tokens may be produced:
[]: ARRAY_INIT
[1]: ARRAY_INIT (NUMBER)
[1, foo]: ARRAY_INIT (NUMBER, IDENTIFIER)
new Array: NEW, IDENTIFIER
new Array(): NEW, IDENTIFIER, CALL
new Array(5): NEW, IDENTIFIER, CALL (NUMBER)
new Array(5,4): NEW, IDENTIFIER, CALL (NUMBER, NUMBER)
new Array(5, foo): NEW, IDENTIFIER, CALL (NUMBER, IDENTIFIER)
Hopefully this should provide you a sufficient visualization so you can understand how much more (or less) processing is required.
Based on the above tokens, we know as a fact ARRAY_INIT will always produce an array. We therefore simply create an array and populate it. As far as ambiguity, the lexical analysis stage has already distinguished ARRAY_INIT from an object property accessor (e.g. obj[foo]) or brackets inside strings/regex literals (e.g. "foo[]bar" or /[]/)
This is miniscule, but we also have more tokens with new Array. Furthermore, it's not entirely clear yet that we simply want to create an array. We see the "new" token, but "new" what? We then see the IDENTIFIER token which signifies we want a new "Array," but JavaScript VM's generally do not distinguish an IDENTIFIER token and tokens for "native global objects." Therefore...
We have to look up the scope chain each time we encounter an IDENTIFIER token. Javascript VMs contain an "Activation object" for each execution context which may contain the "arguments" object, locally defined variables, etc. If we cannot find it in the Activation object, we begin looking up the scope chain until we reach the global scope. If nothing is found, we throw a ReferenceError.
Once we've located the variable declaration, we invoke the constructor. new Array is an implicit function call, and the rule of thumb is that function calls are slower during execution (hence why static C/C++ compilers allow "function inlining" - which JS JIT engines such as SpiderMonkey have to do on-the-fly)
The Array constructor is overloaded. The Array constructor is implemented as native code so it provides some performance enhancements, but it still needs to check for arguments length and act accordingly. Moreover, in the event only one argument is supplied, we need to further check the type of the argument. new Array("foo") produces ["foo"] where as new Array(1) produces [undefined]
So to simplify it all: with array literals, the VM knows we want an array; with new Array, the VM needs to use extra CPU cycles to figure out what new Array actually does.
One possible reason is that new Array requires a name lookup on Array (you can have a variable with that name in scope), whereas [] does not.
Good question.
The first example is called an array literal. It is the prefered way to create arrays among many developers. It could be that the performance difference is caused by checking the arguments of the new Array() call and then creating the object, while the literal creates an array directly.
The relatively small difference in performance supports this point I think. You could do the same test with the Object and object literal {} by the way.
Also, interesting, if the length of the array is known in advance (elements will be added just after creation), the use of an array constructor with a specified length is much faster on recent Google Chrome 70+.
"new Array( %ARR_LENGTH% )" – 100% (faster)!
"[]" – 160-170% (slower)
The test can be found here - https://jsperf.com/small-arr-init-with-known-length-brackets-vs-new-array/2
Note: this result tested on Google Chrome v.70+; in the Firefox v.70 and IE both variants almost equal.
This would make some sense
Objects literals enable us to write code that supports lots of
features yet still make it a relatively straightforward for the
implementers of our code. No need to invoke constructors directly or
maintain the correct order of arguments passed to functions, etc.
http://www.dyn-web.com/tutorials/obj_lit.php

Categories