When I'm 64 ( nsFrameStateBits.h )

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

When I'm 64 ( nsFrameStateBits.h )

Jet Villegas-2
Hi All:

While hacking on bug 1242461, I ran into the issue where our 64 bits of
nsFrame and nsBlockFrame state are used up. To resolve this, and I was
thinking I could reuse bit 59 to indicate NS_FRAME_EXTENDED_BITS and
allocate another uint32 or uint64 for those bits. Has someone already tried
this? Will the memory hit be unacceptable?

Thanks,

Jet
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: When I'm 64 ( nsFrameStateBits.h )

L. David Baron
On Saturday 2016-02-13 18:13 -0800, Jet Villegas wrote:
> Hi All:
>
> While hacking on bug 1242461, I ran into the issue where our 64 bits of
> nsFrame and nsBlockFrame state are used up. To resolve this, and I was
> thinking I could reuse bit 59 to indicate NS_FRAME_EXTENDED_BITS and
> allocate another uint32 or uint64 for those bits. Has someone already tried
> this? Will the memory hit be unacceptable?

I don't think it should be separately allocated; it should just be a
fully-fledged part of nsIFrame.

It looks like there's a 32-bit gap on 64-bit builds next to
mOverflow, and we should probably just put another 32 bits of frame
state bits there (after double-checking this).  We might want to
separate the class-specific bits into that new 32-bit value,
although I'm less sure about that.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: When I'm 64 ( nsFrameStateBits.h )

Jet Villegas-2
Thanks David!

I like the idea of moving the class-specific bits into the new area--It
buys us more time for those classes. I'll test to see if the perf hit is
significant when we always fetch from the new bits vs. first checking for
the presence of extended bits.

--Jet


On Sat, Feb 13, 2016 at 6:21 PM, L. David Baron <[hidden email]> wrote:

> On Saturday 2016-02-13 18:13 -0800, Jet Villegas wrote:
> > Hi All:
> >
> > While hacking on bug 1242461, I ran into the issue where our 64 bits of
> > nsFrame and nsBlockFrame state are used up. To resolve this, and I was
> > thinking I could reuse bit 59 to indicate NS_FRAME_EXTENDED_BITS and
> > allocate another uint32 or uint64 for those bits. Has someone already
> tried
> > this? Will the memory hit be unacceptable?
>
> I don't think it should be separately allocated; it should just be a
> fully-fledged part of nsIFrame.
>
> It looks like there's a 32-bit gap on 64-bit builds next to
> mOverflow, and we should probably just put another 32 bits of frame
> state bits there (after double-checking this).  We might want to
> separate the class-specific bits into that new 32-bit value,
> although I'm less sure about that.
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>              Before I built a wall I'd ask to know
>              What I was walling in or walling out,
>              And to whom I was like to give offense.
>                - Robert Frost, Mending Wall (1914)
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: When I'm 64 ( nsFrameStateBits.h )

Xidorn Quan
In reply to this post by L. David Baron
On Sun, Feb 14, 2016 at 10:21 AM, L. David Baron <[hidden email]> wrote:
> It looks like there's a 32-bit gap on 64-bit builds next to
> mOverflow, and we should probably just put another 32 bits of frame
> state bits there (after double-checking this).  We might want to
> separate the class-specific bits into that new 32-bit value,
> although I'm less sure about that.

If we are putting class-specific bits into separate area, are there
any reason we still perfer the current setting (state bits) over bool
bitfields?

It seems to me using bitfields would give us more flexibility on
adding and removing flags, and potentially provide more compile time
check.

I guess we would probably still want to keep bits of text frame in the
same place?

- Xidorn
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: When I'm 64 ( nsFrameStateBits.h )

bugs
In reply to this post by L. David Baron
On Saturday, February 13, 2016 at 6:56:17 PM UTC-8, Xidorn Quan wrote:

> On Sun, Feb 14, 2016 at 10:21 AM, L. David Baron wrote:
> > It looks like there's a 32-bit gap on 64-bit builds next to
> > mOverflow, and we should probably just put another 32 bits of frame
> > state bits there (after double-checking this).  We might want to
> > separate the class-specific bits into that new 32-bit value,
> > although I'm less sure about that.
>
> If we are putting class-specific bits into separate area, are there
> any reason we still perfer the current setting (state bits) over bool
> bitfields?
>
> It seems to me using bitfields would give us more flexibility on
> adding and removing flags, and potentially provide more compile time
> check.
>
> I guess we would probably still want to keep bits of text frame in the
> same place?
>
> - Xidorn

I suppose that if a struct/class of 32 booleans fits in that 32-bit gap, then it should be OK memory-wise. I don't know if this gets compiler-specific re: alignment.

--Jet
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: When I'm 64 ( nsFrameStateBits.h )

Matt Woodrow-2
Using state bits makes us very aware of how many we've used, and when
we're about to run out (and change the compiled size of the class).

We'd want static asserts or similar to track this instead if we switched.

- Matt

On 14/02/16 4:34 PM, [hidden email] wrote:

> On Saturday, February 13, 2016 at 6:56:17 PM UTC-8, Xidorn Quan wrote:
>> On Sun, Feb 14, 2016 at 10:21 AM, L. David Baron wrote:
>>> It looks like there's a 32-bit gap on 64-bit builds next to
>>> mOverflow, and we should probably just put another 32 bits of frame
>>> state bits there (after double-checking this).  We might want to
>>> separate the class-specific bits into that new 32-bit value,
>>> although I'm less sure about that.
>> If we are putting class-specific bits into separate area, are there
>> any reason we still perfer the current setting (state bits) over bool
>> bitfields?
>>
>> It seems to me using bitfields would give us more flexibility on
>> adding and removing flags, and potentially provide more compile time
>> check.
>>
>> I guess we would probably still want to keep bits of text frame in the
>> same place?
>>
>> - Xidorn
> I suppose that if a struct/class of 32 booleans fits in that 32-bit gap, then it should be OK memory-wise. I don't know if this gets compiler-specific re: alignment.
>
> --Jet
> _______________________________________________
> dev-tech-layout mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-layout

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout