Princeton S* Network Systems - Latest Comments

Re: Should We Extend Conference Q&A With Written Responses?

tareq — Sun, 13 May 2012 08:42:59 -0000

While you are preparing to choose game design colleges,
consider the physical campus and location
in addition to the academic
strength of the game design programs.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Mon, 30 Apr 2012 10:27:25 -0000

Everything that SpiderMonkey supports, which is all of them from 1.0 to 1.8

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Yansky — Sun, 29 Apr 2012 22:22:45 -0000

Which version of javascript does js.js support?

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Mon, 23 Apr 2012 16:43:32 -0000

Switching off the JIT ensures that we have a fair comparison. We wanted to measure the overhead of running the interpreter in JavaScript. There are plenty of benchmarks showing how good the JIT performs, so it's not really interesting to compare to a JIT version.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Erik Corry — Sun, 22 Apr 2012 11:14:05 -0000

So it's over 300ms of pure CPU time to do a hello world (or 1+1) startup-work-shutdown cycle. That's pretty heavy. This is on a beefy laptop machine, and not a phone or netbook.

What's the justification for switching off the JIT in the native version when doing the speed comparison? Seems like you are just arbitrarily hobbling the competition there.

What I learn from this is that there are good engineering reasons to prefer the approach of restricting the dialect of JS that you support as some of the alternative approaches do. Perhaps one should go even further and require the to-be-sandboxed code to do without eval.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Guest — Sat, 21 Apr 2012 15:12:57 -0000

FYI:

In Fibonacci, Chrome gives me

js.js result for iteration 100: 1990706582
Native result for iteration 100: 354224848179262000000

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

ThomasX — Fri, 20 Apr 2012 17:08:25 -0000

Could someone do this for PHP please?

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Colin Faulkingham — Fri, 20 Apr 2012 14:30:24 -0000

yo dawg. I heard you like javascript. So we put Javascript in your Javascript so you can write Javascript for your Javascript. :-)

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Techload Sites Ribeirao Preto — Fri, 20 Apr 2012 13:45:44 -0000

Very good work!

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Andrew Fuchs — Fri, 20 Apr 2012 13:33:30 -0000

Jeff, this is some great code!

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Irishado — Fri, 20 Apr 2012 13:21:02 -0000

It's not about if it will work its about trying to do something that no one thought about.

Excellent work guys keep it up

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Fri, 20 Apr 2012 13:20:02 -0000

Yes, see my reply to Marquier's comment about this

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

ZJM — Fri, 20 Apr 2012 13:14:44 -0000

I think there may be an issue with the Fibonacci demo
in js.js for numbers larger than 46. Overflow? Using Chrome 18.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Fri, 20 Apr 2012 12:37:24 -0000

Not really - the interpreter is single-threaded. It potentially could be put it in a background web worker so it wouldn't block the main thread, but DOM access would be difficult from a web worker.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

larrybattle — Fri, 20 Apr 2012 12:33:13 -0000

Would there be an performance increase if you used web workers?

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

wong2 — Fri, 20 Apr 2012 11:23:31 -0000

I'm consistently get this error too.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

PIT — Fri, 20 Apr 2012 10:05:08 -0000

Wow, It's really amazing!

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Fri, 20 Apr 2012 09:23:39 -0000

Hmm, it would be interesting to do, but the NaCl client version should win by a landslide. It's not really a fair comparison.

As for startup time - that's what the first entry is in the table of microbenchmark times.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Fri, 20 Apr 2012 09:18:58 -0000

This is because I'm converting to an i32 rather than a double. It should be able to be fixed relatively easily.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Guénolé Marquier — Fri, 20 Apr 2012 08:38:01 -0000

Until 46 as iteration number in the Fib demo works fine

But starting from 47, the native and js.js buttons give different results :(

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Erik Corry — Fri, 20 Apr 2012 08:20:04 -0000

It seems there is no comparison to the NaCl port of V8.

Also, startup times for the pages containing js.js would be interesting.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

wewebuk — Fri, 20 Apr 2012 02:54:07 -0000

Nice, I would like to see more regarding this, but also It can be achieved with much simpler code

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Guest — Fri, 20 Apr 2012 02:35:58 -0000

It sounds great, but, it a little bit complicated for a very simple concept in Javascript, is it not?
What about simply redefining symbols that should not be accessed?

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Jeff Terrace — Fri, 20 Apr 2012 00:05:45 -0000

If you check out the paper, we have a related work section where we discuss ADsafe and Caja.

Re: JavaScript in JavaScript (js.js): Sandboxing Third-Party Scripts

Guest — Fri, 20 Apr 2012 00:02:39 -0000

How do allow the Javascript access to useful APIs? Why did you write your own interpreter instead of taking a verifier approach like ADSafe or a source code rewriter approach like Caja?