Re: PSA: RIP MOZ_ASSUME_UNREACHABLE

Great work Chris! Thanks for linking to the study; the link gives me error 400, github links are tricky: 2014-09-22 4:06 GMT-04:00 Chris Peterson : > [1] https://raw.githubusercontent.com/bjacob/builtin-unreachable-study > Repo link: https://github.com/bjacob/builtin-unreachable-study Notes file

Re: Getting rid of already_AddRefed?

As far as I know, the only downside in replacing already_AddRefed by nsCOMPtr would be to incur more useless calls to AddRef and Release. In the case of "threadsafe" i.e. atomic refcounting, these use atomic instructions, which might be expensive enough on certain ARM CPUs that this might matter. S

Re: Building with a RAM disk

9 1:40 GMT-04:00 Geoff Lankow : > Ah yes, I forgot to say. I am on Linux. I've found using RAM instead of my > (mechanical) disk saves about 5 minutes of a roughly half-hour build. > > GL > > > On 19/07/14 16:24, Benoit Jacob wrote: > >> What OS are we talkin

Re: Building with a RAM disk

What OS are we talking about? (On Linux, ramdisks are mountpoints like any other so that would be trivial; but then again, on Linux, the kernel is good enough at using extra RAM for disk cache automatically, that you get the benefits of a RAMdisk automatically). Benoit 2014-07-18 22:39 GMT-04:0

Re: PSA: DebugOnly<> fields aren't zero-sized in non-DEBUG builds

That sounds like a good idea, if possible. 2014-07-16 14:41 GMT-04:00 Ehsan Akhgari : > Should we make DebugOnly MOZ_STACK_CLASS? > > > On 2014-07-15, 9:21 PM, Nicholas Nethercote wrote: > >> Hi, >> >> The comment at the top of mfbt/DebugOnly.h includes this text: >> >> * Note that DebugOnly i

Re: PSA: DebugOnly<> fields aren't zero-sized in non-DEBUG builds

It may be worth reminding people that this is not specific to DebugOnly but general to all C++ classes: In C++, there is no such thing as a class with size 0. So expecting DebugOnly to be of size 0 is not misunderstanding DebugOnly, it is misunderstanding C++. The only way to have empty classes beh

Re: Firefox heap-textures usage

Please file a bug on bugzilla, product: Core, component: Graphics, and CC bas.schouten. This about:memory report says you have 4G of textures; that seems too much; and the fact that 'explicit' is above 4G suggests that that is for real and not just a bug in this counter-based memory reporter. Beno

Re: What are the most important new APIs to document in Q3/Q4?

2014-06-26 9:09 GMT-04:00 Eric Shepherd : > Hi! The docs team is trying to build our schedule for the next quarter or > two, and part of that is deciding which APIs to spend lots of our time > writing about. I'd like to know what y'all think the most important APIs > are for docs attention in the

Re: PSA: Refcounted classes should have a non-public destructor & should be MOZ_FINAL where possible

Here's an update on this front. In Bug 1027251 we added a static_assert as discussed in this thread, which discovered all remaining instances, and we fixed the easy ones, which were the majority. The harder ones have been temporarily whitelis

Re: C++ standards proposals of potential interest, and upcoming committee meeting

2014-06-09 16:27 GMT-04:00 Jet Villegas : > It seems healthy for the core C++ language to explore new territory here. > Modern primitives for things like pixels and colors would be a good thing, > I think. Let the compiler vendors compete to boil it down to the CPU/GPU. In the Web world, we have

Re: C++ standards proposals of potential interest, and upcoming committee meeting

2014-06-09 16:12 GMT-04:00 Benoit Jacob : > > > > 2014-06-09 15:56 GMT-04:00 Botond Ballo : > > - Original Message - >> > From: "Benoit Jacob" >> > To: "Botond Ballo" >> > Cc: "dev-platform" >> >

Re: C++ standards proposals of potential interest, and upcoming committee meeting

2014-06-09 15:56 GMT-04:00 Botond Ballo : > - Original Message - > > From: "Benoit Jacob" > > To: "Botond Ballo" > > Cc: "dev-platform" > > Sent: Monday, June 9, 2014 3:45:20 PM > > Subject: Re: C++ standards pr

Re: C++ standards proposals of potential interest, and upcoming committee meeting

2014-06-09 15:31 GMT-04:00 Botond Ballo : > Cairo-based 2D drawing API (latest revision): > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4021.pdf > I would like the C++ committee's attention to be drawn to the dangers, for committee, to try to make decisions outside of its domain of

Re: Intent to implement: DOMMatrix

2014-06-08 8:56 GMT-04:00 : > On Monday, June 2, 2014 12:11:29 AM UTC+2, Benoit Jacob wrote: > > My ROI for arguing on standards mailing on matrix math topics lists has > > been very low, presumably because these are specialist topics outside of > > the area of expe

Re: Intent to implement: DOMMatrix

2014-06-07 12:49 GMT-04:00 L. David Baron : > On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: > > - change isIdentity() so it's a flag. > > I'm a little worried about this one at first glance. > > I suspect isIdentity is going to be used primarily for optimization. > But we want optimization

Re: Intent to implement: DOMMatrix

2014-06-05 18:59 GMT-04:00 Matt Woodrow : > On 6/06/14 12:05 am, Benoit Jacob wrote: > >> >> The situation isn't symmetric: radians are inherently simpler to implement >> (thus slightly faster), basically because only in radians is it true that >> sin(x) ~= x f

Re: Intent to implement: DOMMatrix

2014-06-05 9:08 GMT-04:00 Rik Cabanier : > > > > On Thu, Jun 5, 2014 at 5:05 AM, Benoit Jacob > wrote: > >> >> >> >> 2014-06-05 2:48 GMT-04:00 Rik Cabanier : >> >> >>> >>> >>> On Wed, Jun 4, 2014 at 2:20 PM

Re: Intent to implement: DOMMatrix

2014-06-05 2:48 GMT-04:00 Rik Cabanier : > > > > On Wed, Jun 4, 2014 at 2:20 PM, Milan Sreckovic > wrote: > >> In general, is “this is how it worked with SVGMatrix” one of the design >> principles? >> >> I was hoping this would be the time matrix rotate() method goes to >> radians, like the canva

Re: Intent to implement: DOMMatrix

2014-06-04 20:28 GMT-04:00 Cameron McCormack : > On 05/06/14 07:20, Milan Sreckovic wrote: > >> In general, is “this is how it worked with SVGMatrix” one of the >> design principles? >> >> I was hoping this would be the time matrix rotate() method goes to >> radians, like the canvas rotate, and un

Re: Intent to implement: DOMMatrix

2014-06-03 18:29 GMT-04:00 Robert O'Callahan : > On Wed, Jun 4, 2014 at 10:26 AM, Rik Cabanier wrote: > >> That would require try/catch around all the "invert()" calls. This is ugly >> but more importantly, it will significantly slow down javascript >> execution. >> I'd prefer that we don't throw

Re: Intent to implement: DOMMatrix

2014-06-03 18:26 GMT-04:00 Rik Cabanier : > > > > On Tue, Jun 3, 2014 at 2:40 PM, Benoit Jacob > wrote: > >> >> >> >> 2014-06-03 17:34 GMT-04:00 Benoit Jacob : >> >> >>> >>> >>> 2014-06-03 16:20 GMT-04:00 R

Re: Intent to implement: DOMMatrix

2014-06-03 17:34 GMT-04:00 Benoit Jacob : > > > > 2014-06-03 16:20 GMT-04:00 Rik Cabanier : > > >> >> >> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob >> wrote: >> >>> >>> >>> >>> 2014-06-03 3:34 GMT-04:

Re: Intent to implement: DOMMatrix

2014-06-03 16:20 GMT-04:00 Rik Cabanier : > > > > On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob > wrote: > >> >> >> >> 2014-06-03 3:34 GMT-04:00 Dirk Schulze : >> >> >>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob >>> wrote

Re: Intent to implement: DOMMatrix

enoit 2014-06-03 13:23 GMT-04:00 Rik Cabanier : > > > > On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob > wrote: > >> >> >> >> 2014-06-03 3:34 GMT-04:00 Dirk Schulze : >> >> >>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob >>> wrote

Re: Intent to implement: DOMMatrix

