Firefox build (Nightly) thread with root permission
Hi, I have created a new thread in Nightly and the function can be launched while I executed the script: ./mach run Q1: Because my function is related to kernel, root privilege is necessary. Hence, I got the error message as shown in the following: root privileges needed to run this function--- Q2: By running the function with sudo sudo ./mach run Things seem running well. However, the browser can not be launched and it ended without any notice. The following log shown on my terminal root privileges obtained... myDesktop$ Any feedback will be highly appreciated. Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
Joshua Cranmer wrote: MOZ_ASSUME_UNREACHABLE_MARKER tells the compiler that this code and everything after it can't be reached, so it need do anything. Clang will delete the code after this branch and decide to not emit any control flow. I have found this to be unhelpful when debugging because you can't jump into deleted code. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 03/29/2014 02:55 PM, Paolo Amadini wrote: With bug 988122 landing soon, you'll now find a Promise object available by default in the global scope of JavaScript modules. However, this default implementation is still limited, and you're strongly recommended to import Promise.jsm explicitly in new modules: Cu.import(resource://gre/modules/Promise.jsm); This will give you a number of advantages, among others: - Errors don't risk disappearing silently (bug 966452) - Tests will fail if errors are accidentally uncaught (bug 976205) - You can inspect the current state in the debugger (bug 966471) - You can see registered then handlers (bug 966472) - You get better performance on long Promise chains Promise.jsm and Promise are still interoperable from the functional point of view, the difference is in the above non-functional characteristics. Promise.jsm also has better performance due to the fact that it avoids the JavaScript / C++ / JavaScript turnaround time on chain resolution, Has this shown up in profiles? If so, could you please give links to the profiles, since we should get fast promise handling to the web platform. with an optimized resolution loop handling How is this different to the C++ implementation? Based on the code inspection both seem to do pretty much the same thing. Post a runnable to the event loop and then process all the callbacks in on batch. but I don't think this performance part should prevent us from migrating to C++ Promises when the other limitations are addressed. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 3/31/14 1:34 PM, smaug wrote: Promise.jsm and Promise are still interoperable from the functional point of view, the difference is in the above non-functional characteristics. Promise.jsm also has better performance due to the fact that it avoids the JavaScript / C++ / JavaScript turnaround time on chain resolution, Has this shown up in profiles? If so, could you please give links to the profiles, since we should get fast promise handling to the web platform. I don't remember that we did any benchmark on this. I seem to remember that this was an assumption based on a discussion with bz a long time ago, but it might have been someone else. Numbers would be interesting, though. Paolo, do you have plans to perform benchmarking? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 30/03/2014 22.10, Boris Zbarsky wrote: Hmm. I don't think it was clear to anyone working on the DOM/ES6 promises that were were trying to treat them as do not use kind of things. Obviously, that is not what anyone is proposing here :-) DOM Promises are already enabled by default in content, thanks to the great work that has been done on both implementation and specification. We should make sure that chrome code can fully benefit from that work as soon as possible. (We're already seeing a partial benefit, since Promise.jsm is still based on the DOM Promises specification work.) In most cases, code will work exactly in the same way. Sure. But the reason we in my opinion can't just default all scopes to Promise.jsm is that it in fact does _not_ work in exactly the same way in all cases, and people writing green-field code will likely assume a spec-compliant Promise implementation, not just something kinda similar. I also want to clarify that I don't think Promise.jsm should be imported by default in chrome code at this point, despite its advantages. Can we define ready? Is the list of issues you listed in your post at the start of this thread the full list of blockers for dropping Promise.jsm? I've edited bug 939636 to depend on three key issues out of the list I posted before. I think that once those are addressed, there will be no reason to stick to Promise.jsm any longer. It's a reason we can't just default to Promise.jsm, though... For example, would it be sufficiently developer-friendly to log something in this case but proceed instead of throwing? If so, is that something that would make sense to do for ES6 promises as well? Logging things to console is obviously not defined by any specs, so we have wide latitude here. That looks like a good idea to me. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 31/03/2014 13.42, David Rajchenbach-Teller wrote: I don't remember that we did any benchmark on this. I seem to remember that this was an assumption based on a discussion with bz a long time ago, but it might have been someone else. Yes, memory was my source too. On 31/03/2014 13.34, smaug wrote: Based on the code inspection both seem to do pretty much the same thing. Post a runnable to the event loop and then process all the callbacks in on batch. And if that's the case, and the C++ / JavaScript transition does not cost a lot, probably our assumption on performance was wrong. On 31/03/2014 13.42, David Rajchenbach-Teller wrote: Numbers would be interesting, though. Paolo, do you have plans to perform benchmarking? Not at present. I'd like to focus on the blockers, and as I already said I don't think performance is a hard blocker, even if it might be different from one implementation to the other. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox build (Nightly) thread with root permission
On 3/31/14 4:56 AM, Paul wrote: Q1: Because my function is related to kernel, root privilege is necessary. Hence, I got the error message as shown in the following: root privileges needed to run this function--- What function are you talking about? Something in Firefox already, or new code that you are adding? Q2: By running the function with sudo sudo ./mach run Things seem running well. However, the browser can not be launched and it ended without any notice. Firefox is not meant to run with root privileges, and I actually thought we checked and refused to launch in that case. I can't find the bug about it now, though. In any case I strongly discourage running Firefox as root. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 3/31/14 8:18 AM, Paolo Amadini wrote: I've edited bug 939636 to depend on three key issues out of the list I posted before. I think that once those are addressed, there will be no reason to stick to Promise.jsm any longer. Thanks. I'll see what I can do about getting these knocked out. That said, we should probably track all the parity bugs in that bug. Maybe a separate bug on things blocking the switch? It's a reason we can't just default to Promise.jsm, though... For example, would it be sufficiently developer-friendly to log something in this case but proceed instead of throwing? That looks like a good idea to me. I filed bug 990043 on investigating the DOM side of this. Not marking that as blocking bug 939636 for now, but per above I think it probably should. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
On 3/28/14, 7:03 PM, Joshua Cranmer wrote: I included MOZ_ASSUME_UNREACHABLE_MARKER because that macro is the compiler-specific optimize me intrinsic, which I believe was the whole point of the original MOZ_ASSUME_UNREACHABLE. AFAIU, MOZ_ASSUME_UNREACHABLE_MARKER crashes on all Gecko platforms, but I included MOZ_CRASH to ensure the behavior was consistent for all platforms. No, MOZ_ASSUME_UNREACHABLE_MARKER tells the compiler that this code and everything after it can't be reached, so it need do anything. Clang will delete the code after this branch and decide to not emit any control flow. It may crash, but this is in the same vein that reading an uninitialized variable may crash: it can certainly do a lot of wrong and potentially exploitable things first. So what is an example of an appropriate use of MOZ_ASSUME_UNREACHABLE in Gecko today? If we can identify a good example, then perhaps we can create an easier to use solution. If we have no good examples, then we should probably remove this tricky macro. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
2014-03-31 15:22 GMT-04:00 Chris Peterson cpeter...@mozilla.com: On 3/28/14, 7:03 PM, Joshua Cranmer wrote: I included MOZ_ASSUME_UNREACHABLE_MARKER because that macro is the compiler-specific optimize me intrinsic, which I believe was the whole point of the original MOZ_ASSUME_UNREACHABLE. AFAIU, MOZ_ASSUME_UNREACHABLE_MARKER crashes on all Gecko platforms, but I included MOZ_CRASH to ensure the behavior was consistent for all platforms. No, MOZ_ASSUME_UNREACHABLE_MARKER tells the compiler that this code and everything after it can't be reached, so it need do anything. Clang will delete the code after this branch and decide to not emit any control flow. It may crash, but this is in the same vein that reading an uninitialized variable may crash: it can certainly do a lot of wrong and potentially exploitable things first. So what is an example of an appropriate use of MOZ_ASSUME_UNREACHABLE in Gecko today? That's a very good question to ask at this point! Good examples are examples where 1) it is totally guaranteed that the location is unreachable, and 2) the surrounding code is performance-critical for at least some caller. Example 1: Right *after* (not *before* !) a guaranteed crash in generic code, like this one: http://hg.mozilla.org/mozilla-central/file/df7b26e90378/build/annotationProcessors/CodeGenerator.java#l329 I'm not familiar with this code, but, being in a code generator, I can trust that this might be performance critical, and is really unreachable. Example 2: In the default case of a performance-critical switch statement that we have an excellent reason of thinking is completely unreachable. Example: http://hg.mozilla.org/mozilla-central/file/df7b26e90378/js/src/gc/RootMarking.cpp#l42 Again I'm not familiar with this code, but I can trust that it's performance-critical, and since that function is static to this cpp file, I can trust that the callers of this function are only a few local functions that are aware of the fact that it would be very dangerous to call this function with a bad 'kind' (though I wish that were said in a big scary warning). The UNREACHABLE here would typically allow the compiler to skip checking that 'kind' is in range before implementing this switch statement with a jump-table, so, if this code is performance-critical to the point that the cost of checking that 'kind' is in range is significant, then the UNREACHABLE here is useful. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firefox build (Nightly) thread with root permission
Hey BDS, Thanks for your reply. 1. The function I mentioned is the new code I added. 2. I understand that running Firefox with root privileges is not encouraged. However, due to my experiment is related to kernel, root privileges will be necessary to my program. I wiped out my code which was added in Nightly and run sudo ./mach run ---This runs well and Nightly can be launched. However, when I added my code back to Nightly and rebuilt the code, It ended without Nightly launched. I am still confused by this. Please let me know if you have any comment. Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
