[libcxxabi] Reducing stack usage of test

[bcraig]

Summary

This test has a lot of classes with large amounts of manually inserted padding in them, presumable to prevent various optimizations. The test then creates lots of these objects on the stack. On embedded targets, this was usually enough to overflow the stack.

I moved the objects to global / namespace scope. Since the tests are each in their own namespace, there should be no cross-test conflicts.

[jroelofs]

Could these large padding things be related to the fact that the test is used as a performance check for the implementation? That being said, I have no idea who is paying attention to the numbers that come out of this test (if anyone even is?). Maybe @howard.hinnant knows something about it?

[bcraig]

In D15539#311343, @jroelofs wrote:

Could these large padding things be related to the fact that the test is used as a performance check for the implementation? That being said, I have no idea who is paying attention to the numbers that come out of this test (if anyone even is?). Maybe @howard.hinnant knows something about it?

My expectation is that the only thing the padding numbers would effect with regards to execution time would be cache hits and misses. If there is something subtle going on though, then those sizes need some comments and rationale. "93481" looks like it was pulled out of a hat, and it is large enough on it's own to overflow many embedded stacks.

[bcraig]

As an alternative, would it be acceptable to heap allocate these
objects, using the original padding numbers?

[bcraig]

Starting primes at 13, and skipping the larger twin in twin prime pairs. Using long double instead of char for padding to help alleviate fears of multiple structs having the same actual size.

[jroelofs]

What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment?

Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere.

[bcraig]

In D15539#312319, @jroelofs wrote:

What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment?

Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere.

Alignment is the main answer. I'd use max_align_t directly, except that it got added in C++11, and this test should be able to run in C++98 and C++03.
Using a large type instead of a char also makes it easier to avoid making two padding values that look different, but aren't actually all that different due to internal padding. Just starting at a high prime wouldn't fix this, as then I have to ensure that consecutive values are separated by at least sizeof(void *).

[jroelofs]

In D15539#312332, @bcraig wrote:

In D15539#312319, @jroelofs wrote:

What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment?

Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere.

Alignment is the main answer. I'd use max_align_t directly, except that it got added in C++11, and this test should be able to run in C++98 and C++03.
Using a large type instead of a char also makes it easier to avoid making two padding values that look different, but aren't actually all that different due to internal padding. Just starting at a high prime wouldn't fix this, as then I have to ensure that consecutive values are separated by at least sizeof(void *).

What platform are you on where sizeof(void*) is anywhere near 13 bytes?

[jroelofs]

In D15539#312336, @jroelofs wrote:

In D15539#312332, @bcraig wrote:

In D15539#312319, @jroelofs wrote:

What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment?

Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere.

Alignment is the main answer. I'd use max_align_t directly, except that it got added in C++11, and this test should be able to run in C++98 and C++03.
Using a large type instead of a char also makes it easier to avoid making two padding values that look different, but aren't actually all that different due to internal padding. Just starting at a high prime wouldn't fix this, as then I have to ensure that consecutive values are separated by at least sizeof(void *).

What platform are you on where sizeof(void*) is anywhere near 13 bytes?

Ohh, nevermind... now I see what you're saying.

[bcraig]

In D15539#312336, @jroelofs wrote:

In D15539#312332, @bcraig wrote:

In D15539#312319, @jroelofs wrote:

What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment?

Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere.

Alignment is the main answer. I'd use max_align_t directly, except that it got added in C++11, and this test should be able to run in C++98 and C++03.
Using a large type instead of a char also makes it easier to avoid making two padding values that look different, but aren't actually all that different due to internal padding. Just starting at a high prime wouldn't fix this, as then I have to ensure that consecutive values are separated by at least sizeof(void *).

What platform are you on where sizeof(void*) is anywhere near 13 bytes?

I'm on a platform where void* is 4 bytes (Hexagon). That's not what I was getting at though. Lets take x86_64 as an example instead.

#include <iostream>

struct A {
  virtual ~A() {}
  char _[17];
};
struct B {
  virtual ~B() {}
  char _[19];
};
struct C {
  virtual ~C() {}
  char _[23];
};

int main() {
  std::cout<<"A: "<<sizeof(A)<<std::endl; //prints 32
  std::cout<<"B: "<<sizeof(B)<<std::endl; //prints 32
  std::cout<<"C: "<<sizeof(C)<<std::endl; //prints 32
  return 0;
}

I could reasonable see an optimizer collapsing some of these classes together in some way or another. If you change the chars out for long doubles, then all three classes have different sizes.

[bcraig]

Ping.
If desired, I could provide an alternative implementation where all the structs are allocated at global scope with their original padding.

[bcraig]

ping

[jroelofs]

FOAD: Ball's in @mclow.lists's court, not mine. I don't feel comfortable signing off on this.

[bcraig]

ping

[bcraig]

@mclow.lists ping

[mclow.lists]

I think you've reduced the scope of the tests significantly with this change.

If you want to make the objects smaller, that's fine - but please heed Howard's advice in the email thread:

• Don't make them too small. (three digits is better than two)
• Keep the object sizes odd, and their differences more than the max alignment for your platform.

test/dynamic_cast14.pass.cpp

18

Using long double here (instead of char) forces alignment; reducing the scope of the tests.
(and means that the sizes are always an even number, and (probably) a multiple of 8.

36

@howard.hinnant wrote in the email thread:

If you need to reduce these numbers for other platforms, I think that would be fine. However I would not reduce them to double digits. I would keep them as large as you can reasonably get away with.

[bcraig]

Any objections to using the original sizes, but constructing the objects at global scope? That fixes the stack usage without significantly changing the layout characteristics of the test?

[mclow.lists]

Any objections to using the original sizes, but constructing the objects at global scope?

I think that should work.

[bcraig]

So does this latest revision get the check-mark of approval?

[bcraig]

@mclow.lists ping

[mclow.lists]

Yes, sorry.

test/dynamic_cast14.pass.cpp

 
 struct A1
 {
-    char _[43981];
+    char _[2];
     virtual ~A1() {}
 
     A1* getA1() {return this;}

 
 struct A2
 {
-    char _[34981];
+    char _[3];
     virtual ~A2() {}
 
     A2* getA2() {return this;}

     : public A1,
       public virtual A2
 {
-    char _[93481];
+    char _[5];
     virtual ~A3() {}
 
     A1* getA1_3() {return A1::getA1();}

     : public virtual A2,
       public A1
 {
-    char _[13489];
+    char _[7];
     virtual ~A4() {}
 
     A1* getA1_4() {return A1::getA1();}

     : public A3,
       public A4
 {
-    char _[13489];
+    char _[11];
     virtual ~A5() {}
 
     A1* getA1_3() {return A3::getA1();}

 struct A6
     : public A1
 {
-    char _[81349];
+    char _[13];
     virtual ~A6() {}
 
     A1* getA1_6() {return A1::getA1();}

     : public A5,
       public A6
 {
-    char _[34819];
+    char _[17];
     virtual ~A7() {}
 
     A1* getA1_3() {return A5::getA1_3();}

 struct A8
     : public A7
 {
-    char _[3489];
+    char _[19];
     virtual ~A8() {}
 
     A1* getA1_3() {return A7::getA1_3();}

 struct A9
     : public A1
 {
-    char _[3481];
+    char _[23];
     virtual ~A9() {}
 
     A1* getA1_9() {return A1::getA1();}

 struct A10
     : public virtual A8
 {
-    char _[4831];
+    char _[29];
     virtual ~A10() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public virtual A8,
       public A9
 {
-    char _[6483];
+    char _[31];
     virtual ~A11() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public A10,
       public A11
 {
-    char _[2283];
+    char _[37];
     virtual ~A12() {}
 
     A1* getA1_3() {return A10::getA1_3();}

 struct A13
     : public A12
 {
-    char _[1283];
+    char _[41];
     virtual ~A13() {}
 
     A1* getA1_3() {return A12::getA1_3();}

 
 struct A1
 {
-    char _[43981];
+    char _[2];
     virtual ~A1() {}
 
     A1* getA1() {return this;}

 
 struct A2
 {
-    char _[34981];
+    char _[3];
     virtual ~A2() {}
 
     A2* getA2() {return this;}

     : protected A1,
       public virtual A2
 {
-    char _[93481];
+    char _[5];
     virtual ~A3() {}
 
     A1* getA1_3() {return A1::getA1();}

     : public virtual A2,
       public A1
 {
-    char _[13489];
+    char _[7];
     virtual ~A4() {}
 
     A1* getA1_4() {return A1::getA1();}

     : public A3,
       public A4
 {
-    char _[13489];
+    char _[11];
     virtual ~A5() {}
 
     A1* getA1_3() {return A3::getA1();}

 struct A6
     : public A1
 {
-    char _[81349];
+    char _[13];
     virtual ~A6() {}
 
     A1* getA1_6() {return A1::getA1();}

     : public A5,
       public A6
 {
-    char _[34819];
+    char _[17];
     virtual ~A7() {}
 
     A1* getA1_3() {return A5::getA1_3();}

 struct A8
     : public A7
 {
-    char _[3489];
+    char _[19];
     virtual ~A8() {}
 
     A1* getA1_3() {return A7::getA1_3();}

 struct A9
     : public A1
 {
-    char _[3481];
+    char _[23];
     virtual ~A9() {}
 
     A1* getA1_9() {return A1::getA1();}

 struct A10
     : public virtual A8
 {
-    char _[4831];
+    char _[29];
     virtual ~A10() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public virtual A8,
       public A9
 {
-    char _[6483];
+    char _[31];
     virtual ~A11() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public A10,
       public A11
 {
-    char _[2283];
+    char _[37];
     virtual ~A12() {}
 
     A1* getA1_3() {return A10::getA1_3();}

 struct A13
     : public A12
 {
-    char _[1283];
+    char _[41];
     virtual ~A13() {}
 
     A1* getA1_3() {return A12::getA1_3();}

 
 struct A1
 {
-    char _[43981];
+    char _[2];
     virtual ~A1() {}
 
     A1* getA1() {return this;}

 
 struct A2
 {
-    char _[34981];
+    char _[3];
     virtual ~A2() {}
 
     A2* getA2() {return this;}

     : public A1,
       protected virtual A2
 {
-    char _[93481];
+    char _[5];
     virtual ~A3() {}
 
     A1* getA1_3() {return A1::getA1();}

     : public virtual A2,
       public A1
 {
-    char _[13489];
+    char _[7];
     virtual ~A4() {}
 
     A1* getA1_4() {return A1::getA1();}

     : public A3,
       public A4
 {
-    char _[13489];
+    char _[11];
     virtual ~A5() {}
 
     A1* getA1_3() {return A3::getA1();}

 struct A6
     : public A1
 {
-    char _[81349];
+    char _[13];
     virtual ~A6() {}
 
     A1* getA1_6() {return A1::getA1();}

     : public A5,
       public A6
 {
-    char _[34819];
+    char _[17];
     virtual ~A7() {}
 
     A1* getA1_3() {return A5::getA1_3();}

 struct A8
     : public A7
 {
-    char _[3489];
+    char _[19];
     virtual ~A8() {}
 
     A1* getA1_3() {return A7::getA1_3();}

 struct A9
     : public A1
 {
-    char _[3481];
+    char _[23];
     virtual ~A9() {}
 
     A1* getA1_9() {return A1::getA1();}

 struct A10
     : public virtual A8
 {
-    char _[4831];
+    char _[29];
     virtual ~A10() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public virtual A8,
       public A9
 {
-    char _[6483];
+    char _[31];
     virtual ~A11() {}
 
     A1* getA1_3() {return A8::getA1_3();}

     : public A10,
       public A11
 {
-    char _[2283];
+    char _[37];
     virtual ~A12() {}
 
     A1* getA1_3() {return A10::getA1_3();}

 struct A13
     : public A12
 {
-    char _[1283];
+    char _[41];
     virtual ~A13() {}
 
     A1* getA1_3() {return A12::getA1_3();}