2014-06-02 23:45 GMT-04:00 Rik Cabanier : > To recap I think the following points have been resolved: > - remove determinant (unless someone comes up with a strong use case) > - change is2D() so it's a flag instead of calculated on the fly > - change isIdentity() so it's a flag. > - update constru

Re: Intent to implement: DOMMatrix

2014-06-03 3:34 GMT-04:00 Dirk Schulze : > > On Jun 2, 2014, at 12:11 AM, Benoit Jacob > wrote: > > > Objection #6: > > > > The determinant() method, being in this API the only easy way to get > > something that looks roughly like a measure of invertibility,

Re: Intent to implement: DOMMatrix

2014-06-02 17:13 GMT-04:00 Rik Cabanier : > > > > On Mon, Jun 2, 2014 at 11:08 AM, Benoit Jacob > wrote: > >> >> >> >> 2014-06-02 14:06 GMT-04:00 Benoit Jacob : >> >> >>> >>> >>> 2014-06-02 13

Re: Intent to implement: DOMMatrix

2014-06-02 13:56 GMT-04:00 Nick Alexander : > On 2014-06-02, 9:59 AM, Rik Cabanier wrote: > >> >> >> >> On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander > > wrote: >> >> On 2014-06-02, 4:59 AM, Robert O'Callahan wrote: >> >> On Mon, Jun 2, 2014 at 3:19 PM,

Re: Intent to implement: DOMMatrix

2014-06-02 14:06 GMT-04:00 Benoit Jacob : > > > > 2014-06-02 13:56 GMT-04:00 Nick Alexander : > > On 2014-06-02, 9:59 AM, Rik Cabanier wrote: >> >>> >>> >>> >>> On Mon, Jun 2, 2014 at 9:05 AM, Nick Alexander >> <mailto:nalex

Re: Intent to implement: DOMMatrix

2014-06-02 7:59 GMT-04:00 Robert O'Callahan : > On Mon, Jun 2, 2014 at 3:19 PM, Rik Cabanier wrote: > >> isIdentity() indeed suffers from rounding errors but since it's useful, >> I'm >> hesitant to remove it. >> In our rendering libraries at Adobe, we check if a matrix is *almost* >> identity. M

Re: Intent to implement: DOMMatrix

2014-06-01 23:19 GMT-04:00 Rik Cabanier : > > > > On Sun, Jun 1, 2014 at 3:11 PM, Benoit Jacob > wrote: > >> >> >> >> 2014-05-31 0:40 GMT-04:00 Rik Cabanier : >> >> Objection #3: >>>> >>>> I dislike the way tha

Re: Intent to implement: DOMMatrix

2014-05-31 0:40 GMT-04:00 Rik Cabanier : > Objection #3: >> >> I dislike the way that this API exposes multiplication order. It's not >> obvious enough which of A.multiply(B) and A.multiplyBy(B) is doing A=A*B >> and which is doing A=B*A. >> > > The "by" methods do the transformation in-place. In

Re: Intent to implement: DOMMatrix

I never seem to be able to discourage people from dragging the W3C into specialist topics that are outside its area of expertise. Let me try again. Objection #1: The skew* methods are out of place there, because, contrary to the rest, they are not geometric transformations, they are just arithmet

Re: PSA: Refcounted classes should have a non-public destructor & should be MOZ_FINAL where possible

Actually that test program contradicts what I said --- my IsDestructorPrivateOrDeleted produces exactly the same result as !is_destructible, and is_destructible does return 0 for the class with private destructor. So you could just use that! Benoit 2014-05-28 16:51 GMT-04:00 Benoit Jacob

Re: PSA: Refcounted classes should have a non-public destructor & should be MOZ_FINAL where possible

Awesome work! By the way, I just figured a way that you could static_assert so that at least on supporting C++11 compilers, we would automatically catch this. The basic C++11 tool here is std::is_destructible from , but it has a problem: it only returns false if the destructor is deleted, it does

Re: Do we still need Trace Malloc?

2014-05-19 23:19 GMT-04:00 L. David Baron : > On Monday 2014-05-19 20:09 -0700, Nicholas Nethercote wrote: > > On Mon, May 19, 2014 at 5:32 PM, L. David Baron > wrote: > > > Another is being able to find the root strongly connected components > > > of the memory graph, which is useful for finding

Re: Intent to implement and ship: navigator.hardwareConcurrency

2014-05-19 23:37 GMT-04:00 Rik Cabanier : > > > > On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob wrote: > >> +1000! Thanks for articulating so clearly the difference between the >> Web-as-an-application-platform and other application platforms. >> > > It

Re: Intent to implement and ship: navigator.hardwareConcurrency

+1000! Thanks for articulating so clearly the difference between the Web-as-an-application-platform and other application platforms. Benoit 2014-05-19 21:35 GMT-04:00 Jonas Sicking : > On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: > > I don't see why the web platform is special here a

Re: Intent to implement and ship: navigator.hardwareConcurrency

Also note that even some popular desktop APIs that in practice expose the "hardware" thread count, choose not to call it that way. For example, Qt calls it the "ideal" thread count. http://qt-project.org/doc/qt-4.8/qthread.html#idealThreadCount IMO this suggests that we're not the only ones feel

Re: nsRefPtr vs RefPtr

st overloads of global functions. Benoit 2014-05-13 8:04 GMT-04:00 Benoit Jacob : > If the semantics difference between TemporaryRef and already_AddRefed are > the main factor blocking us here, could we at least make progress by > temporarily having the two coexist, i.e. a transition p

Re: nsRefPtr vs RefPtr

If the semantics difference between TemporaryRef and already_AddRefed are the main factor blocking us here, could we at least make progress by temporarily having the two coexist, i.e. a transition plan roughly as follows: 1) Introduce a nsTemporaryRef behaving like TemporaryRef but cooperating wi

Re: nsRefPtr vs RefPtr

2014-05-11 23:40 GMT-04:00 Boris Zbarsky : > On 5/11/14, 7:50 PM, Chris Pearce wrote: > >> Should we be preferring mozilla::RefPtr in new code? >> >> Should we be replacing nsRefPtr with mozilla::RefPtr? >> > > I would err on "no" for both, given https://bugzilla.mozilla.org/ > show_bug.cgi?id=820

Re: PSA: nsTArray lengths and indices are now size_t (were uint32_t)

other.mIndex) {} bool Found() const { return mIndex != NoIndex; } index_type Value() const { MOZ_ASSERT(Found()); return mIndex; } }; Benoit 2014-05-11 10:25 GMT-04:00 Ehsan Akhgari : > On 2014-05-11, 10:15 AM, Benoit Jacob wrote: > >> Hi, >> >> Since Bu

PSA: nsTArray lengths and indices are now size_t (were uint32_t)

Hi, Since Bug 1004098 landed, the type of nsTArray lengths and indices is now size_t. Code using nsTArrays is encouraged to use size_t for indexing them; in most cases, this does not really matter; however there is one case where this does matter, which is when user code stores the result of nsTA

Re: Time to revive the "require SSE2" discussion

2014-05-09 13:24 GMT-04:00 Rik Cabanier : > > > > On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob wrote: > >> Totally agree that 1% is probably still too much to drop, but the 4x drop >> over the past two years makes me hopeful that we'll be able to drop >> n

Re: Time to revive the "require SSE2" discussion

evidence that the stuff from > http://www.palemoon.org/technical.shtml#speed , which AFAICT are the only > perf numbers that have been cited in this thread? > > > On Fri, May 9, 2014 at 10:14 AM, Benoit Jacob wrote: > >> Totally agree that 1% is probably still too much to d

Re: Time to revive the "require SSE2" discussion

millions of people. > > chris > > > > On 5/8/14, 5:42 PM, matthew.br...@gmail.com wrote: > >> On Tuesday, January 3, 2012 4:37:53 PM UTC-8, Benoit Jacob wrote: >> >>> 2012/1/3 Jeff Muizelaar : >>> >>> >>>> >>>

Re: Time to revive the "require SSE2" discussion

Wonderful, thanks Matthew! @Stability-team: ^^^ see the value of public crashdata CSV files in action! Thanks! Benoit 2014-05-08 20:42 GMT-04:00 : > On Tuesday, January 3, 2012 4:37:53 PM UTC-8, Benoit Jacob wrote: > > 2012/1/3 Jeff Muizelaar : > > > > > > > &

