Diskussion zu: Intels Nova Lake m.b.z. 288MB L3-Cache + hohen Gaming- & MT-Zugewinnen

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/geruechtekueche-intels-nova-lake-mit-bis-zu-288-mb-l3-cache-und-hohen-gaming-multithread-zugewi

[Zossel]

Last-Level-Cache würde ich das nicht nennen, das ist ein ganz gewöhnlicher L3.Steht auch so in dem verlinkten Video mit Timestamp.

Ein LLC hängt direkt vor den DRAM-Controller, und dieser würde sich auch auf PCIe-Transfers und die IGPU auswirken.
Bei den zu erwartenden zukünftigen PCIe Bandbreiten würde ein LLC langsam sinnvoll werden.

[CCCP]

Möglicherweise sind somit auch alle diese Performance-Angaben nur basierend auf Intels eigenen Simulationen, sprich dem entsprechend, was Intel bei gutem Gelingen erreichen will – sofern man die Taktraten auch in der Praxis dort hin bekommt, wo jene hingegen sollen. tausche ein g gegen ein h.
Kommt mir vor wie eine Wunschliste an den Weihnachtsmann. Aber sollte Intel das mit einen kleinen Abschlag hinbekommen. Würde es den Markt beleben was Gaming CPU angeht.

[Badesalz]

Habt ihr eigentlich den Prozentsatz an Spielen mitbekommen die in heimischen Auflösungen CPU-limitiert laufen? :usweet:

[Leonidas]

Last-Level-Cache würde ich das nicht nennen, das ist ein ganz gewöhnlicher L3.Steht auch so in dem verlinkten Video mit Timestamp.

Nunja, die Abkürzung bLLC wurde aber verwendet und habe ich daher auch wiedergegeben. Auch Intel sagt zum L3 gern LLC - einfach nur als Ausdruck dessen, das es der letzte Cache vor dem DRAM ist, nicht als Ausdruck dessen, wo jener konkret liegt.


tausche ein g gegen ein h.

;) Gefixt.

[Badesalz]

Schemabild des Lova-Lake? ;)

Premium Gaming in 8+16+4. Die haben den Knall imemrnoch nicht gehört :ulol: Als wenn die Leute sich above 2025 mit sinnloser core-flood und je nach Modell portionierten V-Cache - bei gleicher core-flood! - verarschen lassen würden :ufinger:

Die sind immernoch sowas von von vorgestern.

[Zossel]

einfach nur als Ausdruck dessen, das es der letzte Cache vor dem DRAM ist, nicht als Ausdruck dessen, wo jener konkret liegt.

Laut den Bildern nur für die CPU.

BTW: Was ist eigentlich der Unterschied zwischen Tiles und Chiplets?

[Leonidas]

Schemabild des Lova-Lake? ;).

Wunderbarer Fehler. Aber trotzdem gefixt.


BTW: Was ist eigentlich der Unterschied zwischen Tiles und Chiplets?

Eigentlich keiner. Intel wollte es nicht "Chiplets" nennen, damit es nicht so aussieht, als würde man gegenüber AMD (Jahre später) nachziehen. Die technische Differenz des Packagings würde ich als marginal einschätzen, hat jedenfalls keine Bedeutung gegenüber "Tiles" oder "Chiplets".

[Zossel]

Eigentlich keiner. Intel wollte es nicht "Chiplets" nennen, damit es nicht so aussieht, als würde man gegenüber AMD (Jahre später) nachziehen. Die technische Differenz des Packagings würde ich als marginal einschätzen, hat jedenfalls keine Bedeutung gegenüber "Tiles" oder "Chiplets".

Das stiftet nur Verwirrung.
Und warum will man verschleiern das Intel der Nachzügler ist?

[Badesalz]

Wie so oft diesmal in #4 wieder was falsche gefragt oder?

edit:
Paul's Hardware :ulol:
https://www.youtube.com/watch?v=klxb7JpT2Ss

[Gast Ritis]

Das APO+ Programm zieht einem direkt die Zehnägel hoch. EXE-Files gegen Intel-Optimierte Varianten austauschen?
So weit ist es mit deren CPUs gekommen. AMD hatte als Underdog gegen Intel-opimierte Compilate nie viel dagegenzusetzen, denen fehlte das Budget und Team selbst 3DNow-optimierte oder Intel-Compiler-Flag freie Executables herzustellen.

Dass Intel heute (vermutlich) AVX10.2 optimierten Code selbst durchdrücken muss zeigt nur wie die das Ding um exclusive ISA-Features tot geritten haben und jetzt darunter leiden.

