달빅 모니터가 8 바이트 경계

Question

<code root>/dalvik/vm/Sync.cpp에 정렬 왜하는 struct Monitor가 : Monitor가 8 바이트로 정렬 왜 이해할 수 없다

struct Monitor { 
    Thread*  owner;   /* which thread currently owns the lock? */ 
    int   lockCount;  /* owner's recursive lock depth */ 
    Object*  obj;   /* what object are we part of [debug only] */ 

    Thread*  waitSet; /* threads currently waiting on this monitor */ 

    pthread_mutex_t lock; 

    Monitor* next; 

    /* 
    * Who last acquired this monitor, when lock sampling is enabled. 
    * Even when enabled, ownerMethod may be NULL. 
    */ 
    const Method* ownerMethod; 
    u4 ownerPc; 
}; 

. 모든 멤버 (포인터, int & pthread_mutex_t)의 길이가 4 바이트이기 때문에 4 바이트 씩 정렬해야한다고 생각합니다.

Answer 1

문제는 명시 적으로 표시되지 않았지만 8 바이트 정렬에 의해 당신은 아마 Misaligned monitor 확인과 함께 code의이 부분을 의미 :

Monitor* dvmCreateMonitor(Object* obj) 
{ 
    Monitor* mon; 
    mon = (Monitor*) calloc(1, sizeof(Monitor)); 
    if (mon == NULL) { 
     ALOGE("Unable to allocate monitor"); 
     dvmAbort(); 
    } 
    if (((u4)mon & 7) != 0) { 
     ALOGE("Misaligned monitor: %p", mon); 
     dvmAbort(); 
    } 

이유는 달빅 얇은 잠금을 사용한다는 것입니다. 잠금은 객체의 32 비트 값이고 하단 3 비트는 잠금 상태 인코딩에 사용됩니다. 씬/팻 로크 상태를위한 1 비트와 해시 상태를위한 2 비트입니다. Monitor에 대한 포인터는 29 비트 만 남아 있습니다. 동일한 source 가입일

:

로크 값 자체 Object.lock에 저장된다. 잠금의 LSB는 해당 상태를 인코딩합니다. 취소하면, 잠금은 "씬" 상태에 다음과 같이 그 비트가 포맷됩니다

[31 ---- 19] [18 ---- 3] [2 ---- 1] [0] 
lock count thread id hash state 0 

세트, 잠금은 "지방"상태에 있고 그 비트는 를 포맷하는 경우 다음과 같이 Thin Locks: Featherweight Synchronization for Java

: 참고로

[31 ---- 3] [2 ---- 1] [0] 
    pointer hash state 1 

여기 얇은 로크를 설명하는 용지의

의견에서 정렬이 어떻게 수행되는지를 묻습니다. C 표준은 할당 자에게 모든 유형의 할당에서 사용할 수있는 주소를 반환하기 만하면됩니다. C99 §7.20.3 (메모리 관리 함수)에서 :

할당이 성공하면 포인터가 반환되어 모든 유형의 객체에 대한 포인터에 할당되고 그런 다음이 객체에 액세스하는 데 사용됩니다 또는 할당 된 공간에있는 그러한 객체들의 배열 (공간이 명시 적으로 할당 해제 될 때까지).

기본적으로 32 비트 ARM 시스템의 malloc/calloc/realloc은 8 바이트 단위로 정렬 된 블록을 반환합니다. 나는 Misaligned monitor 검사가 8 바이트 정렬 블록을 반환하지 않는 버전으로 할당자가 교체되는 경우에 대비하여 실패하는 방어 코드가 있다고 믿습니다.