Re: Intent to implement: WebGL 2.0

2014-05-08 5:53 GMT-04:00 Anne van Kesteren : > It seems like you want to be able to do that going forward so you > don't have to maintain a large matrix forever, but at some point say > you drop the idea that people will want 1 and simply return N if they > ask for 1. Yes, that's what we agreed

Re: Intent to implement: WebGL 2.0

2014-05-07 15:09 GMT-04:00 Ehsan Akhgari : > We had a meeting about this today, and there is one big issue with my > proposal above. Because of the fact that extra dictionary members in the > contextOptions arguments are ignored, this means that UA engines which have > already shipped their imple

Re: Intent to implement: WebGL 2.0

2014-05-07 14:14 GMT-04:00 Boris Zbarsky : > On 5/7/14, 2:00 PM, Benoit Jacob wrote: > >> The idea is that if getContext("webgl", {version : N}) returns non-null, >> then the resulting context is guaranteed to be WebGL version N, so that >> no other versionin

Re: Intent to implement: WebGL 2.0

2014-05-07 13:41 GMT-04:00 Boris Zbarsky : > On 5/7/14, 12:34 PM, Ehsan Akhgari wrote: > >> Implementations are free to return a context that implements a higher >> version, should that be appropriate in the future, but never lower. >> > > As pointed out, this fails the explicit opt-in bit. > > Th

Re: Intent to implement: WebGL 2.0

This looks great, modulo one detail: 2014-05-07 12:34 GMT-04:00 Ehsan Akhgari : > > I discussed the requirements of this API in person with vlad and bjacob. > Here are two key things to keep in mind: > > 1. The WebGL working group wants web pages to opt in to the WebGL2 > specific parts of the

Re: Intent to implement: WebGL 2.0

2014-05-06 18:41 GMT-04:00 Jonas Sicking : > I disagree with several points of this email. > > On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob > wrote: > > So, thinking more about this, here's what I think is the deeper concern > > here. > > > > If we ma

Re: Intent to implement: WebGL 2.0

a decade. Benoit 2014-05-06 13:07 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:53 PM, Benoit Jacob wrote: > >> Ah, I see the confusion now. So the first reason why what you're >> suggesting >> wouldn't work for WebGL is that WebGL extension my add functionality >

Re: Intent to implement: WebGL 2.0

2014-05-06 13:15 GMT-04:00 Ralph Giles : > On 2014-05-06 9:53 AM, Benoit Jacob wrote: > > > By default, WebGL does not allow FLOAT to be passed for > > the type parameter of the texImage2D method. The OES_texture_float > > extension make that allowed. > > I have

Re: Intent to implement: WebGL 2.0

2014-05-06 13:07 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:53 PM, Benoit Jacob wrote: > >> Ah, I see the confusion now. So the first reason why what you're >> suggesting >> wouldn't work for WebGL is that WebGL extension my add functionality >> without c

Re: Intent to implement: WebGL 2.0

2014-05-06 12:53 GMT-04:00 Benoit Jacob : > > > > 2014-05-06 12:32 GMT-04:00 Boris Zbarsky : > > On 5/6/14, 12:25 PM, Benoit Jacob wrote: >> >>> To what extent does what I wrote in my previous email, regarding >>> interactions between different extension

Re: Intent to implement: WebGL 2.0

2014-05-06 12:32 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:25 PM, Benoit Jacob wrote: > >> To what extent does what I wrote in my previous email, regarding >> interactions between different extensions, answer your question? >> > > I'm not sure it answers

Re: Intent to implement: WebGL 2.0

2014-05-06 12:11 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:03 PM, Benoit Jacob wrote: > >> Indeed, the alternative to doing WebGL2 >> is to expose the same functionality as a collection of WebGL 1 extensions >> > > I think Anne's question, if I understood it

Re: Intent to implement: WebGL 2.0

2014-05-06 11:04 GMT-04:00 Anne van Kesteren : > On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann > wrote: > > I think Khronos made a bad experience with backwards compatible APIs > > during OpenGL's history. They maintained a compatible API for OpenGL for > > ~15 years until it was huge and cru

Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic

