How does this project compare to the existing machine code compilers, namely Valgrind's VEX library and Qemu's tiny code generator (https://wiki.qemu.org/Documentation/TCG)?
My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.
I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.
Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.
Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.
Are there any languages which do something like this?
That's exactly how the current implementation of std::string works in C++. The techniques that have been used to implement that mechanism can be applied to any other reference-counted C++ class.
Context switches can be as cheap as two machine instructions (loading a task structure pointer into a register, and jumping to a code address). Modern systems have caches, and context switches typically cause many cache misses. This has an important negative impact on performance.
Within QNX, which really is a microkernel, almost everything is preemptable. All the kernel does is pass messages, manage memory, and dispatch the CPUs.
Your comment is incomplete and not completely correct.
One topic you touched is the choice of locking versus message passing for communication between threads. With a monolithic kernel like Linux you have the choice between locking and message passing. With a microkernel like QNX you don't have a choice -- message passing is the only option. This matters because the more messages that are passed, the more context switches that are needed. And each context switch takes some time. Which means that microkernels have a throughput disadvantage.
Your post seems to suggest that the option of passing messages between subsystems in the Linux kernel is not available. This is very well possible.
Regarding multiple CPU's and spinlock-based systems: aren't you aware that with Linux-rt all spinlocks are converted into preemptible mutexes ?
Or: the latency issue you touched is real. But stating that the latency of a microkernel is better than the latency of a monolithic kernel is wrong. And you seem to be unaware of Linux-rt.
I'm a Cisco employee, and I am involved in weekly conference calls with MontaVista for an embedded Linux project. MontaVista really solves the issues we report to their support department, although not always as fast as we would like it.
When starting a new embedded project, not only an operating system has to be chosen but it also has to be decided which CPU will be used in the project (Intel-architecture, PPC, MIPS or ARM). You cannot choose a CPU and ignore the operating system, and you cannot choose an operating system while ignoring the CPU it will run on. What I learned the hard way is that it is important to choose a mainstream CPU, even if this means that it will consume a little bit more power or takes up some more PCB space. Otherwise you might be surprised some day that the embedded Linux vendor drops support for the CPU you selected for your project.
Slashdot Mirror
How does this project compare to the existing machine code compilers, namely Valgrind's VEX library and Qemu's tiny code generator (https://wiki.qemu.org/Documentation/TCG)?
My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.
I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.
Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.
Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.
Are there any languages which do something like this?
That's exactly how the current implementation of std::string works in C++. The techniques that have been used to implement that mechanism can be applied to any other reference-counted C++ class.
Within QNX, which really is a microkernel, almost everything is preemptable. All the kernel does is pass messages, manage memory, and dispatch the CPUs.
Your comment is incomplete and not completely correct.
One topic you touched is the choice of locking versus message passing for communication between threads. With a monolithic kernel like Linux you have the choice between locking and message passing. With a microkernel like QNX you don't have a choice -- message passing is the only option. This matters because the more messages that are passed, the more context switches that are needed. And each context switch takes some time. Which means that microkernels have a throughput disadvantage.
Your post seems to suggest that the option of passing messages between subsystems in the Linux kernel is not available. This is very well possible.
Regarding multiple CPU's and spinlock-based systems: aren't you aware that with Linux-rt all spinlocks are converted into preemptible mutexes ?
Or: the latency issue you touched is real. But stating that the latency of a microkernel is better than the latency of a monolithic kernel is wrong. And you seem to be unaware of Linux-rt.
Are you perhaps a QNX-salesman ?
I'm a Cisco employee, and I am involved in weekly conference calls with MontaVista for an embedded Linux project. MontaVista really solves the issues we report to their support department, although not always as fast as we would like it.
When starting a new embedded project, not only an operating system has to be chosen but it also has to be decided which CPU will be used in the project (Intel-architecture, PPC, MIPS or ARM). You cannot choose a CPU and ignore the operating system, and you cannot choose an operating system while ignoring the CPU it will run on. What I learned the hard way is that it is important to choose a mainstream CPU, even if this means that it will consume a little bit more power or takes up some more PCB space. Otherwise you might be surprised some day that the embedded Linux vendor drops support for the CPU you selected for your project.