Bug 121238 – Bitmap's WordType should be a template parameter

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Mark Hahnenberg]

The code is written as if it already is. We just need to lift it out of the class.

[Mark Hahnenberg]

Created attachment 211449 [details]
Patch

[Darin Adler]

Comment on attachment 211449 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=211449&action=review

> Source/WTF/ChangeLog:26
> +        (WTF::::Bitmap):
> +        (WTF::::get):
> +        (WTF::::set):
> +        (WTF::::testAndSet):
> +        (WTF::::testAndClear):
> +        (WTF::::concurrentTestAndSet):
> +        (WTF::::concurrentTestAndClear):
> +        (WTF::::clear):
> +        (WTF::::clearAll):
> +        (WTF::::nextPossiblyUnset):
> +        (WTF::::findRunOfZeros):
> +        (WTF::::count):
> +        (WTF::::isEmpty):
> +        (WTF::::isFull):

The prepare-ChangeLog script made a mess here. I suggest inserting the class name Bitmap into these function names.

[Mark Hahnenberg]

Committed r155640: <http://trac.webkit.org/changeset/155640>

[Geoffrey Garen]

Are you planning to use an 'unsigned char' WordType in the GC?

Two thoughts:

(1) I wonder if we should just mandate "byte at a time" for bitmap. Why do we need to customize?

(2) It's important to preserve some of the "machine word at a time" optimizations even if the client requests a byte word size. For example, nextPossiblyUnset should work a machine word at a time.

[Mark Hahnenberg]

(In reply to comment #4)
> Are you planning to use an 'unsigned char' WordType in the GC?
> 
Yep. It allows us to be more accurate when we're checking for mark bits (i.e. there's only 7 other objects that could confuse us into taking the slow path rather than 31).

> Two thoughts:
> 
> (1) I wonder if we should just mandate "byte at a time" for bitmap. Why do we need to customize?
>
I thought it would be better to leave the choice to the client, although I guess before this patch the client didn't have a choice either.
 
> (2) It's important to preserve some of the "machine word at a time" optimizations even if the client requests a byte word size. For example, nextPossiblyUnset should work a machine word at a time.
Okay. I filed https://bugs.webkit.org/show_bug.cgi?id=121266.