2014-04-28 14:18 GMT-04:00 Trevor Saunders : > On Mon, Apr 28, 2014 at 02:07:07PM -0400, Benoit Jacob wrote: > > 2014-04-28 12:17 GMT-04:00 Birunthan Mohanathas < > birunt...@mohanathas.com>: > > > > > On 28 April 2014 14:18, Benoit Jacob wrote: > > > &

Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic

2014-04-28 12:17 GMT-04:00 Birunthan Mohanathas : > On 28 April 2014 14:18, Benoit Jacob wrote: > > Question: is there a plan to switch to an implementation based on > variadic > > templates when we will stop supporting compilers that don't support > them? Do > >

Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic

2014-04-28 0:18 GMT-04:00 Birunthan Mohanathas : > Bugs 900903 and 900908 introduced variadic variants of > NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION, > etc. and removed the old numbered macros. So, instead of e.g. > NS_IMPL_ISUPPORTS2(nsFoo, nsIBar, nsIBaz), simply use

Re: Policing dead/zombie code in m-c

2014-04-25 3:31 GMT-04:00 Henri Sivonen : > On Thu, Apr 24, 2014 at 4:20 PM, Benoit Jacob > wrote: > > 2014-04-24 8:31 GMT-04:00 Henri Sivonen : > > > >> I have prepared a queue of patches that removes Netscape-era (circa > >> 1999) internationalizatio

Re: Policing dead/zombie code in m-c

2014-04-24 8:31 GMT-04:00 Henri Sivonen : > I have prepared a queue of patches that removes Netscape-era (circa > 1999) internationalization code that efforts to implement the Encoding > Standard have shown unnecessary to have in Firefox. This makes libxul > on ARMv7 smaller by 181 KB, so that's a

Re: Oculus VR support & somehwat-non-free code in the tree

with what we support. There's no magic here; we don't get the above 2) point for free. Benoit > > Andreas > > On Apr 15, 2014, at 2:57 PM, Robert O'Callahan > wrote: > > > On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob >wrote: > > > >> If

Re: Oculus VR support & somehwat-non-free code in the tree

2014-04-14 18:41 GMT-04:00 Vladimir Vukicevic : > 3. We do nothing. This option won't happen: I'm tired of not having Gecko > and Firefox at the forefront of web technology in all aspects. > Is VR already "Web technology" i.e. is another browser vendor already exposing this, or would we be the f

Re: mozilla::Atomic considered harmful

2014-04-02 11:03 GMT-04:00 Honza Bambas : > On 4/2/2014 11:33 AM, Nicolas B. Pierron wrote: > >> >> --lock(mRefCnt); >> if (lock(mRefCnt) == 0) { >>delete this; >> } >> >> This way, this is more obvious that we might not be doing the right >> things, as long as we are careful to refuse AtomicH

Re: mozilla::Atomic considered harmful

2014-04-01 18:40 GMT-04:00 Jeff Walden : > On 04/01/2014 02:32 PM, Ehsan Akhgari wrote: > > What do people feel about my proposal? Do you think it improves writing > > and reviewing thread safe code to be less error prone? > > As I said in the bug, not particularly. I don't think you can program

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-04-01 10:57 GMT-04:00 Benjamin Smedberg : > On 4/1/2014 10:54 AM, Benoit Jacob wrote: > >> Let's see if we can wrap up this conversation soon now. How about: >> >> MOZ_MAKE_COMPILER_BELIEVE_IS_UNREACHABLE >> > I counter-propose that we remove th

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-28 17:14 GMT-04:00 Benoit Jacob : > > 2014-03-28 16:48 GMT-04:00 L. David Baron : > > On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote: >> > My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE. >> > >> > I

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-04-01 3:58 GMT-04:00 Benoit Jacob : > * Remove jump table bounds checks (See a.cpp; allowing to abuse a jump > table to jump to an arbitrary address); > Just got an idea: we could market this as "WebJmp, exposing the jmp instruction to the Web" ? We could build a pre

Re: MOZ_ASSUME_UNREACHABLE is being misused

