>
> * Virtual methods are supported but you have to use the 'virtual' and
> 'override' keywords - a bit ugly. Otherwise methods are treated as
> non-virtual. My guess is that they are trying to avoid the problem
> that Java has with nearly everything being a virtual method, and the
Since Kaffe came up on this list, let me add a few comments about it:
>
> Kaffe is a clean room implementation to the spec but they have expanded the
> language in some interesting ways. I seem to recall they used the MS alternative
> to JNI but maybe they put in JNI as well.
Kaffe fully supp
>
> I think it is the drawback of the "Open Source" model. Technically,
> you can take any code and release it as yours after few changes.
>
Technically, this has nothing to do with the "Open Source" model.
Sun's JDK, the community license, or the blackdown port have little
in common with open
>
> >>To add another reason why nobody should draw conclusions quite yet:
> >>Kaffe's benchmarks were obtained with a version of its class libraries
> >>that was compiled with jikes, which is often considered to create
> >>the slowest bytecode among the different javac compilers.
> >
> >Is it? C
>
> I said this on comp.compilers and think it may interest some in this
> news group. According to the site, the performance of this VM is
> comparable to Sun's hotspot. It's released under a BSDish license.
> Anyone with more Java VM programming experience cares to take a look at
> it and see h
Thanks for your all your answers. I think we got an insightful
discussion going. I also think we got almost everything cleared up.
Let's hope that some mainstream magazine publishes numbers that show
just how Linux is being outperformed at the pthreads level and that
that changes the attitud
>
> My earlier question stands: why does boehm-gc use spinlocks and not
> pthread mutexes, or condition variables? Was it a deliberate decision, or
> ignorance on the part of the Linux porters? That choice suprised me a
> little, since garbage collection can run for long durations and cause
> e
>
> You mentioned in a previous email the ibmjdk, is that Jikes? If not what is
> Jikes as I thought that was the IBM JVM. Do you happen to know what Java
> version Jikes is comparable to?
>
No, IBM's JVM is IBM's port of Sun's JVM. It's a JVM.
jikes is a java source to java bytecode compiler
> >
> > So, I believe that kernel support is indeed needed.
>
> Don't do in the kernel what can adequately be performed in user space.
> Let me add my own data here... I modified Matt's program to get better
> timings, and compared mutexes to a spinlock implementation for ix86:
>
[...]
> For s
> >
> >Clearly, in the uniprocessor case, linux-threads is handicapped by
> >having to ask the kernel to switch between threads, because of the
> >1-to-1 implementation model. I fully agree with that.
> >
> >However, I think the case we're looking at here may be slightly different.
> >In our case
Thanks for your answer, Xavier.
Let me reply to some points below and ask some more questions.
I hope this discussion remains interesting and relevant to the
other subscribers on this list.
>
> > > I have a simple Java program where 2 threads spin in a tight loop each
> > > grabbing the same
>
> One thing I'm wondering about is Linux's support for SYSV-style IPC
> (semop etc.). Those appear to be kernel-supported semaphores. Maybe
> the problem is not in the lack of kernel support, but could be fixed
> by using SysV semaphores instead? It would definitely be worth a try.
>
> On t
>
> >I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe
> >measures up against other JVMs.
>
> Wow, nice numbers. I'm excited to see that ibmjdk on Linux is now in
> the same ballpark (or faster!) as msjvm and the Sun VM on Windows.
> Finally, I can hold my head up with pride :-)
Hi,
Matt Welsh wrote:
>
>
> Hi folks,
>
> I have a simple Java program where 2 threads spin in a tight loop each
> grabbing the same lock and releasing it. This is on Linux x86 and has been
> tested using GCJ 2.95.1, Blackdown JDK 1.1.7v3 (native threads), and
> IBM JDK 1.1.8 (native threa
>
> Personally, I'd be interested to see info about non-Blackdown free
> JVMs. We don't hear too much about them on this list. That would
> have been an interesting comparison.
>
I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe
measures up against other JVMs.
Here's the estim
>
> Godmar Back wrote,
> > Miles Sabin wrote,
> > > [snip: className.class vs Class.forName("className")]
> >
> > In other words, you're saving a try/catch clause at the
> > expense of one hidden static variable.
>
> Hmm ... well
>
> > If you know the class' name, and I suspect that you do
> > since you are in a static method of the class, you can
> > do a Class.forName(className).
>
> Better still, className.class, and have it resolved at
> compile time rather than by a runtime lookup.
>
Miles, "className.class" is
Nelson, Maksim,
>
> Nelson Minar wrote:
> >
> > What do people here think about Redhat having Kaffe installed by
> > default as the binary "java"? I think it's a bad idea because Kaffe
> > really doesn't support enough Java to be useful, at least to me. On
> > the other hand, I want to suppor
>
> In regards to setting minimum and maximum stack sizes, a "good value" is
> really dependent on your application. If you're doing alot of file IO or
> very intense computations, you might want to set those numbers fairly
> high. The only way to really determine how much memory to explicitly
>
I just like to address your reference to Kaffe being a personal java
environment.
After lurking a while on this list, I'm starting to realize that Kaffe's
labeling as "PersonalJava" is an unfortunate one.
PersonalJava (http://www.javasoft.com/products/personaljava/)
http://www.javasoft.com/pr
Chris,
>
> Do you have a makefile for this?
>
I made one and put everything here in case others are interested as well:
http://www.cs.utah.edu/~gback/linux-jdk-cyclecounter>
I even tested it and it runs.
- Godmar
--
On Linux, you'll probably also need a
static {
System.loadLibrary("nameofsofilethathascyclecounterdoto");
}
in CycleCounter.java.
- Godmar
>
> >
> > I've had similar problems measuring bandwidth. The greatest difficulty was the
> > limited resoution of the available
>
> I've had similar problems measuring bandwidth. The greatest difficulty was the
> limited resoution of the available timers. It's a darn shame that a high
> resolution counter isn't available given all these fancy hardware. Milliseconds!
> Pah! You can do an awful lot in a millisecond. Ever si
I think Phill Edwards <[EMAIL PROTECTED]> plans to rewrite
Linux's pthread package. You are right that the current state of linux-
threads is unacceptable for a Java run-time, as is evident in the
state of the 1.1.7native port.
Implementing a hybrid architecture that would map multiple user-lev
>
> I know that Kaffe is primarily a PersonalJava implementation, which is
> why it breaks several progs. Is it being extended now?
>
Contrary to what was stated earlier on this list, Kaffe currently
supports most 1.1 applications. It also runs on RH 6.0, btw, because
you can simply recompil
Hi,
I'm using the glibc version of jdk1.1.7v1a on a RH 5.2
system with glibc 2.0.7.
When trying to run some programs, I'm getting this message:
java.lang.Error: dtz null
at java.util.TimeZone.getDefault(TimeZone.java:94)
at
at
at ObjectSerialization.main(ObjectS
26 matches
Mail list logo