Ich bin mal gespannt ob das uns länger beschäftigen wird, deren APO-Geschichte ist aber bisher schon recht gruselig.
Wir brauchen ISA-Standards und kompatible Compilate statt Speziallösungen für Spezialfälle.

[crnkoj]

Also wenn der große nova Lake wirklich so kommt, wird es schon spannend, vielleicht ein Neukauf für mich. Nur befürchte ich, dass falls es wahr ist, der Preis über 1k sei wird bzw. Dass die Info einfach falsch ist.
Hort sich ja irgendwie wie Wunschdenken an, so wie früher mit AMD, Vega und "poor volta" kommen ins Gedächtnis...

[Lehdro]

Habt ihr eigentlich den Prozentsatz an Spielen mitbekommen die in heimischen Auflösungen CPU-limitiert laufen? :usweet:
Wie willst du das quantifizieren?

Ich weiß nur das ich mit meinem 9800X3D immer noch in CPU Bottlenecks reinrenne. Mehr CPU Power = mehr gut. Hilft auch sämtliche Unzulänglichkeiten einzudämmen, auf die ich sonst keinen Einfluss habe: traversal stutters wegen Engine fuckups, Treiberoverhead, Shadercompile während des Spielens (:mad:) und auch generelle Snappyness.

[The_Invisible]

Ja CPU Power kann man nie genug haben, auch nicht in 4k. Anno1800 ist da die auflösung ziemlich egal, meine 4090 taktet da in 4k sogar runter, bitte gern so 2x bis 3x mehr CPU Power :D

[Badesalz]

Dass Intel heute (vermutlich) AVX10.2 optimierten Code selbst durchdrücken muss zeigt nur wie die das Ding um exclusive ISA-Features tot geritten haben und jetzt darunter leiden.
1. APO ist der erste Rollator für eine CPU. Du regst dich unnötig auf. JEDER weiß es...

2. Dass Intel heute (vermutlich) AVX10.2 optimierten Code selbst durchdrücken muss zeigt nur wie die das Ding um exclusive ISA-Features tot geritten haben und jetzt darunter leiden.Das ist absolut richtig. Um solchen Mist kümmert sich jetzt aber IMHO die x86 ecosystem advisory group. Die sind alle froh, daß sie schwach genug geworden sind mit solchem Schwachsinn nicht mehr der alleinige bestimmer beim x86 zu sein.
https://newsroom.intel.com/corporate/october-2024-intel-news

Da ist Linus mit dabei und der hat genau diesen Schwachsinn gefressen und schon einige Rants darüber rausgeblasen :rolleyes: Es ist nicht mehr die Zeit wo sie einfach machen konnten was sie wollten.

[Gast]

Eigentlich keiner. Intel wollte es nicht "Chiplets" nennen, damit es nicht so aussieht, als würde man gegenüber AMD (Jahre später) nachziehen. Die technische Differenz des Packagings würde ich als marginal einschätzen, hat jedenfalls keine Bedeutung gegenüber "Tiles" oder "Chiplets".

Intel hat es aber auch schon Chiplet genannt. Und 2018 kam Kaby Lake G. Davon ab, das Intel schon zu Pentium Zeiten MCMs gemacht hat. ^^

https://spectrum.ieee.org/intels-view-of-the-chiplet-revolution

[Leonidas]

Interessant. Aber dann dachte sich das Marketing wohl: "Wir brauchen einen neu klingenden Begriff!"

[Zossel]

Interessant. Aber dann dachte sich das Marketing wohl: "Wir brauchen einen neu klingenden Begriff!"

Der selbe Unsinn wie mit "HT" vs. "SMT", solange man keine Zuwendungen von Intel dafür bekommt muss man den Unfug nicht mitmachen.

[Badesalz]

Bestens. Weswegen ich auch beständig immer von SMT gesprochen habe :up:

Ja CPU Power kann man nie genug haben, auch nicht in 4k. Anno1800 ist da die auflösung ziemlich egal, Anno ist die Galionsfigur bei dem Thema... Manchmal überlege ich, ob es da auch mehr gibt.

[Gast]

Last-Level-Cache würde ich das nicht nennen, das ist ein ganz gewöhnlicher L3.Steht auch so in dem verlinkten Video mit Timestamp.

