Object's memory layout

The layout of objects stored in memory is divided into:
object header (Header), instance data (Instance Data) and alignment padding (Padding)
1. The object header includes two parts of information, the first part is used to store the runtime data of the object itself, such as Object header information such as HashCode, GC generation age, lock status flag, thread held lock,
   biased thread ID, biased timestamp, etc.
   are additional storage costs that are not related to the data defined by the object itself. Considering the virtual machine Space efficiency, Mark Word is designed as a non-fixed data structure
   in order to store as much information as possible in a very small space, it will reuse its own storage space according to the state of the object. For example: in a 32-bit HotSpot virtual machine, if the object is in
   an unlocked state, 25 bits in the 32-bit space of Mark Word are used to store the object hash code, 4 bits are used to store the object generation age, and 2 bits are used to store the object generation age. Storage lock flag bit,
   1bit is fixed to 0.
   Other states include: lightweight lock, heavyweight lock, GC mark, and
   the other part of the object header is the type pointer, that is, the object points to his class element data pointer, virtual The machine uses this pointer to determine which class the object is an instance of.
2. The instance data part is the effective information that the object actually stores, and it is also the field content of the respective types defined in the program code. Whether it is inherited from the parent class or
   defined in the subclass, it needs to be recorded. This part of the storage order is affected by the virtual machine allocation strategy parameter (FieldsAllocationStyle) and the
   order in which the fields are defined in the Java source code. The default allocation strategy of the Hotspot virtual machine is longs/doubles, ints, shorts/chars, bytes/booleans, opps (Ordinary Object Pointers)
   As you can see from the allocation strategy, fields of the same width are always allocated together.
   Under the condition that we meet this premise, the variables defined in the parent class will appear before the child class.
3. The third alignment padding does not necessarily exist, nor does it have a special meaning, it just acts as a placeholder. Because the automatic memory management system of HotSpot VM requires that the starting address of the object
   must be an integer multiple of 8 bytes, in other words, the size of the object must be an integer multiple of 8 bytes. And the object part is exactly a multiple of 8 bytes (1 or 2 times),
   so when the object instance data part is not aligned, it needs to be filled by alignment padding.

Compiling hotspot progress

1./usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lgcc_s

2. invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
     gclog_or_tty->print("TLAB: %s thread: "INTPTR_FORMAT" [id: %2d]" is
invalid suffix literals; c++11 requires a space between literals and string macros [-Werror= literalsuffix]
modified to gclog_or_tty->print("TLAB: %s thread: " INTPTR_FORMAT " [id: %2d]"
3. error : "__LEAF" redefined [-Werror]
 #define __LEAF(result_type, header) \
Modified to:
 429 #ifdef __LEAF
    430 #undef __LEAF
    431 #define __LEAF(result_type, header) \
    432 TRACE_CALL(result_type, header) \
    433 debug_only( NoHandleMark __hm;)                                     \
    434   /* begin of body */
    435 #endif
4. error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated [-Werror=deprecated-declarations]
   if((status = ::readdir_r(dirp, dbuf, &p)) != 0)  未解决
vi /usr/include/dirent.h
#pragma disable(warning:4244)
For existing releases (7,8, 9), I think the right thing is to just disable the deprecation warning
错误:'int readdir_r(DIR*, dirent*, dirent**)'被弃用[-Werror=不支持声明]
/* Reentrant version of `readdir'.  Return in RESULT a pointer to the
        next entry.
        This function is a possible cancellation point and therefore not
        marked with __THROW.  */
     # ifndef __USE_FILE_OFFSET64
     extern int readdir_r (DIR *__restrict __dirp,
                           struct dirent *__restrict __entry,
                           struct dirent **__restrict __result)
          __nonnull ((1, 2, 3)) __attribute_deprecated__;
     # else
     #  ifdef __REDIRECT
    extern int __REDIRECT (readdir_r,
                           (DIR *__restrict __dirp,
                             struct dirent *__restrict __entry,
                             struct dirent **__restrict __result),
                            readdir64_r)
      __nonnull ((1, 2, 3)) __attribute_deprecated__;
    #  else
     #   define readdir_r readdir64_r
     #  endif
    # endif

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325903736&siteId=291194637