Instructions Java 8 non sécurisées: xxxFence ()

Question

Dans Java 8 trois barrière de mémoire des instructions ont été ajoutées Unsafe classe (source):

/**
 * Ensures lack of reordering of loads before the fence
 * with loads or stores after the fence.
 */
void loadFence();

/**
 * Ensures lack of reordering of stores before the fence
 * with loads or stores after the fence.
 */
void storeFence();

/**
 * Ensures lack of reordering of loads or stores before the fence
 * with loads or stores after the fence.
 */
void fullFence();

Si nous définissons la barrière de mémoire avec la manière suivante (que je considère comme plus ou moins facile à comprendre):

Considérons X et Y les types d'opération/de classes qui font l'objet de la réorganisation,

X_YFence() est une barrière de mémoire d'instructions qui assure que toutes les opérations de type X avant la barrière terminée avant toute opération de type Y après la barrière est commencé.

Nous pouvons aujourd'hui "carte" de la barrière des noms à partir d' Unsafe de cette terminologie:

• loadFence() devient load_loadstoreFence();
• storeFence() devient store_loadStoreFence();
• fullFence() devient loadstore_loadstoreFence();

Enfin, ma question est , pourquoi n'avons-nous pas load_storeFence(), store_loadFence(), store_storeFence() et load_loadFence()?

Ma conjecture serait - ils ne sont pas vraiment nécessaire, mais je ne comprends pas pourquoi à l'heure actuelle. Donc, j'aimerais savoir les raisons pour ne pas les ajouter. Devine sur qui sont aussi les bienvenus (espérons que ce n'est pas une cause de cette question hors de propos que par opinion, tout de même).

Merci à l'avance.

Answer 1

Une bonne source d'information est la PEC 171 lui-même.

Justification:

Les trois méthodes donnent les trois différents types de mémoire clôtures que certains compilateurs et les transformateurs ont besoin pour s'assurer que les accès (charges et les magasins) ne deviennent pas réorganisées.

La mise en œuvre (extrait):

pour le C++ versions du moteur d'exécution (en prims/unsafe.cpp), la mise en œuvre via l'OrderAccess méthodes:

    loadFence:  { OrderAccess::acquire(); }
    storeFence: { OrderAccess::release(); }
    fullFence:  { OrderAccess::fence(); }

En d'autres termes, les nouvelles méthodes sont étroitement liés à la façon dont la mémoire clôtures sont mis en œuvre à la JVM et les niveaux d'UC. Ils correspondent aussi à la barrière de mémoire les instructions disponibles en C++, la langue dans laquelle hotspot est mis en œuvre.

Une approche plus fine aurait probablement été possible, mais les avantages ne sont pas évidents.

Par exemple, si vous regardez le tableau d'instructions du processeur dans la JSR 133 livre de cuisine, vous verrez que LoadStore et LoadLoad carte pour les mêmes instructions sur la plupart des architectures, c'est à dire les deux sont effectivement Load_LoadStore instructions. Donc, en ayant un seul Load_LoadStore (loadFence) l'instruction au niveau de la JVM semble être une conception raisonnable de la décision.