121–130 of 245 posts
> today AWS will happily rent you an x1e.32xlarge with 128 vCPUs and an incredible 3,904GB of ram. > ... > ZGC restricts itself to 4Tb heaps Isn't a 4TB heap limit short-sighted for a GC intended to last over a decade?
If anything, borrow a few more bits, and you should easily be able to address petabytes.
Earlier quoted context omitted.
> Java is already suitable for game development, specially with LibGDX. I think it is safe to assume that under "game development" most people understand rather high performance demands, not a solitaire clone (esp since the comment you responded to pointed out pause-times as crucial).
You can also make a 3d game of large scale, and just let it have hiccups occasionally and still make a billion dollars. Of course those of us hosting servers for that particular game would have saved a ton of money and pain if they had not used Java, or used Java more cleverly.
One can make a game in C++ and make it just as bad.
Earlier quoted context omitted.
With the exception of Go and C#, there are no limitation on value types. All those languages are GC enabled systems programming languages. Regarding Go the memory safety in multithreaded code is orthogonal to having support for value types or not.
It's not orthogonal at all. Nontrivial mutations to multi-word sized values are inherently racy operations that can lead to UB if you don't have restrictions on how value types can be used. D isn't memory safe; Active Oberon employs mandatory object locking on writes (which is a rather heavy runtime solution); Cedar values are either immutable, or always valid with respect to word sized mutations (as far as I can tel…
We are discussing GC enabled systems programming languages with support for unsafe operations, not Rust's idea of thread safety.
D is memory safe in the context of @safe code, of course @system code is unsafe.
Active Oberon and Modula-3 also have record types, strings and arrays that can be stack allocated, declared on the global data memory segment or just manually allocated in unsafe packages.
In both cases I can also declare untraced pointers for memory blocks in unsafe packages, that the GC will gladly ignore.
Earlier quoted context omitted.
Wasn't Minecraft originally written in Java? Might still be.
Yes. But I believe that Microsoft made an improved version written in C++ after the acquisition.
Earlier quoted context omitted.
With the exception of Go and C#, there are no limitation on value types. All those languages are GC enabled systems programming languages. Regarding Go the memory safety in multithreaded code is orthogonal to having support for value types or not.
If the manually allocated memory may contain references to managed objects then it still needs to be traced by the gc. That or you start pinning managed objects or pull everything related into manual world. Both kinda suck.
In any case, the point is that you should only do that for the code paths that actually matter, after profiling the application and not everywhere.
Be productive, make use of the GC, naturally taking into the consideration the algorithms + data structures being used.
If that is still not enough to meet the application's SLAs, then manually allocation comes into play.
Earlier quoted context omitted.
How so in the case of using GPL code?
I'm not completely sure because I'm not familiar with the topic, but maybe it has to do with the fact that even when they sue you with an impossible-to-win lawsuit, they can destroy you with the cash you need to expend to even start defending yourself. This can also destroy investment rounds for many startups.
Earlier quoted context omitted.
512 bytes here.
What kind of PC had 512 bytes of RAM?
Earlier quoted context omitted.
I'm not completely sure because I'm not familiar with the topic, but maybe it has to do with the fact that even when they sue you with an impossible-to-win lawsuit, they can destroy you with the cash you need to expend to even start defending yourself. This can also destroy investment rounds for many startups.
Okay but they can do that even if you don't use Java.
They could sue you, with a higher chance of winning, for using a python, a js or a ruby than for using OpenJDK derived code.
Earlier quoted context omitted.
It's not orthogonal at all. Nontrivial mutations to multi-word sized values are inherently racy operations that can lead to UB if you don't have restrictions on how value types can be used. D isn't memory safe; Active Oberon employs mandatory object locking on writes (which is a rather heavy runtime solution); Cedar values are either immutable, or always valid with respect to word sized mutations (as far as I can tel…
I don't get why you are jumping into memory safety in multi-threaded environments. We are discussing GC enabled systems programming languages with support for unsafe operations, not Rust's idea of thread safety. D is memory safe in the context of @safe code, of course @system code is unsafe. Active Oberon and Modula-3 also have record types, strings and arrays that can be stack allocated, declared on the global data…
Record types with fields that don't depend on one another, strings and (fixed-size) arrays only support "uninteresting" mutations that remain valid even in the presence of atomic tearing. They are restricted compared to the general value types that you can have in a language like C++ (for example, sum types, unions, "fat objects" like Go's interfaces, or vectors with dynamic lengths), because for the latter having a write tear can lead to undefined behavior (for instance, overwriting a value vector can lead to the pointed-to vector part temporarily having a different length than the length field would indicate, which can easily lead to a buffer overflow).
The memory safe fragment of D has similar restrictions on its value types to the above. For example, its value arrays must have a size known at compile time.
Of course you can support such features in the unsafe fragment of a language. However, this is a pretty significant deterrent to actually using the feature and idiomatic code will avoid it most of the time.