LLC ist jede höchste Cachestufe auf einem DIE, und als allgemeine Bezeichnung durchaus sinnvoll, weil es es damit egal ist, wie viele Cachestufen es darunter gibt und man damit auch um unnötig verwirrende sprachliche Konstrukte herumkommt, bei dem irgendeine zusätzliche Cachestufe dann plötzlich als L0 oder L x.5 bezeichnet wird, nur um der Vergleichbarkeit wegen die letzte Stufe in der Bezeichnung auf dem selben Level zu halten.

[Gast]

BTW: Was ist eigentlich der Unterschied zwischen Tiles und Chiplets?

Chiplets werden übers Substrat verbunden, Tiles über ein eigenes Interposer-Tile.

[Gast]

Das APO+ Programm zieht einem direkt die Zehnägel hoch. EXE-Files gegen Intel-Optimierte Varianten austauschen?


Machen GPU-Hersteller (auch AMD) nicht anders, die haben es nur einfacher, weil da der Aufführbare Code eh nicht in den Executables liegt sondern vom Treiber erzeugt wird.

So lange es funktional identisch ist, ist daran nichts auszusetzen.

[Platos]

Bezüglich Sockelsupport: Wir wissen ja auch von AMD, was das heisst: Sockelsupport heisst ja noch laaange nicht, dass auch jedes Mainboard mit diesem Sockel dann alle CPUs aller dieser Generationen untersützt.

Wir wissen ja alle, wie dehnbar man solche Aussagen (wenn Intel sie dann getätigt würde) auslegt.

[Badesalz]

Bezüglich Sockelsupport: Wir wissen ja auch von AMD, was das heisst: Sockelsupport heisst ja noch laaange nicht, dass auch jedes Mainboard mit diesem Sockel dann alle CPUs aller dieser Generationen untersützt.Was gab es da so für Ausreißer?

Machen GPU-Hersteller (auch AMD) nicht anders, die haben es nur einfacher, weil da der Aufführbare Code eh nicht in den Executables liegt sondern vom Treiber erzeugt wird.Dann ist es nicht das Gleiche und nicht das Selbe. Und neben Execs die man erst zusammenbacken kann würde es ggf. auch Sinn mache paar DLLs so zu backen.
Am Ende hast du neu durchgekaute Compilate die es auch erst geben muss. Bei Grakas passiert das prinzipiell, generell, automatisch.

NULL Vergleichbarkeit. Die Typen machen NUR Chaos. Angefangen mit SSE über weiter unzählige ISA Exklusivitäten und nun nochmals dazu über APO(+).

Ich hoffe wieterhin, daß die "x86 ecosystem advisory group" dem einen Riegel vorschiebt oder sie sonst einfach rausschmeißt :mad: Mal sehen wie sie damit klarkommen, wenn keiner von denen sie berücksichtigt.

[Gast]

Bestens. Weswegen ich auch beständig immer von SMT gesprochen habe :up:

Anno ist die Galionsfigur bei dem Thema... Manchmal überlege ich, ob es da auch mehr gibt.

Cities Skylines 2 nutzt auch jeden Core den es bekommt - zumindest bis 64 Stück.

[Zossel]

Machen GPU-Hersteller (auch AMD) nicht anders, die haben es nur einfacher, weil da der Aufführbare Code eh nicht in den Executables liegt sondern vom Treiber erzeugt wird.

Du verwechselst GPU-Code und CPU-Code.

[Zossel]

Chiplets werden übers Substrat verbunden, Tiles über ein eigenes Interposer-Tile.

Bei den KI/HPC-Teilen von AMD werden "Tiles" verwendet?

[Zossel]

LLC ist jede höchste Cachestufe auf einem DIE, und als allgemeine Bezeichnung durchaus sinnvoll, weil es es damit egal ist, wie viele Cachestufen es darunter gibt und man damit auch um unnötig verwirrende sprachliche Konstrukte herumkommt, bei dem irgendeine zusätzliche Cachestufe dann plötzlich als L0 oder L x.5 bezeichnet wird, nur um der Vergleichbarkeit wegen die letzte Stufe in der Bezeichnung auf dem selben Level zu halten.

Wie ich bereits schrub würde ein LCC auf alle Busmaster wirken.

[Exxtreme]

Machen GPU-Hersteller (auch AMD) nicht anders, die haben es nur einfacher, weil da der Aufführbare Code eh nicht in den Executables liegt sondern vom Treiber erzeugt wird.

So lange es funktional identisch ist, ist daran nichts auszusetzen.

