181–185 of 185 posts
Earlier quoted context omitted.
Yes - that is a performance optimisation. I don't think comparing everything by value makes or breaks the implementation.
>I don't think comparing everything by value makes or breaks the implementation. Nothing much to think -- distinct objects must have distinct references [e.g. new String("a")!=new String("a')], literals must have the same references for the same values [e.g. "a"=="a"].
Earlier quoted context omitted.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
I'm sure it's not complete, but I also wouldn't be surprised if 99% of what's in HotSpot is optimization tweaks and performance boosts which aren't essential to the JLS.
Earlier quoted context omitted.
> any perceived complexity for implementing a Java VM in hardware has had no practical economic effect, or slowed down implementation meaningfully. This is an assertion that can only be disputed with an alternate universe.
Hardly. That would require an assertion like 'any perceived complexity for implementing a Java VM in hardware did not exist because it was rolled out in the most economic way possible given non-technical constraints, and it also did not slow down the implementation beyond the minimum absolutely necessary for any technical solution possible.'. Notice the difference? To propose alternative solutions based on practical…
No.
> If the solution was rolled out within a timeframe considered useful/expected for this kind of solution, then it also didn't slow down implementation meaningfully - as in it didn't block it, or add serious delay.
Also no.
Earlier quoted context omitted.
Funnily enough I did the same in an early wip version of my toy JVM. Ended up using unsafe to use 'static references internally but only hand out wrappers that include a reference to the JVM. This also ensures that objects/classes/… from one JVM can't be used in another one.
Could you not pass around Mutex performantly?
Earlier quoted context omitted.
I've heard very inconsistent things about this, which is interesting. Often people say Rust is less productive, as there's often "makework" involved with satisfying the borrow checker. I suspect a lot of it revolves around how you perceive that sort of thing: it can be cast as both productivity (satisfying it can potentially rule out bugs) or a loss of productivity (you were already satisfied the code was correct). B…
I'm about 2 years into primarily writing Rust (after a long time in the .NET world). The borrow checker slowed me down a lot at the start but these days it's not a big deal. Eventually you internalize the easiest ways to make it happy (clone and pass references as needed) and can reserve tricky optimizations for hot paths where they actually matter. I would say that today, most of the times I sit down to write some R…