|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
|
|
detect useless return valueHello,
I am trying to optimize some of my native functions. My aim is to know in advance if the returned value will be used by the caller. For example my JSClass Socket has a Write() method that send data through a socket and returns the data that has not been sent (overflow). This feature exists but is rarely used, this is why I wondering if it is possible to detect (by looking at the next opcode) if the creation of the returned value is optional. I noticed that the bytecode of functions whose the return value is not used look like this: 00046: 13 callname "MyFct" 00049: 13 call 0 00052: 13 trace 00053: 13 popv Can I say that if there is only a trace opcode between call and popv, the return value of the function will not be used ? Franck. _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valuePerhaps popv need more analysis, but pop, popn and void are simpler to
detect. Franck. _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valuefranck.fr <soubok@...> wrote:
> Perhaps popv need more analysis, but pop, popn and void are simpler to > detect. Yeah, popv basically means, "you need to return a value" since the result might be used by something that is hidden from your view by native frames. If you see a POP, POPN, or VOID opcode, though, you can definitely avoid generating your return value. It would be neat if we gave you an easy way to see this. We've done stuff like this before, e.g. with String.prototype.match) but the problem is that bytecode inspection knocks us off trace (out of the JIT), so we removed it (in that case, the cost of building the resulting object was far greater than the cost of not being able to trace through it). I'm also not exactly sure what the API to do this would look like. -- Blake Kaplan _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return value> I'm also not exactly sure what the API to do this would look like.
I was about to smarty-pantsily suggest __attribute__((noreturn)). Then it crossed my mind that it might be implentable with a special wrapper function: magicalFunction(function { }();); OTOH, POITROAE.. Wes _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valueOn Oct 15, 2:03 am, Blake Kaplan <mrb...@...> wrote:
> franck.fr <sou...@...> wrote: > > Perhaps popv need more analysis, but pop, popn and void are simpler to > > detect. > > Yeah, popv basically means, "you need to return a value" since the result > might be used by something that is hidden from your view by native frames. If > you see a POP, POPN, or VOID opcode, though, you can definitely avoid > generating your return value. > > It would be neat if we gave you an easy way to see this. We've done stuff like > this before, e.g. with String.prototype.match) but the problem is that > bytecode inspection knocks us off trace (out of the JIT), so we removed it (in > that case, the cost of building the resulting object was far greater than the > cost of not being able to trace through it). I'm also not exactly sure what > the API to do this would look like. > -- > Blake Kaplan Yes, I understand the issue with JIT. Another issue is that FastNative doesn't have a frame then it is difficult to use bytecode inspection in the following case: void FastNativeCallNativeFunction( NativeFunction ); Sometimes people use the void operator to mean they don't need the return value, perhaps this information could be processed at compile time and used at runtime to inform the callee that the return value is not needed ? Franck. _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return value> Sometimes people use the void operator to mean they don't need the
return value, +1 - good insight, Franck. Much better than my suggestion! Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valueOn Thu, Oct 15, 2009 at 1:38 PM, franck.fr <soubok@...> wrote:
> Sometimes people use the void operator to mean they don't need the > return value, > perhaps this information could be processed at compile time and used > at runtime to inform the callee that the return value is not needed ? This violates the principle of least surprise. Although usage of "void" is rather esoteric (people really only use it on the web for HREF=javascript: values, right?) it is probably not a good idea that adding void(expr) around an expression expr should change the evaluation of expr. -- http://codebad.com/ _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valueI have seen (void 0) used in JSON (or JSON-like output) to represent a
property which is defined but has no value. That said, I don't think Franck was suggesting "void(expr)"; rather "void expr". Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
|
|
|
Re: detect useless return valueOn 10/16/09 11:15 AM, John J. Barton wrote:
> Wes Garland wrote: >> I have seen (void 0) used in JSON (or JSON-like output) to represent a >> property which is defined but has no value. > > Wes, does that make any sense in Javascript? I think no. Which is why > the language has no void. Uh... Sure it has |void|. See ECMA-262 section 11.4.2; right between the sections about |delete| and |typeof|. -Boris _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
Re: detect useless return valueOn Fri, Oct 16, 2009 at 11:15 AM, John J. Barton
<johnjbarton@...> wrote: > Wes Garland wrote: >> >> I have seen (void 0) used in JSON (or JSON-like output) to represent a >> property which is defined but has no value. > > Wes, does that make any sense in Javascript? I think no. Which is why the > language has no void. It certainly does make sense, and the language does have void as a unary operator (produces undefined, which wasn't always a predefined property of the global). An object can have a property with the value undefined, which is different from having no property by that name. Those cases differ in enumeration, the "in" operator, and visibility of same-named properties on prototype, plus toString/toSource/uneval/JSON.stringify behaviour. Mike _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
|
|
|
Re: detect useless return valueOn Fri, Oct 16, 2009 at 11:47 AM, John J. Barton
<johnjbarton@...> wrote: > Ok, thanks, surprise to me. But it's an operator, not a type or value. It's an operator which produces a value of type (and value!) "undefined", yeah. That's how it's been used in this thread too, afaict. >> An object can have a property with the value undefined, which is >> different from having no property by that name. Those cases differ in >> enumeration, the "in" operator, and visibility of same-named >> properties on prototype, plus toString/toSource/uneval/JSON.stringify >> behaviour. > > How would I create such a property? If I have one, what does toString() say? o = {prop:undefined, otherprop:(void 0); } Play with it! Mike _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
|
|
|
Re: detect useless return valueOn Fri, Oct 16, 2009 at 12:10 PM, John J. Barton
<johnjbarton@...> wrote: >>>> An object can have a property with the value undefined, which is >>>> different from having no property by that name. >>> >>> How would I create such a property? If I have one, what does toString() >>> say? >> >> o = {prop:undefined, otherprop:(void 0); } > > But the operator |(void 0)| evaluates here produces a value "undefined", so > that the object 'o' has two defined properties, both with value "undefined". Yes, indeed -- I was just showing two ways. They both create such a property, as you asked. Mike _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
|
|
|
Re: detect useless return valueOn Fri, Oct 16, 2009 at 12:25 PM, John J. Barton
<johnjbarton@...> wrote: > Ok, but Wes said "a property which is defined but has no value", whereas > these cases are "a property which has the value 'undefined'". Yes, the name of "undefined" is bad and confusing. Hindsight! A property is defined if it is present, though it can have as a value the value |undefined| (as produced by "void 0" or accessing an undefined property). > I don't think > this distinction means much, except that I don't see why JSON needs (void 0) > when it just means 'undefined'. |undefined| relies on a global property that is present by default, but can be reassigned by crazy people. (void 0) is a context-independent language expression. Mike _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
|
|
|
|
|
Re: detect useless return valueOn Fri, Oct 16, 2009 at 12:38 PM, Boris Zbarsky <bzbarsky@...> wrote:
> On 10/16/09 11:16 AM, Mike Shaver wrote: >> >> An object can have a property with the value undefined, which is >> different from having no property by that name. Those cases differ in >> enumeration, the "in" operator, and visibility of same-named >> properties on prototype, plus toString/toSource/uneval/JSON.stringify >> behaviour. > > Although it looks like our JSON.stringify drops props whose value is > |undefined|: > > javascript:var o = { x: undefined }; alert(JSON.stringify(o)) > > Bug needs filing? On the other hand, Safari has the same behavior... No, shaver needs reminding. Thanks. Mike _______________________________________________ dev-tech-js-engine mailing list dev-tech-js-engine@... https://lists.mozilla.org/listinfo/dev-tech-js-engine |
| Free embeddable forum powered by Nabble | Forum Help |