hashmash

Just say "tracing garbage collection" to avoid the usual referencing counting arguments.

Because none of the existing software would work. The idea of running a Rosetta-like feature on an 8-bit CPU isn't feasible. The Apple II eventually received an upgraded processor, the 65816, which was compatible with the 6502.

It wouldn't have happened because the 6809 wasn't binary compatible with the 6800.

Yes, I'm familiar with these. Many of the earliest problems were to due bugs in the verifier, and there were several different vendors with their own set of bugs. The bulk of these problems were identified and resolved over 25 years ago.

Most of the later problems are due to the fact that the API attack surface was too large, because of the backwards SecurityManager design. And because it existed, it seems there was little incentive to do something better.

Once the instrumentation API was introduced (Java 5), it made it easier to write agents which could limit access to APIs using an "allow" approach rather than the awful rules imposed by the SecurityManager. Java 9 introduced modules, further hardening the boundaries between trusted and untrusted code. It was at this point the SecurityManager should have been officially deprecated, instead of waiting four more years.

Going back to the earlier comment, the problem isn't due to the runtime being somehow inherently insecure, but instead due to the defective design of the SecurityManager. It hasn't been necessary for providing security for many years.

The Java runtime isn't any more inherently insecure than the JavaScript runtime, and JavaScript seems to work just fine for the web.

The key reason why applet security failed was because it gave you the entire JDK by default, and so every method in the JDK needed to have explicit security checking code in place to restrict access. The model was backwards -- full control by default with selective disabling meant that every new feature in the JDK is a new vulnerability.

The post is pretty much bullshit. Variable names have no impact on performance.

This adds an extra level of friction that doesn't happen when the set of primitive types is small and simple. When everyone agrees what an int is, it can be freely passed around without having to perform special conversions and deal with errors.

When trying to adapt a long to an int, the usual pattern is to overload the necessary methods to work with longs. Following the same pattern for uint/int conversions, the safe option is to work with longs, since it eliminates the possibility of having any conversion errors.

Now if we're taking about signed and unsigned 64-bit values, there's no 128-bit value to upgrade to. Personally, I've never had this issue considering that 63 bits of integer precision is massive. Unsigned longs don't seem that critical.

Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa?

Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when doing less-common, low-level operations.

The first official JIT became available in JDK 1.1, in 1997. The Symantec JIT was available as an add-on sometime in mid 1996, just a few months after JDK 1.0 was released. Even better performance was possible with GCJ, available in 1998.

The release of HotSpot was in 1999, and became default with JDK 1.3 in 2000. It took JIT compilation to the next level, making tools like GCJ mostly obsolete.

If JEP 401 is ever delivered (Value Classes and Objects), then this sort of problem should go away.

At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.

Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.

So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.

What's the elevator pitch? If I'm already happy with the OO language I'm using today, why should I use Nod? What does it do better?

The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible.

JNI was only ever designed to be good enough, and it is. The new FFM API aims to replace JNI in most cases, but it's designed to be "perfect". As a result, the new API took many years to develop, but JNI was quick to develop.

It would be nice to have the FFM API much sooner, but alternatives like JNR and JNA have been around for a long time. There wasn't a rush to develop a JNI replacement.

I guess it depends on what "just fine" means. What happens when a conversion is applied? Is there silent data corruption (C), or is there an exception (Ada, D) or perhaps a panic (Rust, Zig)? Is the behavior dependent on compiler flags?

Keeping unsigned integer types out of the language makes things much simpler, and keeping things simple was an original design goal of Java.

The problem with having unsigned integer types is that it introduces new type conversion issues. If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Or vice versa? A smaller set of primitive types is preferred, since it has fewer conversion issues.

Unsigned integer types are only really necessary when dealing with low-level bit manipulation, but most programs don't do this. The lack of unsigned integers makes low-level stuff a bit more difficult, but it makes the language as a whole much easier. It's a good tradeoff.

The main problem with the keyboard was the non-standard size of the kepcaps. The standard distance between keycaps is 0.75 inches, and the standard top width is 0.5 inches. The Atari ST keycap distance is standard, but the top width is 0.625 inches. Because of this, if your finger isn't exactly centered over the top of the key, it hits the adjacent key too, leading to key jam.

Were you only testing on x86 or any other "total store order" architecture? If so, removing the volatile modifier has less of an impact.

When using the `-XX:+PerfDisableSharedMem` workaround, VisualVM cannot attach to the running process anymore.

Why is an async model better than using OS threads for an I/O bound workload? The OS is doing async stuff internally and shielding the complexity with threads. With virtual threads this work has shifted to the JVM. Can the JVM do threads better than the OS?

The OS scheduler is still there (for the carrier threads), but now you've added on top of that FJ pool based scheduler overhead. Although virtual threads don't have the syscall overhead when they block, there's a new cost caused by allocating the internal continuation object, and copying state into it. This puts more pressure on the garbage collector. Context switching cost due to CPU cache thrashing doesn't go away regardless of which type of thread you're using.

I've not yet seen a study that shows that virtual threads offer a huge benefit. The Open Liberty study suggests that they're worse than the existing platform threads.

But that same benefit was always available with platform threads -- a simple API. What is the real gain by using virtual threads? It's either going to be performance or memory utilization.

The problem with the naïve design is that even with virtual threads, you risk running out of (heap) memory if the threads ever block. Each task makes a bit of progress, allocates some objects, and then lets another one do the same thing.

With virtual threads, you can limit the damage by using a semaphore, but you still need to tune the size. This isn't much different than sizing a traditional thread pool, and so I'm not sure what benefit virtual threads will really have in practice. You're swapping one config for another.

William Anders never walked on another world.

The CoCo 3 had a custom chip which provided an MMU and a few other features, but the maximum amount of memory it supported was 512KB. Page size was fixed at 8KB.

With Java, the default encoding when converting bytes to strings was originally platform independent, but now it's UTF-8. UTF-16 and latin-1 encodings are (still*) used internally by the String class, and the JVM uses a modified UTF-8 encoding like it always has.

* The String class originally only used UTF-16 encoding, but since Java 9 it also uses a single-byte-per-character latin-1 encoding when possible.

There's no hard guarantee that freeing an object runs in constant time. Reference counting tends to provide more predictable performance, but I don't think the phrase "hard guarantee" is appropriate.

PRQL has some very nice features, but the syntax also has some not so nice features that you don't see in the examples. There's special parsing rules for parenthesis and newlines, and a special word wrap character is needed at times to disable the rule that treats newlines as the pipe operator.

PRQL is actually a first class functional programming language, with syntax for supporting readable query processing pipelines. The documentation for PQL is a bit light, so I don't know if it's as powerful as PRQL.

It would have had little to no impact. To run it, you need the 512KB upgrade and a disk drive. To get decent looking graphics you'd also need to shell out money for an RGB monitor. It would have been substantially cheaper to get an NES and the DK cartridge for it.