Also ich sehe da schon ziemlich große Probleme auf Intel zukommen. Es ist oft so, dass die Spielehersteller bestimmte Compiler-Optimierungen deaktivieren weil das sonst Bugs in ihrer Software aktivieren würde. Kommt jetzt Intel daher und ersetzt den unoptimierten fehlerhaften Code durch optimierten fehlerhaften Code dann könnte das diese Bugs aktivieren und die Spiele würden anfangen abzustürzen.

Kann also sein, dass nur sehr wenige Spiele unterstützt werden durch APO+ bei denen man weiss, dass sie kaum Bugs enthalten.

[Gast]

Kommt jetzt Intel daher und ersetzt den unoptimierten fehlerhaften Code durch optimierten fehlerhaften Code dann könnte das diese Bugs aktivieren und die Spiele würden anfangen abzustürzen.



Glaubst du ernsthaft, Intel würde einfach würfeln und Code austauschen ohne ihn zu testen?

[Zossel]

Also ich sehe da schon ziemlich große Probleme auf Intel zukommen. Es ist oft so, dass die Spielehersteller bestimmte Compiler-Optimierungen deaktivieren weil das sonst Bugs in ihrer Software aktivieren würde. Kommt jetzt Intel daher und ersetzt den unoptimierten fehlerhaften Code durch optimierten fehlerhaften Code dann könnte das diese Bugs aktivieren und die Spiele würden anfangen abzustürzen.

Kann also sein, dass nur sehr wenige Spiele unterstützt werden durch APO+ bei denen man weiss, dass sie kaum Bugs enthalten.

Compiler von z.b Z80 auf 808[86] gab es schon früher.

So ist das erste DOS relativ früh zu Anwendungssoftware gekommen.
Und DOS zu diesen völlig bekackten FCBs von CPM gekommen.

[Exxtreme]

Glaubst du ernsthaft, Intel würde einfach würfeln und Code austauschen ohne ihn zu testen?

Wenn ich mir die Qualität der Software von Intel so anschaue ... ;)

Und so ein Code-Austausch ist nicht so ohne Weiteres möglich. Denn da spielen dann so Dinge wie Anticheat, Patchstand der .exe etc. eine Rolle. Und nein, es wird wahrscheinlich auch keine generische Lösung dafür geben. Denn das berühmt-berüchtigte Halteproblem steht hier im Weg.

[Badesalz]

Ist dieser Schwachsinn nicht eh nur bis Titan nötig? Das ist doch eh bald wieder vorbei :uup:
Neben APO, denkt auch an DTT :whistle:

Man könnte die Brüder mit ihrem Kasperle Theater auch einfach ignorieren.

[Zossel]

Wenn ich mir die Qualität der Software von Intel so anschaue ... ;)

Und so ein Code-Austausch ist nicht so ohne Weiteres möglich. Denn da spielen dann so Dinge wie Anticheat, Patchstand der .exe etc. eine Rolle. Und nein, es wird wahrscheinlich auch keine generische Lösung dafür geben. Denn das berühmt-berüchtigte Halteproblem steht hier im Weg.

Die ersten Versionen von VMware haben das Problem der nicht vorhanden HW-Unterstützung für Virtualisierung durch Code-Tausch zu Laufzeit gelöst.

[Zossel]

Ist dieser Schwachsinn nicht eh nur bis Titan nötig? Das ist doch eh bald wieder vorbei :uup:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13796259&postcount=26

[Exxtreme]

Die ersten Versionen von VMware haben das Problem der nicht vorhanden HW-Unterstützung für Virtualisierung durch Code-Tausch zu Laufzeit gelöst.

Welchen Code hat VMWare denn da getauscht?

[Gast]

Du verwechselst GPU-Code und CPU-Code.

Es handelt sich immer noch um Code, dass x86 den Code direkt in die Executable packt ist ja nur der Legacy geschuldet. Als die ersten Programmierbaren GPUs erschienen war man eben schon schlauer und hat mitgedacht, dass neue Hardware neue Optimierungen benötigen könnte, und man vor allem bei der Hardwareentwicklung nicht durch ewig mitgeschleifte Legacy eingeschränkt wird.

[Gast]

Welchen Code hat VMWare denn da getauscht?

Den vom OS, der Kernel erwartet ja in Ring0 zu laufen, was er in einer VM nicht kann, da in Ring0 der Hypervisor läuft. Kernelcode der Ring0 voraussetzt muss von der VM ersetzt werden, damit er trotzdem lauffähig bleibt.

[Zossel]

Welchen Code hat VMWare denn da getauscht?

