Jump to content

h4writer

Community Members
  • Content Count

    11
  • Joined

  • Last visited

  • Days Won

    1

h4writer last won the day on July 10 2013

h4writer had the most liked content!

Community Reputation

4 Neutral

About h4writer

  • Rank
    Discens
  1. That's one of the reasons I try not to use for ... in. The order isn't specified. If it is really important to get the same order, I would keep a property that contains the properties by name in the right order. You can keep that "order" variable on the object and adjust whenever a property get's deleted/added ... var obj = { "prop2": 1 "prop3": 2 "prop4": 3 } obj.order = ["prop2", "prop3", "prop4"]; for (var i=0; i < obj.order.length; i++) { var key = obj.order[i]; callback(key, obj[key]); }
  2. Thanks for the graphs. Would it be possible to increase the zoom level. I mostly try to make sure the whole graph is visible on the screen. Maybe here you could try to have it visible in twice the screen height? That way you have an overview and still have enough information ...
  3. Implement JSOP_SETRVAL and JSOP_RETRVAL (should apply to v24) https://bugzilla.mozilla.org/show_bug.cgi?id=890722 Fix bailing of LCallGeneric: https://bugzilla.mozilla.org/show_bug.cgi?id=891910 Quick and dirty fix for GetPopertyPolymorphicV. This doesn't fix the real issue and could actually decrease performance. I'm not sure yet what the right fix is, but this removes the constant bailing from that bytecode: diff --git a/js/src/ion/BaselineInspector.cpp b/js/src/ion/BaselineInspector.cpp --- a/js/src/ion/BaselineInspector.cpp +++ b/js/src/ion/BaselineInspector.cpp @@ -100,18 +100,18 @@ Bas
  4. I have been looking into the issues surrounding the JS engine and how to improve performance by having better code (i.e taking more use of IonMonkey). So we have bailouts (temporary go to baseline again) and invalidation (delete the IM code) in this code. From high to low this is: 1) MCallGeneric 2) GetPopertyPolymorphicV 3) BoundsChecks 4) ValueToInt32 1) MCallGeneric is the generic code used in IonMonkey to call to a function. Normally in the browser the JSObject to where the call takes place is always a JSFunction. Here that isn't the case, since I assume you added your own JSObject's and o
  5. So in most cases we will use JSOP_RETURN to indicate a return. But for some returns we need to do more e.g. close open try blocks. In that case JSOP_SETRVAL is used to set the value and the extra code is executed followed by JSOP_RETRVAL to return the value. So that is happening here. Apparently we don't compile those bytecodes yet. (Happens most often with try blocks what isn't supported by IM). So the problem here is the "return" in the for-in loop. Opened https://bugzilla.mozilla.org/show_bug.cgi?id=890722 to fix this. 1) I think the patch to support it will be fairly small. So if you want
  6. I know that's unfortunate, but it will create much better type information and be much faster. There are different solutions for that problem though, 1) if entities_ is small, you can recreate that object when wanting to delete a property. 2) you can have an array with all "available keys" and recreate the array when you remove a poperty. 3) If the value in entities[x] is never undefined, I would just check it in the loop and just "continue;" That seems very strange! We don't need an arguments object there...
  7. Sorry about the delay. Next week I'll be more responsive. I've got all the important stuff done now. I looked to the BoundsCheck issue and it definitely looks like an issue of IonMonkey. It should remember an element was set out of bound and when recompiling using a alternate version that doesn't bail in this case. I still have to look why and create a patch. I hope I can create a patch this weekend. Else I will provide one in the beginning of next week. Thanks for reporting! About "OSR script has argsobj". You can see which script it is, by providing IONFLAGS=scripts,aborts. The line before t
  8. I do not know the details (yet) about that part. So I could ask it on irc myself. But I suggest you do it yourself? Since that way you will get the most information about what is possible and not and how to work around it. I think Luke (:luke) would be the best person to ask it. He is stationed in Mountain View, but is online from 18h CEST. If getting online on those times is hard, you can always mail him. (luke AT mozilla . com). I introduced him yesterday to this project, since he didn't know it yet . https://blog.mozilla.org/luke/2012/01/24/jsruntime-is-now-officially-single-threaded/
  9. About the rounding errors. Yes I think the last comment is still valid and I don't think that will change soon. I'm sure that we use one NaN representation in the JIT. Since that makes our live easier. I actually assumed that is also the case in the interpreter? If NaN is the same across platform is another question. I can ask around if you want to know. That is a flag mostly for fuzzers. It contains little hacks to make life easier for them. To make scripts more deterministic in output/behaviour. E.g. last bug I can remember (not implemented yet) is don't show the compilation time of asm.js
  10. Running code in JIT or the interpreter shouldn't make a difference. So we definitely care for these issues! That was an issue reported by Gary and is about an problem in JM/TM vs the interpreter. Both are removed now in favor of IM. I'm not gonna pretend we don't have these issues in IM, but we try to fix them. Gkw, decoder and Jesse are running special bots to find these issues. Now and than they pop up during differential testing. So reporting bugs about that is highly welcome! Just reading the bugs, I don't think we can do much about floating point issues on different platforms, though that
  11. About the constant hitting bound check. I'm not sure this is a JS error, it could potentially be an IonMonkey issue. I'm willing to look into it and fix it if you can provide me a shell version of it. About the messages: [Abort] Script too large (2149 bytes) This is telling me you are running a non-threadsafe build. Therefore you don't have parallel compilation and we cap the max script size to 2000 bytes. You should really try a threadsafe build. (That's the default in the browser). The maximum script is 20000bytes and compilation happens on background thread. Should give a nice performance b
×
×
  • Create New...