Development update
Hannes Wallnoefer
I thought I'd give a little update on recent rhino commits (some of
them quite massive).
On the master branch, recent changes have mostly been limited to bug
fixing. Here's a list of bugs since the release of 1.7R3:
The more significant changes on the master branch since 1.7R3 are the
introduction of ConsStrings for faster string concatenation and the
port of V8 fast-dtoa from Spidermonkey which speeds up number to
string conversion and also helped to fix a few bugs there. The master
branch should be quite stable, I don't want to make larger changes
there and I think we should start thinking about a 1.7R4 release.
As previously posted I'm working on some bigger changes for an
upcoming major release, and I've started a "rhino_1_8" branch for
these. Whether that release will actually be 1.8 and whether all those
changes will go into it is up to debate, however that's my "future"
branch for now.
My main priorities for rhino_1_8 are 1) improving performance and 2)
overcoming rhino's problem with large script files/functions. So far
I've done the following:
- Removed some code and features which outlived their usefulness: the
old XMLBeans based E4X implementation, the __parent__ property, the
global Script, With, and Call objects (whatever those were supposed to
do)
- Started to avoid using IdScriptableObject as explained in another
thread.
- Added a function activation object that uses indexed instead of
hashed access to parameters and variables, making functions using it
(and nested closures) almost as fast as those using JVM locals to
store parameters and variables.
- Change optimizer.Codegen to produce one java class per function
instead of packing all functions into a single class file. The problem
with the single class file approach is that it's quite tricky and adds
a high base level of complexity to bytecode generation that makes
adding optimizations harder than it should be.
These changes have had some nice effects on performance already. V8-
benchmark-5 results are now nearing 600 on my laptop, up from 360 for
1.7R3. Sunspider is down to 2000ms from >80000ms in 1.7.R3, but that's
mostly due the ConsStrings.
The next things I'm planning are:
- Make large scripts like env.js or coffee-script.js run in compiled
mode. The way to do this is to recognize long functions and split them
up into several java methods. One approach I've tested successfully
with Coffescript is to swap out creation of object literals into their
own method.
- Try porting PCRE/JSCRE to Java. This is the Regexp engine that afaik
has been used by all major JS engines before they started their own
JITed Regexp engines. Regexp is by far our weakest area in benchmarks
and PCRE should be fast and compatible.
Hannes
Mike Schwartz
Any chance you might improve the graphical debugger?
Joel Hockey
>
> Any chance you might improve the graphical debugger?
For Hannes or anyone else who is interested, I've got a patch for the
debugger to add some syntax highlighting.
https://bugzilla.mozilla.org/show_bug.cgi?id=605059
I'm happy to reformat and submit a git pull request.
On the topic of regex improvements which I have spent some time
looking into, my suggestion as an alternative to porting the PCRE
engine is that you will get some performance gains with little work if
you do some pre-parsing of regexps to determine if the regexp is
'safe' to use with java.util.regex otherwise fall back to current
implementation. The ECMA regexp spec has some quirks that are not
compatible with java.util.regex or oniguruma (joni from jruby) or any
other java regexp lib that I am aware of. However these particular
rules are very unlikely to be exercised in normal usage, and I suspect
that very little if any of the sunspider or v8 test cases would use
them. So with a small amount of work, you can probably get
performance gains in real-world use (and benchmarks) but still
maintain full spec compliance.
Jay Young
Hannes Wallnoefer
> > Very nice, Hannes!
>
> > Any chance you might improve the graphical debugger?
>
> For Hannes or anyone else who is interested, I've got a patch for the
> debugger to add some syntax highlighting.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=605059
Cool, I'll try the patch out today.
> I'm happy to reformat and submit a git pull request.
>
> On the topic of regex improvements which I have spent some time
> looking into, my suggestion as an alternative to porting the PCRE
> engine is that you will get some performance gains with little work if
> you do some pre-parsing of regexps to determine if the regexp is
> 'safe' to use with java.util.regex otherwise fall back to current
> implementation. The ECMA regexp spec has some quirks that are not
> compatible with java.util.regex or oniguruma (joni from jruby) or any
> other java regexp lib that I am aware of. However these particular
> rules are very unlikely to be exercised in normal usage, and I suspect
> that very little if any of the sunspider or v8 test cases would use
> them. So with a small amount of work, you can probably get
> performance gains in real-world use (and benchmarks) but still
> maintain full spec compliance.
I'd be very interested in such a patch, both as backup if the PCRE
port doesn't work out and for the 1.7 branch. For those who don't
know, Joel has done some great work in making regexp engines pluggable
and writing wrappers for java.util.regex and JRuby's Joni, but I
didn't merge it in the end because of remaining incompatibilities with
the Ecma spec. I think there were a few dozen mozilla tests failing,
more for java.util.regex than for Joni if I remember correctly.
Hannes
Hannes Wallnoefer
> Does this remove all E4X support, or is there still some other
> implementation in there?
No, it just removes the very old and buggy original implementation
based on Apache XMLBeans that hopefully nobody was using anymore. The
new implementation is based on the DOM3 API which has been part of the
JDK since I think 1.5.
Actually there are a few E4X bugs that should be fixed in master
branch, but I'm not really using E4X so it's quite possible some
regression sneaked in. For anybody using E4X now would be a great
moment to test your code with the master branch.
Hannes
Joel Hockey
>> debugger to add some syntax highlighting.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=605059
>
> Cool, I'll try the patch out today.
If you make TokenStream.isKeyWord visible through to the SwingGUI
class, you can get rid of the long list of keywords that is part of
the patch.
See:
and
https://github.com/joelhockey/rhino-mirror/commit/941dc496203fd087c5e6de5c4efb320138084df0
>> On the topic of regex improvements ...
> I'd be very interested in such a patch
I don't have much time at the moment, but for anyone else who is
interested, you can see the code that I have done for integrating joni
and j.u.r on my github fork
https://github.com/joelhockey/rhino-mirror/tree/master/src/org/mozilla/javascript/regexp
The core piece of functionality that I am suggesting is that when a
new RegExp is created, you can parse the regexp and determine if it
contains any of the exotic things where j.u.r is
not compliant to ecma (sorry, but I can't recall exactly what they
are, but you could always run my branch across the full test suite to
find out). Some of these things can be overcome by rewriting the
regexp into a form where j.u.r will work correctly (see
https://github.com/joelhockey/rhino-mirror/blob/master/src/org/mozilla/javascript/regexp/REJavaUtilRegex.java#L170).
But when that is not possible, just fall back to the default rhino
regexp engine.
> I didn't merge it in the end because of remaining incompatibilities with
> the Ecma spec. I think there were a few dozen mozilla tests failing,
> more for java.util.regex than for Joni if I remember correctly.
Yes joni was closer to ecma than jur and a bit faster I think, but I
never got either to be fully compliant, and it is not possible to do
so. I think this approach of pre-parsing shouldn't be too hard and
could have some good perf gains though.
Michael Schwartz
In terms of the graphical debugger:
1) mouse over variables should show a tool tip with the value
2) viewing a variable should be tree like, you should be able to expand the members and see those values
3) there's no breakpoints tab to show what breakpoints are set, and an interface to toggle enable/disable them and delete them is obviously missing
That's just a start…
:)
Tony Zakula
Tony Zakula
Frank P. Westlake
>The past few weeks have been productive - blame it on
>the weather - so I thought I'd give a little update on
>recent rhino commits (some of them quite massive).
Thank you very much for all this work Hannes.
Does anyone have a jar of this that I can download? I
still haven't firured out how to create one with
Eclipse.
Frank
Koen Serry
modules,
but I need some help in separating the unittests (as they're quite
spagetti now)
Koen
Attila Szegedi
Frank
Frank P. Westlake
> $ ant jar
Thanks. Hannes suggested the same thing but I've been
trying to figure out how to create it with 'eclipse'
because I don't have 'ant' installed. I know the
solution to that would be to install 'ant', and I will,
but how long it will be before I can't do that I don't
know.
Frank
Tim Schaub
After cloning the repo and checking out the branch that you want, add
the project in Eclipse. Find the build.xml file and look for the
targets listed in the "Outline" view. From there you can run the
"jar" target.
>
> Frank
>