Alle GCs, die ich außer Azul kenne, sind etwas parallel, haben aber zumindest einige kleine Stop-the-world-Komponenten. Warum gibt es nicht mehr GC's wie Azul?Warum gibt es keine pausenlosen GCs?
Hat Azul ihre Technologie so patentieren lassen, dass es nicht möglich ist?
Oder verursachen die für den pausenlosen Betrieb erforderlichen Schreib-/Lesebarrieren so viel Aufwand, dass sie für die meisten Arbeitslasten nicht praktikabel sind?
Basierend auf the Azul whitepaper on C4, sieht es aus wie C4 ist eine sehr neue Technologie, eine Implementierung eines 2005 veröffentlichten Algorithmus zuerst auf benutzerdefinierte Hardware und dann portiert speziell auf Linux auf x86, und die JVM-Implementierung sitzt sehr nah an den Kernel VM-System.
Da OpenJDK/HotSpot auf einer Reihe von Plattformen und bei großen Produktionsauslastungen weit verbreitet ist, tendiert es dazu, sich langsamer zu bewegen, wenn wichtige Neuerungen in Algorithmen übernommen werden (der Wechsel zu TimSort ist ein gutes Beispiel). Die Java 8-Versionen führten die erste grundlegende Überarbeitung des GC-Systems in Jahren ein (mit der Eliminierung des PermGen), und Verbesserungen wie C4, wenn sie praktisch plattformübergreifend oder abstrahiert werden, ohne wesentliche Nachteile für JVM-Buchhaltungseinbauten, sind wahrscheinlich ausprobiert und dann in zukünftigen Versionen in OpenJDK/HotSpot übernommen werden.
Guter Punkt in der Tat, frühe Azul verwendet Hardware-Tag-Bits und dann Linux Kernel-Level-Modifikationen und es ist immer noch Linux-Lösung, gegen Shenandoah "BTW, um den Satz gerade zu setzen: C4 (in der Form, die im Inneren verschifft wurde (unser Zing JVM seit einiger Zeit) ist reine Software und läuft auf unlackierten Linux/x86 Distributionen (RHEL 5.x/6.x, CentOS 5.x/6.x, SLES, Ubuntu, ...) und dem unmodifizierte Kernel, die mit ihnen kommen. " https://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/ – michaelok
Das Implementieren von Garbage Collectors ist ziemlich schwierig und es gibt nicht viele Anwendungen, die einen pausenlosen Collector wirklich rechtfertigen. Wie Sie bereits erwähnt haben, lesen/schreiben Sie Barrieren, um einen ziemlich hohen Overhead zu verursachen, den Sie nur dann zahlen möchten, wenn Sie unbedingt eine niedrige Latenz benötigen und bereit sind, den Durchsatz zu schlagen.
Das heißt, ein Low-Pause-GC namens Shenandoah wird in diesem JEP implementiert: http://openjdk.java.net/jeps/189. Als Java-Programmierer hoffe ich, dass es in ein paar Jahren verfügbar sein wird.
Ich glaube nicht, dass es sich um eine konkrete, beantwortbare Frage handelt, sondern um eine persönliche Meinung und Vermutung. Also wäre es wahrscheinlich besser für ein Forum geeignet als Stack Overflow. –
Ich kann es nur raten, aber ich nehme an, dass ein Teil davon ein Lizenz-/Patentierungsproblem ist - Azul will sowieso etwas Geld verdienen. Abgesehen davon, von ihren rohen Durchsatzerfahrungen in den Whitepapers scheint es, als ob es keinen Geschwindigkeitsvorteil für größere Anwendungen gibt und bei kleineren ist das gelegentliche Schluckauf wegen der Stop-the-World-Sammlung höchstwahrscheinlich nicht so wichtig. – Thomas
Diese Frage scheint off-topic zu sein, weil sie nur fragt, warum etwas noch nicht erfunden wurde. Keine tatsächliche Antwort ist möglich. – EJP