Re: compiler optimization
At 23:37 6/7/00 -0400, Joseph Shraibman <[EMAIL PROTECTED]> wrote: >Sez who? Maybe your jre happens to run that way, but IIRC the behavior >is undefined. If I wasn't so lazy I would look it up. sez the JLS, section 4.5.5. Yes I have it infront of me. No it's not there because of this thread. And yes, you should have looked it up before posting that drivvel to the full list. any other questions? To David's original question... both Sun's javac (1.3 ea) and Jikes (1.11) put in two initializer bytecodes to load in whatever value you're interested in, either into the block or every block depending on if it's a static field or not. I suppose you could put in an optimization that would check every type of reference feild initializer and if it happened to be the default for the type then ommit the bytecode. Both compilers I checked did the same for Object = null; vs Object; ... I'm sure such a patch would at least be considered on jikes-dev... although we'd like to focus on a defect take down before integrating new code cabbey at home dot net <*> http://members.home.net/cabbey If at first you don't succeed, just redefine 'succeed'. Life is a sexually transmitted, 100% lethal disease. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE 1.1.8 Native Threads support missing for linux/Intel
On Wed, 7 Jun 2000, Andrew Majercik wrote: > And there-in lies the rub, because I am trying to find a viable JRE for > shipping a product. :) Sorry, I need to read $subject more carefully. > Does anyone know who to contact? The blackdown people are on this list, they probably already know. But the proper place is probably the "bug reporting" on http://www.blackdown.org/java-linux.html It should be just a re-packaging thing. The jre and jdk are supposed to be identical except for the compiler stuff, no? /Urban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jini
You must set up your network interface (e.g. eth0) for multicast and add a route to that interface (replace INTERFACE with eth0 for example) : ifconfig INTERFACE multicast route add -net 224.0.0.0 netmask 240.0.0.0 dev INTERFACE On Wed, Jun 07, 2000 at 09:56:13PM -0400, David Blankley wrote: > Has anyone successful set-up jini on their linux box?? > > Whenever I try to start the jini registry I get a bunch of errors. > > RMI is working fine tho. > > Any suggestions/successful configurations/tips would be appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JavaOne - no green threads for Linux
Not much new news from JavaOne for Linux (or for anything, really). I did stop by Sun's booth for J2SE on Linux and talked a bit with Hong Zhang, their Hotspot guy for Linux. Newer Sun releases will be native threads only, not green threads. I asked why, and got two answers: Hotspot assumes native threads, so a green threads version would be hard. Thread management is the OS' job, not the application's. We talked a bit about the second point. I agree in principle, but Linux' native threads are just not up to the task. They're slow, heavy, and limited. Hong agreed they weren't great, but expressed optimism that things would improve. He said that he's been talking with the Linux thread implementors some, but hadn't been actively contributing fixes. Folks who care about multithread performance on Linux might want to start working on improving thread support in the kernel. In the past, my impression is that the major Linux kernel developers don't think the thread support has problems. I haven't kept up with it enough to really know - anyone else know more? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JavaOne - no green threads for Linux
Quoting Nelson Minar <[EMAIL PROTECTED]>: > Newer Sun releases will be native threads only, not green threads. I > asked why, and got two answers: > Hotspot assumes native threads, so a green threads version would be hard. > Thread management is the OS' job, not the application's. > > We talked a bit about the second point. I agree in principle, but > Linux' native threads are just not up to the task. They're slow, > heavy, and limited. Hong agreed they weren't great, but expressed > optimism that things would improve. He said that he's been talking > with the Linux thread implementors some, but hadn't been actively > contributing fixes. > > Folks who care about multithread performance on Linux might want to > start working on improving thread support in the kernel. In the past, > my impression is that the major Linux kernel developers don't think > the thread support has problems. I haven't kept up with it enough to > really know - anyone else know more? unfortunately I have to agree with him, it's the os's job. I think since ibm force kernel developer to use a better thread arhitecture (just read their paper about linux thread on alphawors) there will some changes and their kernel patch (not to spend so much time in the thread scheduler) is in the main kernel tree (at least in 2.3.x). btw. I was on the "what's coming on jfc/swing" session, and it's turned out they have (will have but we can see a demo now) skin arhitecture for swing which is based on themes, mostly on linux's gtk themes model (the refer it as linux's themes). it's nice thet there are people at sun who try to put new idea from linux (or any other oss) to java. and give a credit for two folks (two friz) who made the first skin implementation for swing one of them for gtk the other for kde (I don't know why they are said gtk insted of qt if refer to gtk?). it's another kind thing to say a thank you. another good stuff swing has a wheelmouse support too. -- Levente "The only thing worse than not knowing the truth is ruining the bliss of ignorance." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
