Date: Thu, 3 Aug 2000 08:43:00 -0600 (MDT) From: Nate Williams <nate@yogotech.com> To: Michael Robinson <robinson@netrinsics.com> Cc: freebsd-java@FreeBSD.ORG Subject: Re: Linux JDK on FreeBSD (was Re: Alpha JDK 1.2.2 JPDA extension 1) Message-ID: <200008031443.IAA29638@nomad.yogotech.com> In-Reply-To: <200008030637.OAA00807@netrinsics.com> References: <200008030637.OAA00807@netrinsics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >Actually, the latest patchset (and probably patchset 9 as well) could > >probably have been tagged as beta. Personally, I'd like to get rid of > >the redrawing problem some people have before making that jump though. > > Let me quote: > > "October 11, 1999: Work has re-started on the Java2/JDK1.2 port. Expect > an early 'alpha' release in the coming weeks for FreeBSD 3.3-stable/ELF > boxes." > > 10 months in alpha, who knows how many more months in beta, and then a > release, after which the whole process starts all over again for 1.3. Actually, the re-start died in it's infancy until Greg picked it up when I got a new job. > Meanwhile, right now, today, I can use the Sun release of 1.3 for Linux to > do everthing I need to do. What I can't do, though, is use HotSpot, because > it breaks under Linux emulation. > However, since the FreeBSD team doesn't > have any access to the HotSpot code, any plans for access to the HotSpot > code, or any ideas for plans for access to the HotSpot code, this means that > the Linux JDK on FreeBSD today is just as good as the FreeBSD JDK will be > sometime in the year 2002. That's FUD. Sun intends to give us access to everything the Linux folks have. The problem at this point is paperwork, and I'm yelling again at the BSDi folks to help me out here. (Just sent an email off a few minutes ago0> > For real world technology managers making real-world deployment decisions, > very soon the choice will be between running slow-slow-slow Java on > FreeBSD or running fast-fast-fast Java on Linux. Or running even faster on NT, or Solaris. :( > >(b) Lets say an excellent kernel thread interface (for instance) develops > > during the 5.0 production cycle. > > Let's say the tooth fairy comes and debugs all my code for me while I'm > sleeping. But I digress... No, he's serious. Currently FreeBSD is working on an implementation of 'real scalable' kernel threads. This is not to be confused with the current kernel threads implementation that are used in Linux, and emulated by FreeBSD quite well. These actually scale, and will allow FreeBSD to scale much better than Linux does. (See recent benchmarks why the current threading model doesn't work well, or any threading paper). > > Its everything you'd want and is > > perfectly suited for implementing native threads for the JDK. But > > alas, it can't be taken advantage of as there is no native port of > > the JDK. > > Well, I would expect the Linux emulator to be suitably modified to do the > mapping appropriately, because, again, Java is not the only product facing > this issue. ??? You don't understand. It can't do JNI simply because the JVM is responsible for doing the mapping. The emulator folks can't be expected to go off and figure out exactly what the emulator is doing w/regards. If you're the CTO and expect this, then maybe it's time to go find a replacement. :) > Right now I can install Red Hat and run Oracle (with support, no > less), on an 8-way Xeon box with reasonable scalability. You and I have a much definition for 'reasonable scalability'. If you had a Java program with 8 threads in it written with very little contention, you would *never* see 8X performance. You might get 2X, or possibly 2.5X on a good day with a tail-wind. However, on Solaris, you'd get 4-6X, maybe 7X is your application really was written well. That's 'reasonable' scalability. > >(c) The "limited resources" in question here is volunteer time. The > > volunteers may feel that (i) they don't have the skills to work on > > the Linux emulator, and (ii) its their time and they'd actually > > like to spend it on a native JDK port :). > > This, of course, is indisputable. After all, you can still find > volunteers writing code for the Amiga. But that raises another issue: > if a tree writes software in the woods and no one uses it, does it make a > sound? > FreeBSD is dangerously close to falling into the Amiga death spiral. Ahh, now we're down the brass tacks. Everyone take note. Imminent death of FreeBSD soon to be expected. Quick, run away, run away. :) :) > If it weren't for the excellent Linux emulation, it would already be > there. The two biggest issues currently sucking FreeBSD down are SMP > and Java. SMP is certainly big, but we're not competing against Linux, but against NT and Win2K there. Currently both kick our butts in 'real' usage on SMP hardware, the evangelists not-withstanding. However, methinks you're a wee bit over the top with Java. Java is not *nearly* as big as it was a couple years back. Sun screwed the pooch with it's licensing issue, and Java 1.3 is still not supported well on most platforms. Heck, for that matter, only *two* platforms have a usable/stable JDK1.3 platform (and Linux isn't one of them, although it has a 'beta' quality release). Java is but one *minor* piece of the puzzle, which you tend to focus on since it's your job. (And, in case you're wondering, I lead the team in the JDK1.1 port from 1.1.4 and have been making my living as a Java programmer for nearly 5 years now, since the JDK1.0 days). > In my opinion, FreeBSD is far closer to solving the Java issue through > emulation than it is through writing a native port. You don't have all the facts available to you. > so I can't. I can only wait for BSDi to figure out the 1980's are over, > or try to influence the volunteers, or give up and jump ship. You're doing a darn good job of 'influencing' the volunteers, but I doubt it's having the desired effect. Note that other 'vendors' are doing a much better job of influence, by providing resources and encouragement, not bitching and moaning. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008031443.IAA29638>