- writebettercI am not, how did they solve that?
- I can't edit my comment any longer, but I really like nullprogram.com
- void* is basically used for ad-hoc polymorphism in C, and it is a vital part of C programming.
^- This let's us pass arbitrary starting data to a new thread.void new_thread(void (*run)(void*), void* context);I don't know whether this counts as "very few use cases".
The Memory Ownership advice is maybe good, but why are you allocating in the copy routine if the caller is responsible for freeing it, anyway? This dependency on the global allocator creates an unnecessarily inflexible program design. I also don't get how the caller is supposed to know how to free the memory. What if the data structure is more complex, such as a binary tree?
It's preferable to have the caller allocate the memory.
^- this is preferable to the variant where it takes the value as the third parameter. Of course, an intrusive variant is probably the best.void insert(BinTree *tree, int key, BinTreeNode *node);If you need to allocate for your own needs, then allow the user to pass in an allocator pointer (I guessed on function pointer syntax):
struct allocator { void* (*new)(size_t size, size_t alignment); void (*free)(void* p, size_t size); void* context; }.* - No, it's not? Using a VM is one way of preventing buffer overflows, it's not orthogonal.
- > A stack based machine? Why?
The JVM being a stack-machine is probably the least controversial thing about it. Wasm, CPython and Emacs all also have a stack-based bytecode language. The value, of course, comes from having a generic machine that you can then compile down into whatever machine code you want. Having a register machine doesn't seem very useful, as it's completely unnecessary for the front-end compiler to minimize register usage (the backend compiler will do that for you).
Specifying classpath isn't fun, I agree with that. Launch performance isn't good, and is generally a consequence of its high degree of dynamicism and JIT compiler, though of course there are ways around that (Leyden).
> I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it
I agree, I also see very little value in manually writing JVM bytecode programs. However, compiling into the JVM classfile format? Pretty darn useful.
- I think it's the realm of maybe in Silicon Valley. That's 5000 dollars. Look at this statement:
> Let's say only about 1/3 of the world's adult population is poised to take advantage of paid tools enabled by AI
2/3 of the world's adult population is between 15 and 65 (roughly: 'working age'), so that's 50% of the working world that is capable of using AI with those numbers. India's GDP per capita is 2750USD, and now the price tag is even higher than 5k.
I don't know how to say this well, so I'll just blurt it out: I feel like I'm being quite aggressive, but I don't blame you or expect you to defend your statements or anything, though of course I'll read what you've got to say.
- You're saying $8 billion to cover interest, another commenter said 80, but the actual article says ""$8 trillion of CapEx means you need roughly $800 billion of profit just to pay for the interest". Eight HUNDRED billion. Where does the eight come from, from 90% of these companies failing to make a return? If a few AI companies survive and thrive (which tbh, sure, why not?) then we're still gonna fall face down into concrete.
- It's a joke
- This is why you should only use /* */ as your comment style.
- >I am very familiar with how Java does locks. This is different. Look at the ParkingLot/parking_lot API. It lets you do much more than just locks, and there’s no direct equivalent of what Java VMs call the inflated or fat lock. The closest thing is the on demand created queue keyed by address.
Are you familiar with the new LightweightSynchronizer approach with an indirection via a table, instead of overwriting the markWord? I'd say that this has pushed the ParkingLot approach and Java's (Hotspot's, really) approach closer to each other than before. I think the table approach in Java could be encoded trivially into ParkingLot API, and the opposite maybe. Obviously the latter would be a lot more hamfisted.
- The students had identical answers, I presume
- This is very similar to how Java's object monitors are implemented. In OpenJDK, the markWord uses two bits to describe the state of an Object's monitor (see markWord.hpp:55). On contention, the monitor is said to become inflated, which basically means revving up a heavier lock and knowing how to find it.
I'm a bit disappointed though, I assumed that you had a way of only using 2 bits of an object's memory somehow, but it seems like the lock takes a full byte?
- In a single-threaded context, I think 'giant array array of bytes' is still correct? Performance, not so much.
> This part of the blog didn't seem very accurate.
It was a sufficient amount of understanding to produce this allocator :-). I think that if we have beginner[0] projects posted and upvoted, we must understand that the author's understanding may be lacking some nuance.
[0] author might be a very good programmer, just not familiar with this particular area!
- Moxie doesn't want to federate, that's the main issue I believe.
- The goal isn't to exchange facts, it's to bond.
- To me, it doesn't. If someone says "tsc is a transpiler", it gives me nothing actionable. If you do say "it transpiles to JS", then I've got something, but that could just be "compiles to JS". It doesn't really tell me how the thing is constructed either.
- What value does the word have? When I'm writing a compiler, it doesn't matter whether I target C or asm, or Javascript, as my output language. I'll still write it the same way.
- I'd probably say that "transpiler" is not a very useful word with that definition.
- I'm sure that if you went back 100 years you'd be less surprised, but of course the rice would've been replaced with oat porridge or potatoes.