Discussion :

[rtg57]

Bonjour,

j'expérimente quelques bidouillage de données qui m'amènent à plusieurs questions (Excusez-moi si je déroge un peu à la règle "1 question = 1 post" ):

Voici une classe, sensée remplacer une structure (dans un de mes anciens programme en C):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
static class quatreShorts
{
  short donnee1;
  short donnee2;
  short donnee3;
  short donnee4;
}

Ensuite vient l'instanciation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
quatreShorts structure1 = new quatreShorts();
quatreShorts structure2 = new quatreShorts();

Dès lors, j'ai 8 octets disponibles en mémoire pour structure1, et 8 autres octets pour structure2.

Faisons un peu de remplissage d'octets:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
structure1.donnee1 = 1;
structure1.donnee2 = 2;
structure1.donnee3 = 3;
structure1.donnee4 = 4;

Et maintenant une bidouille:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

structure2 = structure1;

En une instruction, je vois les 4 membres de structure2 prendre les même valeur que ceux de structure1. En fait j'ai positionné structure2 sur l'emplacement mémoire de structure1.

Question1: que devient la mémoire réservée pour structure2, dès lors que cette zone devient "orpheline" puisque je n'ai plus de moyen de pointer dessus ?

En fait, ce que je voulais faire à l'origine, c'est un système permettant de copier rapidement les 8 octets de structure1 vers structure2.
Question2: existe-t-il un moyen de faire cette copie de 8 octets depuis l'emplacement pointé par structure1, vers l'emplacement pointé par structure2 ? Autre que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
structure2.donnee1 = structure1.donnee1;
/.../

Ce qui me chatouille un peu, c'est que ces 8 octets, c'est l'équivalent d'un long.
or une instruction du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maVariableLong2 = maVariableLong1;

ferait cette copie instantanément... si vous voyez ce que je veux dire

Merci & @ bientôt

[thelvin]

Dès lors, j'ai 8 octets disponibles en mémoire pour structure1, et 8 autres octets pour structure2.

C'est probablement vrai, mais tu ne devrais pas t'occuper des octets. Tu as 4 shorts dans structure1 et 4 shorts dans structure2. Si tu veux des octets, déclare plutôt des bytes.

En fait j'ai positionné structure2 sur l'emplacement mémoire de structure1.

On ne raisonne pas ainsi en Java. Et idéalement, on ne raisonne pas ainsi en POO.

Avant, tu avais deux objets : un dans structure1 et un dans structure2. Avec ton instruction, tu as fait en sorte que structure2 référence le même objet que structure1. Et plus rien ne référence l'objet que structure2 référençait.

L'emplacement mémoire, on s'en tape. On manipule des références.

Question1: que devient la mémoire réservée pour structure2, dès lors que cette zone devient "orpheline" puisque je n'ai plus de moyen de pointer dessus ?

Ce n'est pas une question de mémoire. L'objet qui était référencé par structure2 ne l'est plus, et il n'est plus référencé par rien. Comme tout objet auquel ça arrive, il sera traité par le garbage-collector en temps et en heure.

En fait, ce que je voulais faire à l'origine, c'est un système permettant de copier rapidement les 8 octets de structure1 vers structure2.
Question2: existe-t-il un moyen de faire cette copie de 8 octets depuis l'emplacement pointé par structure1, vers l'emplacement pointé par structure2 ? Autre que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
structure2.donnee1 = structure1.donnee1;
/.../

Ce qui me chatouille un peu, c'est que ces 8 octets, c'est l'équivalent d'un long.
or une instruction du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maVariableLong2 = maVariableLong1;

ferait cette copie instantanément... si vous voyez ce que je veux dire

Le plus proche de cela est de déclarer que ta classe implémente Cloneable, et pour copier un objet, appeler clone() dessus. Fondamentalement, ça ne copie pas les données d'un objet vers un autre, ça crée un nouvel objet initialisé avec les mêmes données que celui sur lequel on appelle clone(). Et ça suffira très bien dans la plupart des cas, 'faut pas s'en faire.

Parfois, et je veux dire par là qu'en pratique ce n'est jamais le cas sauf si on l'a prouvé... Parfois, donc, créer un nouvel objet à chaque fois est mauvais pour les performances et l'utilisation mémoire, et il vaut mieux copier les données d'un objet à l'autre. Rien n'est prévu pour ça, mais il suffit de créer une méthode qui prend en paramètre l'objet vers lequel copier les données, et ça évite de se casser la tête à copier 4 variables à chaque fois.
Si l'appel de méthode est lui-même trop long, la déclarer final : le compilateur JIT saura alors qu'il peut l'optimiser en une fonction inline.

[tchize_]

Si l'appel de méthode est lui-même trop long, la déclarer final : le compilateur JIT saura alors qu'il peut l'optimiser en une fonction inline.

Pour info, un JIT raisonnablement récent peut très bien inliner des méthodes non finales

[thelvin]

? Comment est-ce possible ?

Tu veux dire, à condition qu'il détecte que l'instance d'objet sur laquelle on appelle cette méthode est toujours la même ?

[tchize_]

la compilation JIT se fait au runtime, sur les blocs les plus souvent utilisé, il n'est donc pas impossible de réaliser ce genre d'opération, le JIT étant interne à la JVM, il n'est pas contraint par les spécification du language puisque sont but est de transformer du java en natif au vol, et a donc une large marge de manoeuvre pour ce genre d'algo d'optimisaiton

ils en parlent un peu ici, je ne trouve pas de document précisant exactement la technique utilisée. Mais c'est critique aux performances de la jvm car l'invocation de méthodes et la partie la plus contraignante en java


http://java.sun.com/products/hotspot...r.html#dynamic

[thelvin]

Grosso-modo ça dit que la JVM doit être capable de détecter quand une nouvelle classe chargée risque de modifier l'optimisation.
Ma foi, je suppose que ça marche. Ça me semblait lourd à gérer, pourtant...

[rtg57]

Merci à vous deux pour l'intérêt que vous avez porté à cette question.

J'ai encore beaucoup le réflexe de chercher à bidouiller dans les octets (Le langage C et C++ permet de s'approcher très près de la machine), parce que je pense que cela permet de faire du code très rapide...mais aussi de beaux plantages

Cependant, c'est vrai que cela n'est pas dans la philosophie de JAVA (je débute) et que pour finir, je viens de résoudre mon problème selon la maxime de Thelvin:

Ca suffira très bien dans la plupart des cas, faut pas s'en faire.

Pour finir, je constate que la rapidité d'exécution du code est tout à fait honorable.

Merci & @ bientôt

[thelvin]

En fait, en Java comme ailleurs, il faut savoir faire preuve d'humilité.

Penser que programmer près de la machine permet de faire du code très rapide, c'est en fin de compte penser qu'on sait mieux optimiser son code que le ne ferait un compilateur spécialisé...
Et en général, on se trompe -_-°.

[tchize_]

Et en général, on se trompe -_-°.

Surtout, en général, on optimise pas là où il faut (l'optimisation hative est toujours une erreur)