Reorder struct elements to be more optimal for 64 bit computers

(Main reason for reordering was to get rid of compiler warnings for order of element initialization)

sql/log.cc

@@ -356,9 +356,10 @@ static int find_uniq_filename(char *name)
 
 MYSQL_LOG::MYSQL_LOG()
   :bytes_written(0), last_time(0), query_start(0), name(0),
-   file_id(1), open_count(1), log_type(LOG_CLOSED), write_error(0), inited(0),
-   need_start_event(1), prepared_xids(0), description_event_for_exec(0),
-   description_event_for_queue(0), readers_count(0), reset_pending(FALSE)
+   prepared_xids(0), log_type(LOG_CLOSED), file_id(1), open_count(1),
+   readers_count(0), reset_pending(FALSE), write_error(FALSE), inited(FALSE),
+   need_start_event(TRUE),
+   description_event_for_exec(0), description_event_for_queue(0)
 {
   /*
     We don't want to initialize LOCK_Log here as such initialization depends on

sql/sql_class.h

@@ -190,10 +190,10 @@ class MYSQL_LOG: public TC_LOG
  private:
   /* LOCK_log and LOCK_index are inited by init_pthread_objects() */
   pthread_mutex_t LOCK_log, LOCK_index, LOCK_readers;
+  pthread_mutex_t LOCK_prep_xids;
+  pthread_cond_t  COND_prep_xids;
   pthread_cond_t update_cond;
   pthread_cond_t reset_cond;
-  bool reset_pending;
-  int readers_count;
   ulonglong bytes_written;
   time_t last_time,query_start;
   IO_CACHE log_file;
@@ -201,21 +201,6 @@ class MYSQL_LOG: public TC_LOG
   char *name;
   char time_buff[20],db[NAME_LEN+1];
   char log_file_name[FN_REFLEN],index_file_name[FN_REFLEN];
-  // current file sequence number for load data infile binary logging
-  uint file_id;
-  uint open_count;				// For replication
-  volatile enum_log_type log_type;
-  enum cache_type io_cache_type;
-  bool write_error, inited;
-  bool need_start_event;
-  /*
-    no_auto_events means we don't want any of these automatic events :
-    Start/Rotate/Stop. That is, in 4.x when we rotate a relay log, we don't want
-    a Rotate_log event to be written to the relay log. When we start a relay log
-    etc. So in 4.x this is 1 for relay logs, 0 for binlogs.
-    In 5.0 it's 0 for relay logs too!
-  */
-  bool no_auto_events;
   /*
      The max size before rotation (usable only if log_type == LOG_BIN: binary
      logs and relay logs).
@@ -227,13 +212,38 @@ class MYSQL_LOG: public TC_LOG
      fix_max_relay_log_size).
   */
   ulong max_size;
-
   ulong prepared_xids; /* for tc log - number of xids to remember */
-  pthread_mutex_t LOCK_prep_xids;
-  pthread_cond_t  COND_prep_xids;
+  volatile enum_log_type log_type;
+  enum cache_type io_cache_type;
+  // current file sequence number for load data infile binary logging
+  uint file_id;
+  uint open_count;				// For replication
+  int readers_count;
+  bool reset_pending;
+  bool write_error, inited;
+  bool need_start_event;
+  /*
+    no_auto_events means we don't want any of these automatic events :
+    Start/Rotate/Stop. That is, in 4.x when we rotate a relay log, we don't
+    want a Rotate_log event to be written to the relay log. When we start a
+    relay log etc. So in 4.x this is 1 for relay logs, 0 for binlogs.
+    In 5.0 it's 0 for relay logs too!
+  */
+  bool no_auto_events;
   friend class Log_event;
 
 public:
+  /*
+    These describe the log's format. This is used only for relay logs.
+    _for_exec is used by the SQL thread, _for_queue by the I/O thread. It's
+    necessary to have 2 distinct objects, because the I/O thread may be reading
+    events in a different format from what the SQL thread is reading (consider
+    the case of a master which has been upgraded from 5.0 to 5.1 without doing
+    RESET MASTER, or from 4.x to 5.0).
+  */
+  Format_description_log_event *description_event_for_exec,
+    *description_event_for_queue;
+
   MYSQL_LOG();
   /*
     note that there's no destructor ~MYSQL_LOG() !
@@ -246,18 +256,6 @@ public:
   int log(THD *thd, my_xid xid);
   void unlog(ulong cookie, my_xid xid);
   int recover(IO_CACHE *log, Format_description_log_event *fdle);
-
-  /*
-     These describe the log's format. This is used only for relay logs.
-     _for_exec is used by the SQL thread, _for_queue by the I/O thread. It's
-     necessary to have 2 distinct objects, because the I/O thread may be reading
-     events in a different format from what the SQL thread is reading (consider
-     the case of a master which has been upgraded from 5.0 to 5.1 without doing
-     RESET MASTER, or from 4.x to 5.0).
-  */
-  Format_description_log_event *description_event_for_exec,
-    *description_event_for_queue;
-
   void reset_bytes_written()
   {
     bytes_written = 0;