JMM Garantien innerhalb einer Try-mit-Ressource-Neuordnungs & JNI rufen

Question

mit dem folgende Codebeispiel:

try (AutoClosable closable = new XXX()) { 
     o.method1(closable); 
     o.method2(); 
} 

Ist das Java-Speichermodell HotSpot closable.close() vor o.method2() neu anordnen kann?

Ich verzichte absichtlich auf Implementierungsdetails wie schließt Methode1 verschließbar? im ersten Teil dieser Frage.

---

Mein spefic Anwendungsfall ist dies:

ich eine C-Bibliothek haben, die wie folgt zusammengefasst werden können:

static char* value; 

void capture(char* ptr){ 
     value = ptr; 
} 

int len(void) { 
    return strlen(value); 
} 

Diese native Bibliothek gewickelt JNA mit

interface CApi extends Library { 

static { 
    Native.register("test.so", CApi.class) 
} 

    void capture(Pointer s); 
    int test(); 
} 

Und mein ursprünglicher Clientcode sieht ungefähr so ​​aus:

Das Problem mit dieser ersten Version ist, dass m von Java zugewiesen wurde und der Lebenszyklus dieses Speichers an m gebunden ist, die stark erreichbar ist. m ist nicht stark mehr erreichbar einmal capture(m) und Speicher wird freigegeben werden, wenn GC Tritte in (JNA auf finalize setzen nativen Speicher frei)

Um dies zu verhindern, dass ich JNA die Unterklasse vorgeschlagen Memory ein AutoClosableMemory einzuführen. Die Idee ist, dass die Verwendung eines Try-with-Resource-Konstrukts klar aussagen würde, dass die Ressource in diesem Bereich stark erreichbar ist. Der Bonus, dass wir das native Gedächtnis befreien konnten, ist bald da wir es nicht mehr brauchen, anstatt auf einen GC warten zu müssen (hey das ist RAII!). Ich

try (AutoClosableMemory m = [...]) { 
    cApi.capture(m); 
    cApi.test(); 
} 

Am garantiert, dass m.close() nie vor cApi.test() geltend gemacht werden und dass m ist stark erreichbar? In diesem Fall wird m von der zugrunde liegenden C-API erfasst, aber der Java-Compiler hat keine Möglichkeit, sie zu kennen.

Answer 1

Theoretisch könnte die JVM die Anweisungen neu anordnen, aber das Ergebnis der Methode muss korrekt bleiben. HotSpot versteht nativen Code nicht und um die Korrektheit zu garantieren, wird Code nie um native Anweisungen herum angeordnet.

Answer 2

Für einen Thread wird garantiert, dass alle in der gleichen Reihenfolge wie in Ihrem Code ausgeführt werden (jede Neuanordnung, die passiert, kann in keiner Weise Ihr Programm beeinträchtigen). Das Neuanordnen kann nur Auswirkungen darauf haben, wie andere Threads sehen, was passiert. In Ihrer Frage gibt es nur einen Thread, so dass Ihr Programm garantiert cApi.test() vor m.close() aufrufen kann.