Java Virtual Threads Ate My Memory: A Web Crawler's Tale of Speed vs. Memory

Re:Java Virtual Threads Ate My Memory: A Web Crawler's Tale ... by koito17 on Friday May 30, 2025 @11:40PM (#44141701)

In Java, there are two kinds of Throwable instances[1]: Error and Exception. As the name suggests, OutOfMemoryError is a subclass of Error. In contrast to Exception, an Error "indicates serious problems that a reasonable application should not try to catch"[2]. For this reason, it's considered bad practice in Java to catch all Throwable instances (or catch Error instances explicitly).

> My instinct would be to catch OOM early

OutOfMemoryError subclasses VirtualMachineError, and when a VirtualMachineError is thrown, your program seems to be firmly in undefined behavior territory. Quoting the JVM specification [3]:

  A Java Virtual Machine implementation throws an object that is an instance of a subclass of the class VirtualMachineError when an internal error or resource limitation prevents it from implementing the semantics described in this chapter. This specification cannot predict where internal errors or resource limitations may be encountered and does not mandate precisely when they can be reported.

For context: "this chapter" refers to the whole chapter describing the behavior of each JVM instruction. The specification seems to suggest that all bets are off on any guarantees the JVM makes by the time a VirtualMachineError is thrown.

[1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

[2] https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

[3] https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.h...

[ Parent | on HN ]

Re:Java Virtual Threads Ate My Memory: A Web Crawler's Tale ... by fulafel on Saturday May 31, 2025 @03:17AM (#44142542)

Is this a hole in the safety guarantees?

[ Parent | on HN ]

Re:Java Virtual Threads Ate My Memory: A Web Crawler's Tale ... by PhilipRoman on Saturday May 31, 2025 @06:12AM (#44143228)

Safety can mean many things. I'm fairly sure JVM will keep the C-level memory safety guarantee after an OOM, but you can still end up with Java objects in inconsistent states that will start throwing exceptions when you poke them.

The reason why these exceptions are so "unsafe" is that they can occur at any moment. Maybe you were in the middle of modifying some data structure which will enter an infinite loop the next time you touch it. It's a bit like signals in C where you have to be extremely careful about the APIs you use, except worse because exceptions unwind the stack. At least in C you can still safely call kernel syscalls regardless of userspace state.

[ Parent | on HN ]

Re:Java Virtual Threads Ate My Memory: A Web Crawler's Tale ... by fulafel on Saturday May 31, 2025 @09:33AM (#44144192)

Yep, it sounds ambiguous. So if there's potentially unsafety allowed in the semantics it would already be interesting. If it turns out that the specification permits "all bets are off" in OOM, eg if it can create conditions where an adversary can gain control of execution in some way, like can happen with synchronisation bugs on some (eg Go) runtimes.

[ Parent | on HN ]