Branch Prediction?

[Paul Hohensee]

History as I remember it. :)

It's been considered, and decided against.  The platforms which openjdk
currently targets all have decent to spectacular hardware branch
prediction.  Those that didn't, such as Niagara 1, ignored prediction
bits.  Conclusion is that it's not worth complicating the code with, as
David says, 'magic macros'.

Paul

David Holmes wrote:
On 19/11/2014 4:42 AM, Christian Thalinger wrote:
> ?or I could just read the next email.  Doh.

Not so obvious when the subject was changed to "Compiler branch hints".
I had to go to the archives to find it.

My 2c. The performance focus has been on generated code, not the runtime
code. Personally I dislike these magic macros as they clutter the code.

David

>> On Nov 18, 2014, at 10:41 AM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:
>>
>> I?m not sure if the silence means nobody knows or nobody cares.
Speaking for myself, I don?t know of any history on this.
>>
>>> On Nov 8, 2014, at 1:43 AM, Erik ?sterlund <erik.osterlund at lnu.se>
wrote:
>>>
>>> Hi,
>>>
>>> Just out of curiosity, is there some good reason why we don't have a
branch prediction macro?
>>> For every tight load a; cmpxchg(expect: a, addr: &x, new_val: b); loop,
I feel a bit uneasy not telling the compiler that this is pretty likely to
succeed, and relying on its guessing.
>>>
>>> Has it been excluded because it's considered not nice or perhaps it was
simply never introduced because nobody found it useful?
>>>
>>> Could have some define like this for GCC, which for other compilers
reduces to nothing:
>>>
>>> #define VM_EXPECT_TRUE(A) __builtin_expect((A), true)
>>> #define VM_EXPECT_FALSE(A) __builtin_expect((A), false)
>>>
>>> It might not lead to drastic performance improvements, but it feels
weird not to tell the compiler what we know and keep secrets from it. And I
think it's also nice for documentation purposes that people reading it also
understand that this expression is gonna be true most of the time, and deal
with it accordingly.
>>>
>>> /Erik