Systemcalls bzw. Softwareinterrupts/Traps/Exceptions und alles was privilegierten Kram anfasst wurde zu Laufzeit durch direkte Calls in den Hypervisior ersetzt.

[Zossel]

Es handelt sich immer noch um Code, dass x86 den Code direkt in die Executable packt ist ja nur der Legacy geschuldet.

Kannst du das bitte noch mal klarer formulieren?

Ansonsten wird der konkrete GPU-Code aus dem intermediate code den die Applikation mitliefert für das GPU-Target zur Laufzeit passend compiliert.

[Lehdro]

Was gab es da so für Ausreißer?

Threadripper 3000/5000

Während EPYCs von Zen bis Zen 3 auf demselben Sockel SP3 und auch theoretisch allen Boards laufen, gibt es bei HEDT Sprünge zwischen TR4, sTRX4 und sWRX8 (alles LGA 4094, SP3r2, SP3r3, SP3r4). Erster kann Zen und Zen+, der zweite tatsächlich nur Zen 2. Letzterer kann Zen 2 und Zen 3 Threadripper, allerdings nur als explizite Pro Ausführung (WX) für den Sockel. Erst mit DDR5 hat AMD das Threadripper Chaos halbwegs in den Griff bekommen.

[Gast]

Kannst du das bitte noch mal klarer formulieren?


Auf jeder Hardware läuft Maschinencode, und dieser wird immer automatisch erzeugt, sei es aus einer Hochsprache, aus einer Intermediate Language, und wenn Intel jetzt meint sie können vorhandenen Maschinencode in einen übersetzen der besser auf ihrer Hardware läuft, why not. Schadet niemanden, und nützt potentiell Intel, bzw. den Besitzern derer Hardware.

[Badesalz]

Was für ein Gehirnfurz... Na ich hoffe die gehen nicht an jede Soft dran die zum Benchen genutzt wird. Wie z.B.... VeraCrypt :ulol:

[Zossel]

Was für ein Gehirnfurz... Na ich hoffe die gehen nicht an jede Soft dran die zum Benchen genutzt wird. Wie z.B.... VeraCrypt :ulol:

Benchmarks sind das kleinste Problem.
Bei Crypto könnten SideChannels dadurch entstehen, oder absichtliches Löschen von Speicher weg optimiert werden.

[Badesalz]

Ja. Das war mein Gedanke ;) Das Ding wäre eben gefährdet (seitens Intel), weil es eben für Benches genommen wird.

APO entwickelt man nicht in 1 Monat. Das ist eben ein Gehirnfurz der vergangenen Tage was nun läuft. P+E werden ja wieder abgeschafft. SMT kommt zurück.

[Zossel]

Ja. Das war mein Gedanke ;) Das Ding wäre eben gefährdet (seitens Intel), weil es eben für Benches genommen wird.

APO entwickelt man nicht in 1 Monat. Das ist eben ein Gehirnfurz der vergangenen Tage was nun läuft. P+E werden ja wieder abgeschafft. SMT kommt zurück.

Wie löst man das eigentlich bei Java?

[Badesalz]

Wenn es keine Problemstellung gibt, wird nicht nach einer Lösung gesucht. Und jetzt hör auf Probleme zu erfinden :wink:

[Gast]

Wie löst man das eigentlich bei Java?

Java wird in der Regel sowieso erst zur Laufzeit kompiliert.

[Zossel]

Wenn es keine Problemstellung gibt, wird nicht nach einer Lösung gesucht. Und jetzt hör auf Probleme zu erfinden :wink:

Der Fall wo es funktioniert ist nicht von Interesse.
Der Fall wo es nicht funktioniert ist der Interessante.

[Gast]

Bei Crypto könnten SideChannels dadurch entstehen, oder absichtliches Löschen von Speicher weg optimiert werden.

Die können durch OOE genauso entstehen, und genau dafür wurden Fences geschaffen in denen die CPU keine Optimierungen durchführen darf.

"Löschen von Speicher" ist schon ein sehr schon ein sehr konstruierter Fall. Erstmal gibt es das gar nicht, Speicher wird entweder freigegeben, er wird also nur dereferenziert, ohne den Inhalt zu ändern, oder er wird überschrieben. Das "wegzuoptimieren" ist unmöglich, dafür müsste man jeden möglichen Programmablauf kennen und wissen dass auf den Speicher nie mehr zugegriffen wird. Das kann man unmöglich herausfinden, daher kann man auch einen Befehl, überschreib mir den Adressbereich XXX mit 0en nicht einfach weglassen.
Zudem ist der Speicher für Userspace-Prozesse vollständig virtualisiert, jede Anwendung kann also nur ihren eigenen Speicherbereich sehen, und die kann ihn sowieso sehen. Eine andere Anwendung hat keinen Zugriff auf den Speicherbereich, ein mögliches Secret kann also nur die Anwendung selbst aus ihrem eigenen Speicherbereich leaken.

