Sounds like a rather nice way of introducing stability and or compatibility problems to java by not allowing Sun's Hot Spot just in time compiler to work correctly.
That's wrong. HotSpot just has to mark the memory containing the generated code executable. Recent Blackdown (non executable mappings aren't Windows specific) releases already do that and future Sun releases will do the same.
That's not surprising in either case, in terms of Java's results. It's well known that Sun has spent more time optimizing the Windows version of Java than any other, including the Solaris version.
That may be true in some areas (e.g. graphics) but it doesn't matter for these simple benchmarks. The code generators are the same on all platforms, ie. the Linux/x86 version will generate the same code as the Win/x86 version for these tests.
Anyhow, these benchmarks are too simple to be meaningfull. (Also note: microbenchmarks are not really favorable to runtime mixed-mode compilers; Java has a different FP model than x86; he only tested the HotSpot Client VM not the more optimizing Server VM.)
Also note that 64-bit is not faster than 32-bit in and of itself
It is on AMD64!
I've ported the HotSpot VM to AMD64 for Blackdown. It's noticable faster the 32-bit version in allmost all benchmarks. The main reason for the performance gain is that you have more registers in 64-bit mode.
I'm sure I'm too late with this reply for anyone to see...but Sun is releasing a 64-bit Java JVM for the new AMD chips next summer that'll run under Windows, and perhaps Linux.
No, they're Windows viruses. As said, I use it to get rid of annoying messages. The mails are no real threat for my machines but I don't want to have my mailbox cluttered up with hundreds of these messages each day.
This can be a *big* problem for *nix/mac users which normally don't need or use AV software.
I actually use ClamAV (with exim4/exiscan) on a pure Linux network in order to get rid of annoying mails. Currently ClamAV is responisble for 40-50% of all rejected/discarded mails per day, here are the statistics for the last seven days:
139 out of 338 discarded mails
188 out of 423
169 out of 397
113 out of 267
143 out of 238
179 out of 347
228 out of 424
The remaining rejected/discared mails are mainly due to unrouteable addresses and high spam scores (exiscan+spamassassin).
I think that must depend on whose VM you are using. I found that to be true of the Blackdown, but Sun's VM does antialias truetype fonts with no trouble at all. This isn't a great example, but look at the captions of this.
Can you give an example? The TT support in Sun's version and our version is virtually the same.
I haven't tried it myself yet, but I found no reference to this ptrace vulnerability [google.com] in the changelog. I suspect this is still a problem (it was in 2.4.19).
It was fixed in 2.4.20-rc2, see the "[PATCH] Fix lcall DoS" entry in the ChangeLog or this bk comment (and the corresponding patch).
Really? Wow... this is kind of scary. My OS class (Intro level) required implementing priority threading and priority donation on the very first assignment. I don't mean to be trolling, but doesn't the absence of this make the Linux kernel kind of... archaic? Or am I completely mis-interpretting your comment?
Of course Linux supports priorities. We're talking about LinuxThreads, a (not fully compliant) POSIX thread implementation.
In the current LinuxThreads implementation setting priorities for threads doesn't make much sense for the default scheduling policy. So changing a thread's priority isn't supported for this policy.
LinuxThreads also supports two realtime scheduling policies (round robin and FIFO). With these policies priorties have a clearly defined meaning and are supported.
In the current version priorities only work SCHED_RR and SCHED_FIFO (both require superuser privileges), SCHED_OTHER (the default policy) doesn't support changing priorities.
Regarding thread specific data access: If your LinuxThreads library uses floating stacks (for ix86 this means it has been built with --enable-kernel=2.4 and for i686) it already will be faster.
Well, generally, when I see something like sleep(3), it means that a thread is waiting for an event to finish. It's polling in a loop by sleeping for 3 milliseconds...
3 seconds not 3 milliseconds!
(see sleep in SUSv3/1003.1-2001)
Furthermore, the Java threading model is not defined by the Java Virtual Machine Specification - take a look. JVM implementors are free to implement threading on various platforms as they see fit.
(The spec will get a little stricter in the future, particularly in respect to memory visibility)
The main reasons for the loose specification are portability and performance. Operating systems tend to have different threading implementations and it's unlikely that this will change in the near future. Trying to implement the same behavior soley in user-space is tricky and only provides limited functionality, so it's not really a solution.
The.NET stuff will have the same problem. BTW, do they have a threading spec yet?
In Java, if you try this, it will always return the same IP Addresses, even if you dial-up/hang-up and renew, and enable/disable interfaces, which makes it useless. You have to restart the JVM to get the new addresses.
Actually you can change the caching policy in Java. In pre-1.4 release based on Sun code, you can set the undocumented property sun.net.inetaddr.ttl.
In 1.4 the policy can be changed by setting two (documented) properties: networkaddress.cache.ttl
and networkaddress.cache.negative.ttl (see
http://java.sun.com/j2se/1.4/docs/guide/net/proper ties.html).
Why do I use galeon?...
2. Because 1.0 has a button to clear the location box!!! Now I can actually use my 3rd button to paste stuff! This alone is enough to make it my primary browser!....
Note that you can do that without using the location bar at all: Just "paste" somewhere
(not on an URL) in the displayed page.
(This works with Netscape 4 and Mozilla-based browsers.)
Slashdot Mirror
Anyhow, these benchmarks are too simple to be meaningfull. (Also note: microbenchmarks are not really favorable to runtime mixed-mode compilers; Java has a different FP model than x86; he only tested the HotSpot Client VM not the more optimizing Server VM.)
Good point :-)
I've ported the HotSpot VM to AMD64 for Blackdown. It's noticable faster the 32-bit version in allmost all benchmarks. The main reason for the performance gain is that you have more registers in 64-bit mode.
Blackdown has released J2SE 1.4.2 for AMD64 a few weeks ago, see http://www.blackdown.org/java-linux/java2-status/j dk1.4-status.html.
Blackdown released a 64-bit VM for Linux/AMD64 just a few days ago.
No, they're Windows viruses. As said, I use it to get rid of annoying messages. The mails are no real threat for my machines but I don't want to have my mailbox cluttered up with hundreds of these messages each day.
- 139 out of 338 discarded mails
- 188 out of 423
- 169 out of 397
- 113 out of 267
- 143 out of 238
- 179 out of 347
- 228 out of 424
The remaining rejected/discared mails are mainly due to unrouteable addresses and high spam scores (exiscan+spamassassin).Actually a difference would have been somewhat strange. No current Linux JVM currently does antialiasing by default, you have to enable it explicitly.
(Pre-1.4.1/1.4.2 version had somewhat ugly TT rendering. Maybe you were comparing some older Blackdown version with a new Sun version.)
In the current LinuxThreads implementation setting priorities for threads doesn't make much sense for the default scheduling policy. So changing a thread's priority isn't supported for this policy.
LinuxThreads also supports two realtime scheduling policies (round robin and FIFO). With these policies priorties have a clearly defined meaning and are supported.
Regarding thread specific data access: If your LinuxThreads library uses floating stacks (for ix86 this means it has been built with --enable-kernel=2.4 and for i686) it already will be faster.
For other TLS enhancements take a look at http://people.redhat.com/drepper/tls.pdf.
The main reasons for the loose specification are portability and performance. Operating systems tend to have different threading implementations and it's unlikely that this will change in the near future. Trying to implement the same behavior soley in user-space is tricky and only provides limited functionality, so it's not really a solution.
The .NET stuff will have the same problem. BTW, do they have a threading spec yet?
The Heise Online article is available in english too: http://www.heise.de/english/newsticker/data/ray-08 .01.02-003/
We (ie. Blackdown) have J2RE 1.3.1 for iPAQs running Linux. It can be stripped down to about 6-7 M which isn't that big.
Bah, I'm quite happy with the current version of the Insidious Big Brother Database ;-)
Nevertheless I wouldn't call it cheap...