Conversation

Notices

1. Embed this notice
   David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Tuesday, 22-Jul-2025 00:28:03 JST David Chisnall (*Now with 50% more sarcasm!*)

   The most annoying thing about our industry is that we go through cycles where we start with a really good idea, but it isn't quite feasible on current computers. Then someone comes along with a less-good version that's actually possible to ship in the mass market. Then an entire generation of programmers grows up with the simplified version, running on computers a thousand times more powerful, and at least a hundred times more powerful than the richer system required. But they have never seen the more complex version and believe that limitations inherited from the simplified version are intrinsic to the problem being solved. And then they come up with something layered on top that repeats the cycle.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 22-Jul-2025 00:28:01 JST ✧✦Catherine✦✧

     in reply to

     • Matt Campbell

     @matt @david_chisnall "Java is slow" is less of a widespread belief now but it sure was a decade ago

     (we have a JVM that can interpret C code from the AST with performance comparable with a batch compiler like LLVM. anything but!)

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Tuesday, 22-Jul-2025 00:28:01 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧
     • Matt Campbell

     @whitequark @matt

     In 2005, I saw a talk but Alan Kay. His big reveal in the middle was that the talk was using Squeak (bytecode-interpreted Smalltalk) and not PowerPoint for his slides. He showed this off by dropping into an inspector and doing some live coding in the middle.

     But the slide a couple before that reveal had contained full-motion video (which was still pretty rare in slides back then). The video had been an MPEG-1 video (so not the latest CODEC: MPEG-2 was feasible to decode on the CPU then, MPEG-4 non-AVC was with an optimised implementation). The CODEC was, itself, written in Smtalltalk.

     Computers are ludicrously fast now. Even the 'slow' Java implementations from the late '90s were an order of magnitude faster than CPython and not that slow on modern hardware. A modern optimising JIT gains you another order of magnitude or so.

     CHERI's capability model is not quite the shape of hardware capability systems from the '60s (different things got faster at different rates, now compute is almost free but non-local memory accesses are very expensive, whereas the converse was true back then), but the entire field was discarded for 20-30 years because RISC showed that you could make simpler computers fast and do things in software on a fast-and-simple core that outperformed doing them in a more complex implementation. Right up until you start to build complex out-of-order pipelines, at which point you realise that you have a lot of fixed overhead per instruction and doing more work per instruction is where the big performance wins come from.

   • Embed this notice
     Matt Campbell (matt@toot.cafe)'s status on Tuesday, 22-Jul-2025 00:28:02 JST Matt Campbell

     in reply to

     @david_chisnall Do you have an example? I'm guessing something like how the classic Macintosh Toolbox and Windows API faked an object-oriented GUI so they could ship on computers not powerful enough to run Smalltalk.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 23-Jul-2025 04:10:52 JST ✧✦Catherine✦✧

     in reply to

     • Matt Campbell
     • ARGVMI~1.PIF

     @argv_minus_one @david_chisnall @matt Java has value types since JDK 8 if i recall

   • Embed this notice
     ARGVMI~1.PIF (argv_minus_one@mastodon.sdf.org)'s status on Wednesday, 23-Jul-2025 04:10:53 JST ARGVMI~1.PIF

     in reply to

     • ✧✦Catherine✦✧
     • Matt Campbell

     @david_chisnall

     That doesn't help for long-lived objects that should have been inlined inside another object. This is a problem for simple wrapper classes like Optional, and it's the reason why it's not recommended to use Optional as anything other than a return value.

     @whitequark @matt

   • Embed this notice
     ARGVMI~1.PIF (argv_minus_one@mastodon.sdf.org)'s status on Wednesday, 23-Jul-2025 04:10:54 JST ARGVMI~1.PIF

     in reply to

     • ✧✦Catherine✦✧
     • Matt Campbell

     @whitequark

     Isn't Java still suffering from the problem of absolutely everything being heap allocated?

     @matt @david_chisnall

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Wednesday, 23-Jul-2025 04:10:54 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧
     • Matt Campbell
     • ARGVMI~1.PIF

     @argv_minus_one @whitequark @matt

     Aside from primitives, every object is allocated from the GC heap, but the degree to which this implies suffering is often overstated. Most objects that would have been stack allocations never escape the young generation and so GC adds very small overhead for them. Stack and GC allocations cost the same amount, only the deallocation costs more in the GC heap. In some implementations, the compiler can do escape analysis and either move non-escaping allocations to the stack or mark them in GC as trivially dead and not needing scanning.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 23-Jul-2025 06:06:43 JST ✧✦Catherine✦✧

     in reply to

     • Matt Campbell
     • ARGVMI~1.PIF

     @argv_minus_one @david_chisnall @matt oh huh I guess I completely misremembered then, thanks!

   • Embed this notice
     ARGVMI~1.PIF (argv_minus_one@mastodon.sdf.org)'s status on Wednesday, 23-Jul-2025 06:06:44 JST ARGVMI~1.PIF

     in reply to

     • ✧✦Catherine✦✧
     • Matt Campbell

     @whitequark

     No, it doesn't. There is a project to introduce them https://openjdk.org/projects/valhalla/ but the project has been in the works for a very long time.

     It will be a very good day for Java when/if Project Valhalla is finally completed. Besides value types, it also aims to allow nullability to be restricted.

     @david_chisnall @matt