imull %edi, %eax addl$1, %eax divl%ecx ret .cfi_endproc 2014-03-28 12:25 GMT-04:00 Benoit Jacob : > Hi, > > Despite a helpful, scary comment above its definition in > mfbt/Assertions.h, MOZ_ASSUME_UNREACHABLE is being misused. Not pointin

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-31 15:22 GMT-04:00 Chris Peterson : > 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. >>> >>>

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-28 17:14 GMT-04:00 Benoit Jacob : > > 2014-03-28 16:48 GMT-04:00 L. David Baron : > > On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote: >> > My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE. >> > >> > I

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-28 17:19 GMT-04:00 Mike Habicher : > MOZ_UNDEFINED_BEHAVIOUR() ? Undefined behaviour is usually enough to > get C/++ programmers' attention. > I thought about that too; then I remembered that it is only at least a year _after_ some time at Mozilla working on Gecko, that I started appre

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-28 16:48 GMT-04:00 L. David Baron : > On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote: > > My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE. > > > > It's really handy to have something like MOZ_ASSERT_UNREACHABLE, instead > of having a bunch of MOZ_ASSERT(false,

Re: MOZ_ASSUME_UNREACHABLE is being misused

2014-03-28 13:23 GMT-04:00 Chris Peterson : > On 3/28/14, 12:25 PM, Benoit Jacob wrote: > >> Should we give typical code a macro that does what they want and sounds >> like what they want? Really, what typical code wants is a no-operation >> instead of undefined-behavior;

MOZ_ASSUME_UNREACHABLE is being misused

Hi, Despite a helpful, scary comment above its definition in mfbt/Assertions.h, MOZ_ASSUME_UNREACHABLE is being misused. Not pointing fingers to anything specific here, but see http://dxr.mozilla.org/mozilla-central/search?q=MOZ_ASSUME_UNREACHABLE&case=true. The only reason why one might want an

Re: We live in a memory-constrained world

http://en.wikipedia.org/wiki/Plain_Old_Data_Structures confirms that POD can't have a vptr :-) Benoit 2014-02-28 7:39 GMT-05:00 Henri Sivonen : > On Fri, Feb 28, 2014 at 1:04 PM, Neil wrote: > > At least under MSVC, they have vtables, so they need to be constructed, > so > > they're not stat

Re: Cairo being considered as the basis of a standard C++ drawing API

P.S. The 1% figure there was a bit harsh, make it 5%... 2014-02-24 7:49 GMT-05:00 Benoit Jacob : > From your blog post: > >> SG 13′s main intended purpose for such an API is to allow people learning >> C++ and writing graphical applications to do so easily, without having t

Re: Cairo being considered as the basis of a standard C++ drawing API

From your blog post: > SG 13′s main intended purpose for such an API is to allow people learning > C++ and writing graphical applications to do so easily, without having to > rely on third-party libraries or learning complex APIs. In the long-term, > however, they would like the drawing API to be

Re: List of deprecated constructs [was Re: A proposal to reduce the number of styles in Mozilla code]

2014/1/7 Kyle Huey > On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob wrote: > >> For example, if I'm scanning a function for possible early returns (say >> I'm >> debugging a bug where we're forgetting to close or delete a thing before >> returning)

Re: List of deprecated constructs [was Re: A proposal to reduce the number of styles in Mozilla code]

2014/1/7 Neil > Benoit Jacob wrote: > > I would like a random voice in favor of deprecating NS_ENSURE_* for the >> reason that hiding control flow behind macros is IMO one of the most evil >> usage patterns of macros. >> >> So you're saying that > >

Re: List of deprecated constructs [was Re: A proposal to reduce the number of styles in Mozilla code]

2014/1/7 L. David Baron > On Tuesday 2014-01-07 09:13 +0100, Ms2ger wrote: > > On 01/07/2014 01:11 AM, Joshua Cranmer 🐧 wrote: > > >Since Benjamin's message of November 22: > > > news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org > > > > >(search for "Please

Re: Can we start using C++ STL containers in Mozilla code?

2013/12/10 Chris Pearce > It seems to me that we should be optimizing for developer productivity > first, and use profiling tools to find code that needs to be optimized. > > i.e. we should be able to use STL containers where we need basic ADTs in > day-to-day coding, and if instances of these co

Re: Can we start using C++ STL containers in Mozilla code?

2013/12/10 smaug > On 12/10/2013 11:28 AM, Chris Pearce wrote: > >> Hi All, >> >> Can we start using C++ STL containers like std::set, std::map, std::queue >> in Mozilla code please? Many of the STL containers are more convenient to >> use than our equivalents, and more familiar to new contributo

Re: Can we start using C++ STL containers in Mozilla code?

ainer-class memory reporting, so that we can at least know how much memory is taken by all std::set 's together. Just so we know if that ever becomes a significant portion of dark matter. Benoit 2013/12/10 Benoit Jacob > Note that we already do use at least those STL containers for whi

Re: Can we start using C++ STL containers in Mozilla code?

Note that we already do use at least those STL containers for which we don't have an equivalent in the tree. I've seen usage of at least: std::map, std::set, and std::bitset. I think that Nick has a good point about reporting memory usage, but I think that the right solution to this problem is to

Re: Deciding whether to change the number of unified sources

Here, stripping a non-opt debug linux 64bit libxul brings it down from 534 MB down to 117 MB. Benoit 2013/12/3 L. David Baron > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote: > > Also, I would be very interested in seeing "size of libxul.so" for > > fully-optimized (including PGO, where

Re: Deciding whether to change the number of unified sources

2013/12/3 Chris Peterson > On 12/3/13, 8:53 AM, Ted Mielczarek wrote: > >> On 12/2/2013 11:39 PM, Mike Hommey wrote: >> >>> Current setup (16): >>>real11m7.986s >>>user63m48.075s >>>sys 3m24.677s >>>Size of the objdir: 3.4GiB >>>Size of libxul.so: 455MB >>> >>> Ju

Re: Deciding whether to change the number of unified sources

I would like to know the *effective* average number of original source files per unified source file, and see how it compares to the *requested* one (which you are adjusting here). Because many unified directories have a low number of source files, the effective number of sources per unified sourc

Re: Mitigating unified build side effects Was: Thinking about the merge with unified build

I'm all for reducing usage of 'using' and in .cpp files I've been switching to doing namespace foo { // my code } instead of using namespace foo; // my code where possible, as the latter leaks to other .cpp files in unified builds and the former doesn't. Regarding the p

Re: HWA and OMTC on Linux

Congrats Nick, after all is said and done, this is a very nice milestone to cross! 2013/11/26 Nicholas Cameron > This has finally happened. If it sticks, then after this commit ( > https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there > will be no more main thread OpenGL compos

Re: Recent build time improvements due to unified sources

2013/11/20 Ehsan Akhgari > On 2013-11-20 5:27 PM, Robert O'Callahan wrote: > >> On Thu, Nov 21, 2013 at 11:06 AM, Zack Weinberg wrote: >> >> On 2013-11-20 12:37 PM, Benoit Jacob wrote: >>> >>> Talking about ideas for further extending the impact

Re: Recent build time improvements due to unified sources

2013/11/20 Gregory Szorc > On Nov 20, 2013, at 9:37, Benoit Jacob wrote: > > > Talking about ideas for further extending the impact of UNIFIED_SOURCES, > it > > seems that the biggest limitation at the moment is that sources can't be > > unified between differ

Re: Recent build time improvements due to unified sources

Talking about ideas for further extending the impact of UNIFIED_SOURCES, it seems that the biggest limitation at the moment is that sources can't be unified between different moz.build's. Because of that, source directories that consist of many small sub-directories do not benefit much from UNIFIED

Re: Graphics leaks(?)

2013/11/19 Nicholas Nethercote > And the comment at https://bugzilla.mozilla.org/show_bug.cgi?id=915940#c13is > worrying: > "... once allocated the memory is only referenced via a SurfaceDescriptor, > which is a generated class (from IPDL). These are then passed around from > thread to thread and

Re: Unified builds

2013/11/18 Boris Zbarsky > On 11/17/13 5:26 PM, Ehsan Akhgari wrote: > >> I don't think that we need to try to fix this problem any more than the >> general problem of denoting our dependencies explicitly. It's common for >> you to remove an #include from a header and find dozens of .cpp files i

  1   2   3   >