18 posts • joined 22 Aug 2007
The point of a wel-defined / modern Memory Model is...
1) You can implement full-userland concurrency (locks, semaphores, atomic objects etc.), with "high-level" code in the given language (no recourse to ASM), and no costly context switch to use OS concurrency facilities unless really necessary (inter-process sync).
2) You can do very dangerous and complex, but very fast concurrency algorithms. Code that is tolerant to controlled data races, lock-free concurrent data structures, etc. See for example Java's Disruptor, or even the internals of many java.util.concurrent APIs. Notice that at this level, the Memory Model is not useful to most language end-users (like I say it's really advanced, highly complex programming that's hard to do right with a good and well-defined MM - but impossible without such MM). It's a feature target at experts who write low-level libraries. Most programmers are better off using higher-level things like volatile variables and concurrency APIs.
3) Even for high-level code, the MM makes easier to have compiler optimizations that are powerful and portable because they can happen on the HIR level (dealing with happens-before or similar attributes) and not in the code generation phase (where every CPU is different); each CPU back-end only needs to provide its own lowering of memory model pseudo-instructions. So this is good for multiplatform C++ compilers like GCC and CLANG. Java VMs have long relied on the MM in order to do all sorts of interesting optimizations, such as lock elision (lock/unlock operations are simply discarded when the JIT can prove it's safe... and yeah this happens VERY often). Even much before 2005, JVMs did many dirty concurrency optimizations, it was just not standardized so you could write advanced code that relied on well-defined behavior of races, but it would not be portable.
I don't any patent dangers
WebM is On2's VP8, a commercial codec that was in the market for almost 3 years, and licensed to several customers of the former On2. I guess the patent shitstorm would have already rained. Also, Google's lawyers have certainly done due dilligence on the patent issue as preparation for the WebM launch. And if somebody sues, Google most certainly has the legal/financial resources to defend their position. (They will probably keep selling patent indemnification contracts to big companies willing to use VP8 even now that it's open source.)
Stanford University Network
1) Not necessary, we can just do ahead-of-time native compilation at module installation time (some JVMs already do that - IBM JDK and JRockit already do it, perhaps JDK 7 with Jigsaw will allow a better implementation (modularized, like .NET's GAC) .
2) James Gosling has not been involved in Java's design for a long time, >10 years; he's moved off to other projects like real-time Java, embedded Java and other stuff. He only poses as the "father of Java" in tech conferences but that's just marketing. I am in a few mailing lists from OpenJDK / JDK 7 and JG is nowhere to be seen, doesn't participate (at east publicly) in discussions like the lambdas proposals etc. So, your wish has already been satisfied. (There's already many "real engineers" wearing the hat that was once Gosling's, you just don't have a good knowledge of the Java evolution process. And JG _is_ a "real engineer", we should thank him for many pragmatic decisions that resulted in Java 1.0 which was a hugely successful platform.)
3) I have my own set of pet bugs, everybody has. Many thousands of these bugs, including some very old ones, are fixed in each major release, and a few more continuously in update releases. Time is short, resources limited, users always want a ton of new features for next release, and it often happens that some bugs cannot be fixes without breaking backwards compatibility (even if that's only for broken apps - sometimes there are many such apps, and Sun has support contracts to honor). Yeah life sucks, we'll never get a perfect platform - if you prefer .NET, or the native Windows or Linux or Mac SDKs, they have thousands of bugs too (the proprietary ones only look better because they don't have a public bugtracking system - at least Sun has got the balls to expose its bugs (much before OpenJDK), so we can at least know the perils and work around them while not fixed.)
4) Sun does monetize on the Java platform in many ways - support contracts (they will do anything from fixing bugs that are important for paying customers, to releasing special JDK builds for SAP), licensing for large JavaME/SE/EE vendors who build their own big platforms around Java, etc. Java was actually a lucrative operation of Sun, it was just not big enough to balance the hemorrhaging of money from other operations. (That was probably a failure - Sun's control of Java should have resulted in MUCH more lucrative services; but Sun was never good in marketing and selling anything, from services to servers.)
Anecdotes of large-scale, successful applications built with refcounting don't mean that this technique is adequate to be used 100% of the time, by the VM's automatic memory manager itself. I was myself a fscking good C++ hacker before moving to Java; I've once written a LR(1) parser optimizer that used every trick in the book to make complex transformations in a very complex object graph. Refcounting is one of the good tools you can use in languages like C++ where manual memory management is the rule, and various kinds of alternative / semi-automatic schemes can be added by libraries and conventions.
But a completely different problem is mixing manual and automatic memory management, or implementing fully-automatic memory management with refcounting. There is a TON of literature around automatic memory management, and refcounting has been basically dead for ages. There's are always somebody trying to resuscitate refcounting because it has the obvious advantage of early detection of dead objects, which in theory could allow early freeing and reduced heap usage. Sometimes a refcounting-based research turns out some limited success, e.g. age-based collection of old-gen heaps (google this within JikesRVM research papers), but so far these ideas appear to have important restrictions or for some reason they nevere reach production VMs (hint: non-refcounted GCs may just keep delivering superior performance in the real world). At best, you can find some resemblance of refcounting in the remembered sets of partitioned heaps like Sun's G1; the remset of a particular sice of the heap can be considered a refcount because when it goes down to empty, that slice is known to be completely empty, so it can be either deallocated or recycled without further overhead. But the general idea of refcounting sucks for other reasons than just cycles. Consider free space management; heap defragmentation; concurrent allocation -- think from GC's perspective, not from C++'s perspective and you will see why refcounting is just a bad idea.
To each its own
You can structure the UI in any extend and style you like, from a single tree to an individual field or method for each node, to the usage of some algorithmic code (e.g. loops) embedded in the declarative structure (JKing has beaten me in this part of the reply). In the end, maybe judgments like "is an extremely bad DSL for declaring UIs" are just in the eye of the beholder - I would use the exact same words to describe things like MXML (and once again, goto JKing's words). I agree though that JavaFX is still catching up in the tooling.
Re: Scene Graphs
Some people "see" a scene graph whenever they see a declarative (XML/DSL) representation of the GUI. This, and also stating that the JavaFX Script's syntax makes code "harder to read", tells me that @DrXym is talking about stuff he[she/it] has spent less than 5 minutes learning. OTOH, the dreaded, perceived issue with deeply-nested structures is mostly a fault of sample code that's not written in good style - we don't _have_ to write an entire GUI as a single object tree with 35 levels of indentation, just because the language allows it. Refactoring and modularity best-practices are available to split the scene graph in smaller, more manageable pieces. Even tool-generated code - from good tools, like JavaFX Composer - will do that. The "single monolithic tree" style is OK mostly for graphics resources produced and manipulated only by drawing tools.
@joeuro The classloading is indeed a major problem. It's getting better; the CDS facility in Java5 speeds&shares the loading of most core APIs (though not JITted code), and 6u10-6u18 have important improvements like much better JavaPlugIn cache (e.g., downloaded jars will only be verified once, then future classloads of the same cached jars will not pay the cost of bytecode verification). JDK 7's Jigsaw promises a decent installed module format, even allowing ahead-of-time compilation / JIT caching (although I don't know if they will actually deliver this by FCS, perhaps just in some future minor updates - but at least the underpinning will be there, i.e. a good module system much like .NET's assemblies).
Wrt your other suggestions: most of them are bogus (esp. refcount and other manual memory mgmt tricks). On-stack allocation of objects will be delivered by JDK 7 as a fully automatic optimization - Escape Analysis-based scalar replacement - already implemented in latest JDK7 weeklies so you can test it; this is a bit limited compared to programmer-controlled stack allocation but in the flipside it's completely transparent without any tradeoff in language/typesystem complexity or in requiring more effort from the programmer. "Value types" in general are the major missing perf feature, I've been advocating this myself, and there are some MLVM projects pursuing this (e.g., inlining of array field-in-last-position; tuples).
Most Antivirus kill Java's performance
This is true for all Java apps, FX or not. The biggest problem seems to be that the JVM creates native code on-the-fly, on heap pages that are later remarked as executable. There are also other creepy low-level tricks, like page faults that JVMs use as a method to capture some uncommon events like nullpointer exceptions; complex memory management performed by garbage collectors; tricks employed by JNI in the stacks; on-stack replacement and deoptimization/re-compilation (even more complex churn of JIT-generated native code), etc. To make it worse, all this action is performed by userspace code. Stupid antiviruses expect all programs to exhibit the much simpler (and mostly kernel-space) low-level behaviors of native-compiled programs, so they stomp over Java processes to investigate possible virus attacks all the time. But of course, there's never a virus because the platform is trusted. (Even if there IS a virus due to an exploit of some JVM security bug, I don't think antivirus would have much success to detect a real thread - the exploit would, by necessity of the JVM's dynamics, have a very complex behavior.)
I am not affected because I don't run antiviruses at all, haven't run them for ~10 years without any problem - generally, antiviruses are good only for non-tech users (or for idiots - that get programs from warez/torrent sites without discipline to run a manual scan, etc.). Now I'm running MS Security Essentials because its overhead is minimal - even for Java programs; it's apparently not broken like other AVs, and I can understand that because MS's .NET platform has similar dynamic behavior and MSE should not bring .NET apps to a halt, so perhaps we Java users are just lucky that MS created an AV that's smart enough for the CLR but this also benefits JVMs. My advise, good at least form Vista and Win7, is simple: 1) uninstall all third-party AVs and other security crap; 2) install latest stuff from MS (firewall, MSE); 3) profit.
Works for me...
(Disclaimer: JavaFX enthusiast writing here.) The GeoView works pretty well here. I don't notice scrolling or any other issues with this or other Java/JavaFX applets. Notice that you really need JRE 6u18, and also JavaFX 1.2.3 - this point-release was readied especially to fix a few bugs for the GeoView app, days before the games started. (Unfortunately the JNLP doesn't enforce these runtime versions, it just requires JRE 5+ and JavaFX 1.2+, so the GeoView may run on older crap if you've already got it installed.) And you really need Windows - the JavaFX ports for Mac and Linux are still lagging a bit. On the Mac, the problem is Apple's JDK lag behind Sun's; on Linux the problem is much more severe as Linux's core media stack is a pile of monkey dung, from graphics drivers to the multiple crappy/nonintegrated sound subsystems etc.
The very first time you load the GeoView (or any FX app that's your first FX apps), there is a bigger download time because the JavaFX runtime weighs in ~10Mb, and that's assuming you've already got the latest JRE. But the warm-start is pretty good in my tests (JRE 6u18 is important for that, contains some significant improvs in the Java PlugIn cache where applets are stored).
Notice that GeoView will query its server for specific info, like each country's flag and medals, on demand as you navigate stuff. This data is stored in the Java PlugIn cache (check the JPG and JSON resources) so the next uses will be fast. Perhaps they could pre-load things in the background when the applet is idle, e.g. prefetching data from nodes that are "neighbor" to the node in focus, that would provide an even better perf. Don't blame the platform for everything; app design plays a big role in PERCEIVED performance.
Now, Flash is certainly ahead in deployment, but... I've just seen the Tour De Flex demo... pretty UN-impressive. The deployment is still good, but not brilliant: I already have the latest Flash so the initial UI loads reasonably quick (>5s) and without fuss. But it's certainly not in the "instantaneous" standard of most Flash applets; and I'm just talking the initial screen! Every single menu item I open for specific demos has a VERY noticeable, extra loading time - always several seconds, like the COLD-start of an entire small Java applet. The performance sucks horribly - drawing of the chrome, simple effects like fade when a modal dialog is shown, etc. Try dragging a window with transparency, e.g. in the TileWindow demo, the shitty performance JUMPS in your face. And don't tell me that Flash 10.1 will fix this with GPU acceleration and other enhancements - I AM already using 10.1beta2. (Doing this test on a Q6600 + NVidia Quadro FX1700, it's not a bleeding-edge gamer system but it's pretty decent. God helps Flex on a laptop with some Intel IGP.) The look&feel is nothing to be proud of, nor is the memory usage (a bit HIGHER than JavaFX's GeoView, in my tests).
All in all, for tiny applets there's still no competition to Flash which can cold-start a small SWF in a couple hundreds of milliseconds. But it's a different ball game for Flex/AIR, that demand very large frameworks that are downloaded on demand (and apparently without any decent caching). Flex/AIR is just as much slow-booting and RAM-eating as Java/JavaFX, so the playing field is much more level here (of course Adobe is still ahead in items like tooling, developer midshare, and runtime distribution - but then, they've been 10+ years in this game, so there's still a lot of ground for JavaFX and also Silverlight to catch up).
This decade only ends in Dec 31 2010...
...as any techie is supposed to know.
Just contributed my 'NO'... to God, and to Grylls
God is just myth and Bear Grylls no much different - his program is fun and he's certainly a skilled survivalist, but all the cheating has been well known for some time. For serious stuff go see Les Stroud's Survivorman. He doesn't try to show himself as a living hero - real survivors don't do risky stunts every five minutes, so I guess for some people the program may look boring - and (unlike Bear) Les doesn't make at least one scene almost naked for the female public... but the survival thing is real.
Re artistic licence @AC
Also, Noah certainly KNEW that he was having sex - a completely drunk man (even if not elder) could hardly "perform"... he was just the first to use booze as excuse for inadequate behavior. ;-)
Just move to Java EE...
It's ridiculous that DBMS-specific packages have to be included in the .NET framework in the first place. I guess that .NET is not sufficiently popular so MS could rely that all the ecosystem - DBMS vendors and others like ORM tools etc. - would offer top-rate and free "providers" for everything (like they do for Java EE).
Best news in a long time. BTW, if the market drops JAVA shares back to $3-4 like before the IBM rumors, it's just proof that the market is stupid - IBM says Sun was worth the double, so it is worth the double - and it would be worth much more (on the merits of its current portfolio, revenues and long-term strategy) without the current recession. Remember guys, the stock market valuation is all about making a cents over the next 24h or little longer than that; it's not about the real value of anything.
Now if somebody else (like Cisco or Google) would step in to buy Sun, I don't see much problem. But IBM would be the kiss of death (one way or another) to far too many great Sun techs.
@Kevin Hutchinson: See http://sun.com/cloud. Yes, it's just recently launched (actual deployment apparently open in beta stage), they're almost late in this market, but they are there and the offering seems great.
@Jim: No, HP doesn't have enything that remotely competes with DTrace. Prove me wrong.
Just fixing some FUD...
"Sun makes proprietary Sparc RISC servers" - why proprietary? The CPU is an open standard (see sparc.org), the OS is open source. People consider Intel x86 hardware "open" because it's ubiquitous, but it's Intel that's just going to sue AMD's spinoff Globalfoundries for the right to manufacture x86-compatible CPUs...
"JavaFX mobile nowhere in sight", how?
Perhaps it's you who are very short-sighted, as Java FX Mobile (in beta quality) shipped together with the 1.0 SDK. There are demos marked as Mobile-compatible, the NetBeans for JavaFX includes mobile samples, there are blogs commenting about the mobile stuff (which is btw pretty hot)...
Aside from that blindness, nice and fair coverage. ;-)
"you see an all or nothing scenarios where either all the loads and stores go through or none do."
Obviously, that should be just "...either all the stores go through or none do.", since you cannot rollback reads ;-)
- Asteroid's SHOCK DINO MURDER SPREE just bad luck - boffins
- BEST BATTERY EVER: All lithium, all the time, plus a dash of carbon nano-stuff
- Stick a 4K in them: Super high-res TVs are DONE
- Review You didn't get the MeMO? Asus Pad 7 Android tab is ... not bad
- FTC to mobile carriers: If you could stop text scammers being jerks that'd be just great