in both directions.
72552: Remedy overzealous CHECK_REQUEST placement in jsapi.c, to produce a
minimal-but-complete set of engine entry points that require a Request
for safe execution.
r=brendan, sr=jband, assist=scc,pinkerton
where any occurrence of arguments.length or arguments[0], e.g., would be
"optimized" to use those bytecodes. This is just wrong if the occurrence
is an operand of delete, ++, --, or the left-hand-side of an assignment
operator!
- [jsfun.c, jsinterp.c] args_getProperty etc. must use JS_GetInstancePrivate,
not JS_GetPrivate, as the arguments object is exposed, and can be made a
prototype of other objects that do not have private data, or private data
that's a JSStackFrame*. Same goes for fun_getProperty, js_GetArgument, etc.
- [jsfun.c, jsobj.c, jsstr.c] No need to specialize fun_delProperty and
str_delProperty to help convince users and ECMA conformance tests that
fun.length and str.length are direct properties of instances, instead of
being delegated to Function.prototype.length and String.prototype.length.
This special case is done universally in js_DeleteProperty for all SHARED
and PERMANENT proto-properties.
- [jshash.c] Sneaking this followup-fix for bug 69271 in: use JS_HASH_BITS
rather than hardcoded 32.
- [jsobj.c, jsscope.[ch]] Fix misnamed js_HashValue (it takes a jsid, so it
is now js_HashId).
- [jsscript.c] script_compile needs to call JS_InstanceOf, to ensure that obj
is a Script object.
- Don't ape java.lang.String's bogo-sampling hash function for "long" (>=16
char) strings.
- Theory and practice comment in jsdhash.h helps analyze when to use double
hashing (most of the time) vs. when to use chaining.
- Subroutine ChangeTable from JS_DHashTableOperate so it can be called from
JS_DHashTableEnumerate, if the latter finds that enough entries have been
removed to be worth a shrink or compress cycle.
- teach nsGenericFactory about nsIClassInfo, and nsIClassInfo.idl to the
builds
- add a heaping serving of macro love for classes that want to support it
- convert many modules to use nsGenericModule the new way
- handful of warning and modeline fixes
- nsSample and some XPConnect test classes now have nsIClassInfo support for
testing
r=pchwartau, sr=brendan
Just add an _IS_LITTLE_ENDIAN for XP_OS2 for now. Eventually, we need to figure
out how to get jstypes.h included in here, since it already has a LITTLE_ENDIAN define.
r=pchwartau, sr=brendan
Rework makefile.win and js.mak for the eventual ability to include jstypes.h in fdlibm.h
Not turned on yet because I can't get it working right on Linux
- Fix bug where script jssrcnote vector terminator was not XDRed.
- Ensure that memory is cleared by serializing zero padding bytes as needed
under JS_XDRBytes and JS_XDRString.
- Fix JS_XDRValue to handle undefined and null JS types properly (bug 31003).
Also make it cast from jsint to uint32 and back carefully, so as to work
with negative numbers even on targets where jsval is a signed 64 bit type.
- Add JS_XDRScript public API.
- Optimize the per-JSXDRState class registry so it uses a JSDHashTable upon
searching for a class-id by name in an overpopulated (for linear search)
registry table.
- Clean up API nits such as JS_XDRNewBase => JS_XDRInitBase, with parameter
list rotation to put cx last (JS_XDRInitBase is an infallible init helper,
not an error-reporting, cx-comes-first, API entry point).
- Fix some XXX comments, unneeded masks, other nits.
- Make sure all JS XDR API functions start with JS_XDR.
* fixed ImporterTopLevel constructor - it now calls
cx.initStandardObjects before defining any functions. The old
constructor is still around for backwards compatibility.
- Fix scope chain for nested functions at top-level (JSOP_DEFFUN), in a part of another statement (JSOP_CLOSURE), and unnamed in an expression (JSOP_ANONFUNOBJ) to match ECMA-262 13.2. My bad: fp->varobj was used up till now, instead of fp->scopeChain; we still *bind* the name of a statement-level (top or not) nested function in fp->varobj. This fixes bug 69559. (r=rogerl, sr=jband)
- Add an Intern command to the shell, for GC vs. intern'ed atom testing.
Rhino Context.setTargetClassFileName() null pointer exception
Date:
Tue, 20 Feb 2001 15:28:20 -0800
From:
"Ryan Manwiller" <rdm@europa.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I'm setting the file name to compile to a file. However, on subsequent
compiles, I don't want to compile to a file, so I tried
setTargetClassFileName(null). This causes a NullPpinterException in
OptClassNameHelper.setTargetClassFileName(OptClassNameHelper.java:76)
It seems that Context.setTargetClassFileName() should check for null.
Thanks
until JS_DestroyRuntime is called (68450, r=rginda, sr=jband).
- NUL-terminate tagbuf in tagify, for the HTML helpers such as string.big()
(66648, r=timeless, sr=jband).
Subject:
Rhino Exception Handling: Inconsistency btw Old/New Versions of 1.5
Date:
Mon, 05 Feb 2001 06:07:07 -0800
From:
Timothy Bergeron <bergeron@resumerabbit.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I've been using Rhino for about a year with almost no problems. However,
I downloaded the latest Rhino tip (rhino15R2pre) and discovered a
significant difference in exception handling.
I rely heavily on JavaScript code like the following:
try {
var em = new ExceptionMaker();
em.npe(); // method throws a java.lang.NullPointerException
//em.ae(); // method throws a Packages.AutomationException
}
catch (e if (e instanceof java.lang.NullPointerException)) {
java.lang.System.out.println("Caught a NullPointerException");
e.printStackTrace();
}
catch (e if (e instanceof Packages.AutomationException)) {
java.lang.System.out.println("Caught an AutomationException");
}
catch (e) {
java.lang.System.out.println("Caught an unexpected exception: "+e);
}
finally {
java.lang.System.out.println("Finally!");
}
Previous Rhino versions worked as expected. The exception thrown from
within the host object would be caught and the appropriate actions could
be taken.
With the most recent tip, the thrown exceptions simply are not caught
within the JavaScript. They propagate back to the Java function invoking
the (in my case) Context.evaluateReader() method.
Running the above JS fragement with the older tip displayed the
following stack trace (when the NullPointerException was caught):
Rhino Version: JavaScript-Java 1.5 release 1 2000 03 15
Caught a NullPointerException
java.lang.NullPointerException
at java.lang.Throwable.<init>(Throwable.java:84)
at java.lang.Exception.<init>(Exception.java:35)
at java.lang.RuntimeException.<init>(RuntimeException.java:39)
at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
at java.lang.reflect.Method.invoke(Native Method)
at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:497)
at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1205)
at org.mozilla.javascript.gen.c1.call(exception.js:3)
at org.mozilla.javascript.gen.c1.exec(exception.js)
at
org.mozilla.javascript.Context.evaluateReader(Context.java:739)
at js.main(js.java:14)
Finally!
When run with the latest tip, the output is:
Rhino Version: JavaScript-Java 1.5 release 1 2000 03
15 Finally!
Exception in thread "main" java.lang.NullPointerException
at java.lang.Throwable.<init>(Throwable.java:84)
at java.lang.Exception.<init>(Exception.java:35)
at java.lang.RuntimeException.<init>(RuntimeException.java:39)
at
java.lang.NullPointerException.<init>(NullPointerException.java:45)
at ExceptionMaker.jsFunction_npe(ExceptionMaker.java:13)
at inv2.invoke()
at
org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:843)
at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:486)
at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1199)
at org.mozilla.javascript.gen.c1.call(Unknown Source)
at org.mozilla.javascript.gen.c1.exec(Unknown Source)
at
org.mozilla.javascript.Context.evaluateReader(Context.java:778)
at js.main(js.java:14)
Curiously, both Rhino versions seem to be returning the same string from
Context.getImplementionVerison();
Anyway, the results from the two runs are clearly different: In the
first case, the exception is thown, the correct catch block is invoked
(hence the stace trace), and the finally block is invoked. In the second
case, the exception is thrown, the finally block is invoked, and the
exception is handled by the calling Java method rather than being
handled by the JavaScript code.
After some research, it appears this change was introducted by a
modification to FunctionObject.call() (See
http://bugzilla.mozilla.org/show_bug.cgi?id=64788) which used to have:
try {
Object result = (method != null)
? method.invoke(thisObj, invokeArgs)
: ctor.newInstance(invokeArgs);
return hasVoidReturn ? Undefined.instance : result;
}
but now has:
Object result = method == null ?
ctor.newInstance(invokeArgs)
: doInvoke(thisObj,
invokeArgs);
If I comment out the new code and replace it with the old, the expected
exception handling returns. Is this just an oversight or the new
expected behavior? Are there any negative side effects (other then the
speed decrease in method invocation) if I use the latest tip but use the
old method invocation procedure in FunctionObject.call() rather than the
new?
- Remove bogus JS_ASSERT(!outermost) from the code that deals with a "#n="
type string being returned from js_EnterSharpObject, where the hash entry
is not yet sharp (because we haven't seen the object twice during depth
first search). This case trivially arises for the outermost object in,
e.g., 'o={}; o.foo=o; uneval(o)'.
- Avoid parenthesizing #n={...} object initializers for uneval, as they are
not ambiguous (whereas {foo:1}, e.g., is ambiguous because it could be a
block statement containing a labeled expression statement, or it could be
an object initializer).
- Death to tabs!
Re: [Rhino in Java] compiling .js to class file gives "bad local" error
Date:
Wed, 31 Jan 2001 09:41:45 +0100
From:
"Sylvia E. Schleutermann" <ses@h-m-s.com>
Organization:
.hms Health Management Systems
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2
I have found out some more. Looking really quickly over the JVM specs, I
found that
indeed the astore-command requires that the variables index be below 128.
However,
the book also said that if more index space is needed, a "wide" command can
be used to
be able to address up to 65xxx variables.
Question: is there a possibility to integrate this "wide"-command into the
class compiler?
Some option, that can be set? Or am I on the wrong tracks?
Please help, since I want to avoid spreading the script over many classes to
avoid the
size limitation. Cheers, Sylvia
Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
news:956sv9$9g53@secnews.netscape.com...
> I have found out that it is definitely the number of variables.
> I removed all variables and then the script compiled into class files
> with one base class and inner classes for each function in the script.
>
> What is the limitation exactly, i.e. does anyone know how many (global)
> variables
> I can use? Or is there some other kind of work around?
>
> Cheers, Sylvia
>
>
> Sylvia E. Schleutermann <ses@h-m-s.com> wrote in message
> news:956qtv$6kh3@secnews.netscape.com...
> > Hello,
> > when compiling a *.js file to class file, I get a "bad local" runtime
> > exception.
> > Stepping through the source, the following happens in reverse order:
> >
> > Codegen.xstore (75, 58, 209)
> > -> in the switch - default case, there is a comparison
> > for local (=209), which is compared to Byte.MAX_VALUE (=127).
> > When greater, the above exception is thrown.
> >
> > Codegen.astore (209)
> > -> calls Codegen.xstore (ByteCode.ASTORE_0, ByteCode.ASTORE, 209)
> >
> > Codegen.generatePrologue (<context>, <tree>, true, -1) // -1 is
> > directParameterCount
> > -> sets itsZeroArgArray = getNewWordLocal(); // here, the 209 is
> > produced
> > -> calls astore (itsZeroArgArray)
> >
> > From what I can read from the source code, the 209 seems to be a counter
> for
> > "locals", perhaps
> > local variables?? The function that is being compiled does initialize
many
> > variables - would it help
> > to move the initialize code out of the function into separate code
blocks?
> >
> > The function looks like this
> >
> > function rule_Disclaimer()
> > {
> > try { VAR1 = <init code 1>;} catch (exception) { VAR1 = <default
init
> > code 1>; }
> > try { VAR2 = <init code 2>;} catch (exception) { VAR2 = <default
init
> > code 2>;}
> > ... (about 58 such variables)
> >
> > var cond = true;
> >
> > < rest of code>
> > }
> >
> > When I compile the script for interpreted mode, all works well. The
> > variables VAR1 to VAR58 are to be global
> > variables (global to the whole script).
> >
> > I appreciate any help! Thanks, Sylvia
> >
> >
>
>
expressions. The method "prefix" on a RegExp behaves exactly the same
as the "exec" method except it returns "undefined" if the match failed
because there was an insufficient number of characters in the
input. E.g.
/^foo/.prefix("foo") => ["foo"] (just like exec)
/^foo/.prefix("fox") => null (just like exec)
/^foo/.prefix("fo") => undefined (whereas exec returns null)
Subject:
[Rhino] Question
Date:
Tue, 30 Jan 2001 20:18:21 +0900
From:
"get21" <get21@secsm.org>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I found something unusual to me when I hacking the Rhino source code.
In tagify method of NativeString Class,
When it adds tag to its string(this.string), it does not use quotation
marks.
For example, the result of tagify("A HREF", "A", value) in
jsFunction_link(String value) is
<A HREF=Some Value>Original String Value</A>
Not,
<A HREF="Some Value">Original String Value</A>
This question might sound silly, but I'm curious why.
Thanks in advance,
Nam
--
email : get21@secsm.org
home : http://get21.secsm.org
phone : 011-9092-1802
- Optimize compile (parse+emit) operation to generate code for each top-level
statement or function in turn, recycling JSParseNodes as we go for greatly
reduced "long linear script" footprint.
- Fix O(n**2) growth problems in bytecode and srcnote generation.
- Add js_ParseTokenStream entry point to compiler, for tree-generation without
code-generation. Move JSOP_EVAL instruction selection from code-generator to
parser, to match other such specializations and enable js_ParseTokenStream.
- Fix js_CompileTokenStream (and get it right in new js_ParseTokenStream) to
respect JSOPTION_VAROBJFIX.
- Clean up bracing, multi-line conditions, and overlong lines.
Some other small fixes are included. Here is the list...
- Make nsIJSID::id [noscript] because xpconnect automatically builds a nsIJSID
wrapper around nsid values. However, xpconnect does not maintain a table of
those wrappers. So, given the same id twice it will make two nsIJSID wrappers.
This means that property walking could get foo.id.id.id... and not detect that
the different objects represent the same id. nsIJSID already exposes 'number'
so that JS can get the stringified value of the nsid. The nsid struct returned
by 'id' is useful for C++, but only causes problems for JS.
- Fix the nsIXPCScriptable 'IGNORE' handler for GetAttributes to not fail
silently.
- Add 'Components' to global objects as a non-enumerable property for backwards
compatibility and to avoid additional work in property enumeration (esp. in
win.toSource!)
- Expose toSource on wrapped native JSObjects. This just returns an empty object
string: '{}'. It can be overridden by an interface method if present.
- Expose toString on wrapped native JSObjects. It can be overridden by an
interface method if present. Previously we only did this as part of the
Convert op. Now someWrapper.toString will return a callable function.
- Extend the toString behaviour to also print the address of the wrapper in
DEBUG builds only: e.g. "xpconnect wrapped nsIFoo @ 0x12345678". mccabe
convinced me this would be useful. Release build behaviour is unchanged - we
worried that exposing addresses might contribute to possible security exploits.
- Have wrapped native JSObjects use Object.prototype as their proto rather than
have a null proto. Originally this was going to allow delegation to
Object.prototype.toSource, but even without that, this seems like a good thing.
This is implemented by getting Object.prototype from the global object each
time we create a wrapper to allow for spify JS dynamic craziness.
- Use 16bit values in wrappednative property descriptors to save space. It was
only possible to use 16 bits of the pointer-sized ints in the structs anyway.
- Do a security check at enumeration time and only expose those properties that
the caller can actually 'Get'. This fixes the toSource security exception
problem.
- Add a big comment about the problem of reporting uncaught exceptions.
- Fix crashing bug for case where object has no enumerable properties and
xpconnect failed to fill in the zero count.
- Fix NewInstanceJSObject to dig in and find the 'ultimate' parent when
parenting new wrapper JSObject. The old scheme was ending up with hugely
long parent chains in some cases.
r=jst, sr=brendan
- Optimize integer ++ and -- to avoid double-to-int, which is quite costly for
some compilers (ftol on Windows with MSVC).
- Optimized arguments[i] and arguments.length references to use bytecodes that
avoid creating an arguments object for the current frame. This entailed
simplifying the compiler to avoid flagging functions and scripts that set
arguments, since we have code in jsfun.c to catch such sets at runtime.
- The code generator now eliminates useless expression statements, giving a
strict warning about them.
- Rationalized jsemit.c's LookupArgOrVar to have well-defined results in *pn.
Eliminate bytecode specializations for argument and local variable gets and
sets from jsparse.c -- these precede jsemit.c's LookupArgOrVar and frustrate
it, by setting pn_slot non-negative too early.
- Code generation errors set report->filename and report->lineno, rather than
hacking "{0}, line {1}: " into the localized message.
- Bogus JSFRAME_VAROBJBUG removed, JSOPTION_VAROBJFIX is sufficient.
- Spruce up jsinterp.c macros to use JS_BEGIN/END_MACRO brackets if possible.
- Avoid calling JS_PropertyStub. The call is too costly compared to a branch
in the caller.
- Optimize integer ++ and -- to avoid double-to-int, which is quite costly for
some compilers (ftol on Windows with MSVC).
- Optimized arguments[i] and arguments.length references to use bytecodes that
avoid creating an arguments object for the current frame. This entailed
simplifying the compiler to avoid flagging functions and scripts that set
arguments, since we have code in jsfun.c to catch such sets at runtime.
- The code generator now eliminates useless expression statements, giving a
strict warning about them.
- Rationalized jsemit.c's LookupArgOrVar to have well-defined results in *pn.
- Code generation errors set report->filename and report->lineno, rather than
hacking "{0}, line {1}: " into the localized message.
- Bogus JSFRAME_VAROBJBUG removed, JSOPTION_VAROBJFIX is sufficient.
- Spruce up jsinterp.c macros to use JS_BEGIN/END_MACRO brackets if possible.
- Avoid calling JS_PropertyStub. The call is too costly compared to a branch
in the caller.
Subject:
minor Rhino bug
Date:
Tue, 23 Jan 2001 13:14:51 -0800
From:
dave russo <d-russo@ti.com>
To:
nboyd@atg.com
CC:
d-russo@ti.com
Norris,
While using the new Rhino debugger (from the latest tip) I started to get "No
Context associated with current Thread" exceptions when expanding host objects
in the "Context:" debugger window.
In looking at the code, I discovered that NativeObject.toString seems to assume
that Context.getContext() may return null. In fact, getContext() always returns
a non-null context or throws an exception.
I changed NativeObject.toString to never throw an exception (see below) and this
eliminated the problem I was seeing (of course).
It would be nice to incorporate this in a future Rhino tip or, if this change is
inappropriate, any guidance would be appreciated. Thanks in advance.
I changed NativeObject.toString to:
public String toString() {
try {
Context cx = Context.getContext();
return jsFunction_toString(cx, this, null, null);
}
catch (Exception e) {
return "[object " + getClassName() + "]";
}
}
from:
public String toString() {
Context cx = Context.getContext();
if (cx != null)
return jsFunction_toString(cx, this, null, null);
else
return "[object " + getClassName() + "]";
}
Re: Small usage simplification for Rhino
Date:
Tue, 23 Jan 2001 16:01:42 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
Norris Boyd <nboyd@atg.com>
References:
1 , 2 , 3 , 4
Norris Boyd wrote:
> Thanks. I've patched in your changes and checked it into CVS.
I also looked at other places with similar pattern of few lines of
common code to construct error messages. The following was occurred too
often not to avoid temptations to move it to a separated function:
NativeGlobal.constructError(
Context.getContext(), "TypeError",
ScriptRuntime.getMessage1("msg.default.value", arg),
this)
It can be replaced by
NativeGlobal.typeError1("msg.default.value", arg, this)
There are other similar usages but they are not to frequent to bother
with code reduction because even the above replacement saves just 200
bytes in uncompressed jars (it is expensive to introduce new methods in
Java).
In any case, if you think it makes any sense, patches are attached. They
are made via
diff -cbB javascript.orig javascript > patch_context
diff -bB javascript.orig javascript > patch_std
from org/mozilla directory.
Regards, Igor
Subject:
Recent rhino broke security support
Date:
Tue, 23 Jan 2001 08:07:45 -0500
From:
"Kurt Westerfeld" <kurt@managedobjects.com>
To:
"Norris Boyd" <nboyd@atg.com>
Norris.....I like the changes made to FunctionObject to do method invocation
much faster. Very slick.
Problem tho: this mechanism does not veer into the security support plugin
on context for defining a class. This is crucial do creating event adapter
code later in applet environments.
I'm going to look into this, but perhaps you could probably make the changes
faster than I.
Unfortunately for us, we found this problem yesterday at a customer site.
:-( Shame on us.
________________________________________________________________________
Kurt Westerfeld
Senior Software Architect
Managed Objects
mailto:kwester@ManagedObjects.com
703.770.7225
http://www.ManagedObjects.com
Managed Objects: manage technology > rule business
mkaply%us.ibm.com
nboyd%atg.com
pschwartau%netscape.com
shaver%mozilla.org
waterson%netscape.com
disttsc%bart.nl
dmose%netscape.com
brendan%mozilla.org
jband%netscape.com
beard%netscape.com
rginda%netscape.com
Peter.VanderBeken%pandora.be
dprice%netscape.com
rogerl%netscape.com
matthias%sorted.org
waldemar%netscape.com
cls%seawood.org
sspitzer%netscape.com
dveditz%netscape.com
dbaron%fas.harvard.edu
jeff.dyer%compilercompany.com