News for hackers. Stuff that matters.
Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by pjmlp on Friday September 17, 2021 @07:44AM (#28564272)
You are right not all of them are, some control weapons systems on battleship fleets.

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

Better deflect that incoming missile on time before the next GC pause.

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by WJW on Friday September 17, 2021 @09:36AM (#28565315)
Let's do the math on that shall we.

Aegis is built for defending against missiles going at most mach 4-5. Mach 5 is ~1700 m/s, so during a millisecond GC pause it will travel slightly under 2 meters. Ship-based SAMs will have proximity-fused fragmentation warheads and even back in the 70s those had a kill radius of >100m (see for example https://en.wikipedia.org/wiki/S-75_Dvina). So even a GC pause at the worst possible moment would not significantly impact the probability to hit the target. Even really fast things in the real world are really slow compared to computers.

(Of course, in practice the Aegis system will only provide midcourse corrections to the missile. The fuse and end phase guidance control software would not interface much with the rest of the combat management system anyway.)

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by lmilcin on Friday September 17, 2021 @09:49AM (#28565444)
I think you don't appreciate how rockets kill other rockets.

The rockets close head on (so the speeds add together) and then the rocket trying to kill the other one explodes at right distance to the side of the other rocket, exploding in a cone of debris.

That cone of debris must intersect the other rocket at a right point. It can't just hit anywhere, to reliably kill it must hit a specific part of the other rocket.

So, realistically, you have to time your explosion to something like tens of microseconds.

Also getting there is a control loop problem and it requires very precise control. The more jitter in execution of the control loop the worse steering it will be and less chance it will get to the right place at the right time.

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by WJW on Friday September 17, 2021 @10:19AM (#28565801)
I was a weapons engineering officer for the Dutch navy for 14 years; I'm well aware of the mechanisms involved.

First of all, a SM-2 will not use the flight path you describe as they tend to "dive down" on a sea skimming missile. But even the shorter range Sea Sparrow missiles that do behave as you describe use multiple guidance phases. In the early and mid-phase guidance phases, the radar reflections from the target missile will not be strong enough for the relatively small receiver in the missile, so the system must depend on midcourse guidance updates (little bit to the right, little bit up, etc) from the combat management system on board the launching vessel to navigate to a "close enough" location from where the sensors on board the missile can acquire the target. The end-phase guidance and fuse timings are quite critical, as you say, but they are also not really under command of the CMS but rather done by embedded systems on board the missile. Generation of the mid-course guidance updates is not nearly as time critical and won't suffer much from a 1 ms pause. The error in location estimation of the target due to sensor imperfections (limited angular resolution, clock jitter, athmospheric effects, etc etc) will be way larger than the 2 meter from the GC pause.

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by pjmlp on Friday September 17, 2021 @11:15AM (#28566412)
Impressive, but you need to factor in it is a real time JVM, with corresponding soft real time GC, and hard real time threads.
Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by TeMPOraL on Friday September 17, 2021 @10:29AM (#28565905)
Might be a naive question, but can't you just disable GC while missiles are in the air? Defer it until there are no immediate threats, and then let it catch up, even if it takes a couple of seconds?

I can't imagine a scenario in which an enemy would be able to saturate the defense system with a continuous onslaught that would make the system run out of memory. You'll sooner run out of SAMs and ammo for that fancy gun that's used to shoot down missiles at close range. And if the enemy can mount such an onslaught, then the ultimate GC will soon run anyway - all memory will be released when the ship sinks.

(I think back to that famous story of a missile with a memory leak, whose designers figured the missile will hit its target or run out of fuel faster than it'll run out of memory.)

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by kaba0 on Friday September 17, 2021 @10:55AM (#28566187)
I think it was a satirical answer, that GC can indeed be used for even hard real time systems (though in this case it is a specific hard real time JVM implementation that has a maximum allowed time to spend on GC). Contrary to what many thinks, hard real time is not about speed, but predictability. And calculating even I don’t know how many missile paths is computationally not too hard, compared to eg. even a computer game.

But to answer your question, there are cases where the JVM is used without GC and it runs for a day, and gets restarted at night. Afaik some bank does it for some form of HFT.

Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by lmilcin on Friday September 17, 2021 @11:26AM (#28566569)
Actually, if you think about it, the missile is already equipped with ultimate in garbage collection:)
Re:Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by cesarb on Friday September 17, 2021 @11:54AM (#28566940)
> Actually, if you think about it, the missile is already equipped with ultimate in garbage collection:)

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

"[...] Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention."