• [^] # Re: Fin de la pureté de Java

    Posté par . En réponse à la dépêche Java 8 et NetBeans 8 sont disponibles. Évalué à 4.

    Je pense qu'on s'écarte un peu du sujet initial. Évidement utiliser des objets plutôt que des types primitives à un fort impact sur les performances pour les raisons suivantes:

    • Coût du cycle de vie d'un objet
    • Empreinte mémoire très supérieure qui pourrie tes caches et te fais faire deux fois plus de fetch
    • Tu perds la localité d'accès, le pattern d'accès mémoire est moins clean et le proco va avoir plus de mal
    • Avoir beaucoup d'objets implique que GC te bouffe du CPU et te nique tes caches
    • Etc.

    Avoir un cache d'objets pour les entiers ne résout pas ces problème et de toute façon quand ces problèmes commence à se poser c'est que ton cache devrait faire 232 éléments pour des int... Et ton pattern d'accès mémoire est toujours pourri.

    Maintenant oui faire des pools d'objets ou des flyweight ca à un sens dans des cas déterminé. Suffit de regarder ce qui a été fait par twitter pour Netty 4.

    en tout cas dans les systèmes multi-threadé à cause des garanties offertes par le Java Memory Model, il y a une Write barrier à chaque exécution d'un constructeur.

    Tu as une source. Par ce que AFAIK (et le cookbook de la JSR 133 confirme) en sortie de constructeur c'est une barrière StoreStore qui est requise, et StoreStore sur x86 c'est un No-op vu que c'est déjà garanti par le memory model d'X86...