[Zossel]

Java wird in der Regel sowieso erst zur Laufzeit kompiliert.

Und woher weis der Compiler das er z.b. ein von den Eingangsdaten unabhängiges Zeitverhalten erhalten soll?

[Zossel]

Die können durch OOE genauso entstehen, und genau dafür wurden Fences geschaffen in denen die CPU keine Optimierungen durchführen darf.

"Löschen von Speicher" ist schon ein sehr schon ein sehr konstruierter Fall. Erstmal gibt es das gar nicht, Speicher wird entweder freigegeben, er wird also nur dereferenziert, ohne den Inhalt zu ändern, oder er wird überschrieben. Das "wegzuoptimieren" ist unmöglich, dafür müsste man jeden möglichen Programmablauf kennen und wissen dass auf den Speicher nie mehr zugegriffen wird. Das kann man unmöglich herausfinden, daher kann man auch einen Befehl, überschreib mir den Adressbereich XXX mit 0en nicht einfach weglassen.
Zudem ist der Speicher für Userspace-Prozesse vollständig virtualisiert, jede Anwendung kann also nur ihren eigenen Speicherbereich sehen, und die kann ihn sowieso sehen. Eine andere Anwendung hat keinen Zugriff auf den Speicherbereich, ein mögliches Secret kann also nur die Anwendung selbst aus ihrem eigenen Speicherbereich leaken.

Es ist ist bei Crypto-Sachen gängige Praxis sensible Sachen explizit zu "überschreiben". (Zufrieden?)
Und Compiler erkennen ziemlich gut wenn irgendwas nicht mehr verwendet wird und schmeißen alles weg was dahin führt. Nicht umsonst gibt es "void" in "C".

[Exxtreme]

Die können durch OOE genauso entstehen, und genau dafür wurden Fences geschaffen in denen die CPU keine Optimierungen durchführen darf.

"Löschen von Speicher" ist schon ein sehr schon ein sehr konstruierter Fall. Erstmal gibt es das gar nicht, Speicher wird entweder freigegeben, er wird also nur dereferenziert, ohne den Inhalt zu ändern, oder er wird überschrieben. Das "wegzuoptimieren" ist unmöglich, dafür müsste man jeden möglichen Programmablauf kennen und wissen dass auf den Speicher nie mehr zugegriffen wird.

So simpel ist das nicht. Z.B. in Java werden so Dinge wie Passwörter oder Tokens sehr oft in einem char-Array gespeichert und nicht in einem String. Denn ein char-Array kannst du nach dem Benutzen explizit mit anderen Daten überschreiben, einen String nicht. Strings sind unveränderlich in Java. Du kannst der String-Referenz zwar einen anderen String oder null zuweisen, sodass er vom Programm selbst nicht mehr erreichbar ist. Aber er bleibt trotzdem auf dem Heap bis der Garbage Collector ihn gelöscht hat. Und wenn der GC gut konfiguriert ist dann kann das länger dauern bis der String weg ist. Und dann haben Angreifer Zeit einen Dump der JVM zu erzeugen.

[Gast]

Und dann haben Angreifer Zeit einen Dump der JVM zu erzeugen.

Dafür müssen sie sich bereits im Kernel der Maschine eingenistet haben, dann hast du eh schon verloren.

[Exxtreme]

Dafür müssen sie sich bereits im Kernel der Maschine eingenistet haben, dann hast du eh schon verloren.

Nein. Mit dem Befehl jmap kannst du JVM dumps erstellen.

https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr014.html

[Zossel]

Dafür müssen sie sich bereits im Kernel der Maschine eingenistet haben, dann hast du eh schon verloren.

Auch an den Speicher von non-java Prozessen kommt man auch ran, braucht ja jeder Debugger, oder man schickt lustige Signale um einen Core zu erzeugen.
Es ist einfach kein best practice Sachen die man nicht mehr braucht im Speicher liegen zu lassen.
Eigentlich müsste man den Speicher wo richtig sensible Sachen liegen auch mit mlock(2) vorm swappen zu schützen.