I would be interested in a test build also if it's available. I have
2 dual opteron Appro boxen running a 32-bit JDK.
Thanks,
Barry Roberts
On Fri, Sep 05, 2003 at 11:40:52AM +0200, SANS Francois wrote:
> Hello,
>
> i ' am very interested by jdk version 1.4.2 for AMD x86_64
>
> is this release
On Wed, Sep 04, 2002 at 09:28:37AM -0700, Dan Kegel wrote:
> I have no idea what Ulrich is planning for his linuxthread replacement,
> but once it's out in the open, we can probably finally fix issues
> like signal delivery.
Is there some public docs on this project ? I'm out of the loop as far
a
On Wed, Sep 04, 2002 at 08:41:07AM -0700, Dan Kegel wrote:
> You're referring to Linuxthreads? It has a couple other problems,
> like pid being different for each thread, and thread startup and
> shutdown
> not being as fast as thread maniacs (you know, the people who create
> more than 1 thread/
On Wed, Sep 04, 2002 at 07:59:30AM -0700, Dan Kegel wrote:
> As I wrote in a previous message, Sun is abandoning M:N threading;
> see http://java.sun.com/docs/hotspot/threads/threads.html
> NGPT is probably a dead end. I suspect Gnu and Linux will continue
> on with kernel-based threads, but with
On Wed, Sep 04, 2002 at 10:30:46AM +0200, Ingo Rockel wrote:
> I just had a look at the mail-archive of their mailing-list. There is a
> statement clarifying, their stuff will NOT work with current JVMs.
>
> Look here:
> http://www-124.ibm.com/pipermail/pthreads-users/2002-August/000250.html
>
I just had a look at the mail-archive of their mailing-list. There is a
statement clarifying, their stuff will NOT work with current JVMs.
Look here:
http://www-124.ibm.com/pipermail/pthreads-users/2002-August/000250.html
It seems also Sun will not support NGPT anytime soon, as they focus on
Cool I'm curious too, as I have
an MP server...
regards
v
On Wed, Sep 04, 2002 at 09:30:33AM +0200, Marco Trevisan wrote:
>Thanks to all you guys! :)
>
>I will try it (most probabily next week) and report back to the mailing
>list.
>The main reasons are:
>1) I would like to deploy on multi-proc
Thanks to all you guys! :)
I will try it (most probabily next week) and report back to the mailing
list.
The main reasons are:
1) I would like to deploy on multi-processor Linux systems without
lacking in scalability;
2) If it works, not only Catalina will benefit from this, but the
overall se
On Tue, Sep 03, 2002 at 10:03:15PM +0200, Marco Trevisan wrote:
> I looked at the NGPT home page, surfed the net and found some
> interesting benchmarks :
> http://www.opengroup.org/rtforum/jan2002/slides/linux/abt.pdf .
>
> At http://www.ibm.com/developerworks/oss/pthreads/, they say: "This
>
On Tue, Sep 03, 2002 at 10:03:15PM +0200, Marco Trevisan wrote:
> I found out that the best performing JVM on a single-processor Linux
> machine is Blackdown-1.3.1 with green threads and the OpenJIT compiler.
> Other JVMs I tried are: IBM v1.3.0 - 1.3.1, Sun v1.3.1 - 1.4.x
If there is any gain i
Yup native threads doing blocking IO on linux is expensive. Things start
looking progressively ugly from 50 connections upwards.
If you move to NIO you will see a significant improvement in both
stability/predictability and performance.
What would make it easier for you to try the multiplexing
Hello all,
I also use Tomcat (v4.0.4), and I have run my webapp with a variety of
JVMs in order to find which is best in terms of performance.
It could be important to point that my Java code conforms to the 1.3 API
specification, no 1.4-exclusive class or method is used.
I found out that the
> "Mauricio" == Mauricio Nuñez <[EMAIL PROTECTED]> writes:
> Thanks for your answers!
> Well, i will need to wait for a back port from kernel 2.5 to 2.4 ...
> I'm trying to get a better performance with Tomcat (a servlet
> container).
> The servlet spec say '1 request: 1 thread', then with
Thanks for your answers!
Well, i will need to wait for a back port from kernel 2.5 to 2.4 ...
I'm trying to get a better performance with Tomcat (a servlet
container).
The servlet spec say '1 request: 1 thread', then with high concurrent
requests, my server is less responsive.
Thanks
El mar
Mauricio Nuñez <[EMAIL PROTECTED]> writes:
> Blackdown JVM 1.3 support green and native threads, but 1.4 only
> native. Threading is an important issue for the server side java
> applications.
>
> Green threads are very scalable ( see Volano report ),
Yes, but only on one CPU.
> while the nat
On Tue, Feb 12, 2002 at 03:31:59PM -0600, Eric wrote:
> Ahh...this may be a solution. It looks like I could build it to not
> do mmap()s, but do malloc()s instead by using -DUSE_MALLOC (and maybe
> even link it against hoard to have a really nice malloc)
>
> However, it appears to be a total pai
Paul Mclachlan <[EMAIL PROTECTED]> writes:
> At :47 02 Feb 2002 -0600, Eric wrote:
>
>> Does anyone have any idea how to fix this? Would it be a big job
>> to fix it in the JVM?
>
> You could grab the source to 1.3.1 at:
>
> http://www.sun.com/software/communitysource/
>
> and edit
>
I have tried it with the 64GB PAE turned on...I don't belive it
changes these constants. It didn't help me.
eric.
On Tue, Feb 12, 2002 at 11:58:50AM -0800, Vladimir G Ivanovic wrote:
> Have you tried enabling CONFIG_HIGHMEM64G when building your kernel?
> With a 4GB VM space, the kernel occupie
Ahh...this may be a solution. It looks like I could build it to not
do mmap()s, but do malloc()s instead by using -DUSE_MALLOC (and maybe
even link it against hoard to have a really nice malloc)
However, it appears to be a total pain to get this thing to compile...
I have no idea where a JDK wit
Have you tried enabling CONFIG_HIGHMEM64G when building your kernel?
With a 4GB VM space, the kernel occupies 1 GB and processes 3GB as
defined by TASK_SIZE:
page.h:81:#define __PAGE_OFFSET (0xC000)
page.h:120:#define PAGE_OFFSET((unsigned long)__PAGE_OFFSET)
At :47 02 Feb 2002 -0600, Eric wrote:
> Does anyone have any idea how to fix this? Would it be a big job to
> fix it in the JVM?
You could grab the source to 1.3.1 at:
http://www.sun.com/software/communitysource/
and edit
jdk131src/j2sdk1.3.1/src/solaris/hpi/src/memory_md.c
On Fri, Aug 17, 2001 at 05:31:49AM -0700, BERNARDES,JOAN (Non-HP-Brazil,ex1) wrote:
> Hi all,
> Somebody knows what is the best JVM for Linux? I mean a JVM that is
> fast, small and support Swing.
All three of the 1.3.x JVMs (Blackdown, Sun, IBM) work and support
Swing. None of them i
>However, due to the nature of our app and infrastructure out app
>needs to be able to do things as different users.
Your one app needs to run with the permissions of several different
users? In a nutshell, Java isn't going to help you with this. In fact,
it'd be fairly awkward to do this in C in
On Thu, 10 May 2001, Joel Dudley wrote:
> Hello all,
> I have a security question for you all. We are going to have some java
> processes running on our server and, for security reasons, we would prefer
> that the JVM not run as root. However, due to the nature of our app and
> infrastructure o
On Thu, May 10, 2001 at 02:03:36PM -0700, Joel Dudley wrote:
> Hello all,
> I have a security question for you all. We are going to have some java
> processes running on our server and, for security reasons, we would prefer
> that the JVM not run as root. However, due to the nature of our app an
See this site, please.
Inside the Java 2 Virtual Machine
http://www.artima.com/jvm/index.html
- Original Message -
From: nilesh modi <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 15, 2001 3:07 PM
Subject: JVM
> Hi,
> can anyone tell me from where i can find out th
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
- Original Message -
From: "nilesh modi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 15, 2001 11:07 AM
Subject: JVM
> Hi,
> can anyone tell me from where i can find out the architecture of J
> My program run well in BLKDOWN Jdk1.2.2. So, I think it is not related to my
> program
> such as dead lock. Of course, I focused on the dead lock for several days.
That reminds me; I have had dead-lock problems with IBM's JDK 1.3 too, in an
IRC implementation I have written/am writing. For hist
Hi, Everybody:
The problem is actually related to the IBM JVM (At least I think so).
Previousely, I used JVM which was download about June. This JVM had fatel
Garbage collection, IBM already listed in the fixing of August.
Actually, I download Java(TM) 2 Runtime Environment, Standard Edition (bu
> > HotSpot is a Sun thing; there is no "HotSpot" in IBM's JVM.
>
> To be pandantic, HotSpot is a java Just-in-time compiler, aka JIT.
> IBM's JVM also has a JIT, it just has a different name, and it's
> on by default. IBM requires an -option at runtime to disable it.
Yes I know, HotSpot *is* a
Peter Schuller wrote:
>
> > It seems there is some memory leak in the HotSpot of IBM JVM.
>
> HotSpot is a Sun thing; there is no "HotSpot" in IBM's JVM.
To be pandantic, HotSpot is a java Just-in-time compiler, aka JIT.
IBM's JVM also has a JIT, it just has a different name, and it's
on by def
> It seems there is some memory leak in the HotSpot of IBM JVM.
HotSpot is a Sun thing; there is no "HotSpot" in IBM's JVM.
What are your threads doing? While IBM's JDK is pretty good, it seems to
have a bad GC; it throws OutOfMemoryErrors a bit too easy.
And exactly how does it "crash"?
> Who
yangyuexiang wrote:
>
> Hi
>
> My program employed several threads.
> On blackdown jdk1.2.2, the memory sized used is seems to fixed to about
> 23m each threads.
> But under IBM JDK1.3, although the speed is much faster, but the memory
> used likes to
> increase unexpectedly and the JVM hangs fi
Hi,
At Sat, 20 May 2000 20:03:11 +0700,
yangyuex <[EMAIL PROTECTED]> wrote:
> Who can tell me what's mean of
>
> "JVM INSTR pop; " in my attatched file.
The `pop' instruction remove away a word from top of Java stack, and
it often appears in the context that method returns a value but the
calle
yangyuex wrote:
>
> Hi,
>
> Who can tell me what's mean of
>
> "JVM INSTR pop; " in my attatched file.
I don't think this line is a legal Java statement. It looks like
'inline assembly' for the JVM. You will need a Java compiler that
understands this sort of things.
> When I compiler the at
Hi,
I tried explicit linking with pthread and there was no libc before that. Even
then it seems to hang. It sems to hang in the garbage collection sequence. We observe
that the gc seems to be waiting to suspend a socket connection. We are trying to
work around the problem. It would be
Christopher Smith wrote:
>
> On Fri, Mar 31, 2000 at 05:30:52PM -0500, John Rousseau wrote:
> > On Friday Mar 31, 2000, Christopher Smith wrote:
> > > On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> > > > On Friday Mar 31, 2000, Natarajan SK wrote:
> > > > Kevin Hendricks solved
On Fri, Mar 31, 2000 at 05:30:52PM -0500, John Rousseau wrote:
> On Friday Mar 31, 2000, Christopher Smith wrote:
> > On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> > > On Friday Mar 31, 2000, Natarajan SK wrote:
> > > Kevin Hendricks solved a very similar problem for me. This is
On Friday Mar 31, 2000, Christopher Smith wrote:
> On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> > On Friday Mar 31, 2000, Natarajan SK wrote:
> > Kevin Hendricks solved a very similar problem for me. This is
> > assuming that you are using native threads. Try linking in -lpth
On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> On Friday Mar 31, 2000, Natarajan SK wrote:
> Kevin Hendricks solved a very similar problem for me. This is
> assuming that you are using native threads. Try linking in -lpthread
> explicitly on your link line (and make sure you don'
On Friday Mar 31, 2000, Natarajan SK wrote:
> Hi, We are facing a JVM hang problem on Linux. We load the JVM
> from JNI and do an AttachThread to the main jEnv. Therefrom it
> goes executing into some classes and somewhere in the middle
> hangs. From the messages printed we find out that it see
> To: bryan vold <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> From: Juergen Kreileder <[EMAIL PROTECTED]>
> Date: 25 Jun 1999 01:58:33 +0200
>
> bryan> What is uncertain is whether or not Sun
> bryan> will incorporate some of the constructions that are a part
Derek Glidden wrote:
> I don't know for sure since, as I said, I haven't done a lot of
> multi-threaded programming. I've run a few third-party Java apps, but
> have no idea on the whole how thread-intensive any of them are.
>
> These two classes are a couple of stupid little things I wrote to se
Nathan Meyers wrote:
>
> OK... so one other question you haven't answered. Are you sure you've
> got two threads staying busy? Most of Java's threads spend most of their
> time sitting around and waiting. If you've really got two threads
> spinning and you're not seeing 100% load, something's str
> bryan vold writes:
bryan> At the Java-Linux BOF at JavaOne, Steve talked a little
bryan> about some of the delays. What I got as one of the main
bryan> problems was a very difficult problem of Linux native
bryan> threads and signal-handling in the JVM. Steve said that
Derek Glidden wrote:
>
> Nathan Meyers wrote:
> >
> > > I'm curious about this as well. I've been playing around with the JDK
> > > 1.2-pre2 on my spanking new Dual-PII machine recently to see how well it
> > > handles SMP and I've noticed that with either native or green threads,
> > > it only
Nathan Meyers wrote:
>
> > I'm curious about this as well. I've been playing around with the JDK
> > 1.2-pre2 on my spanking new Dual-PII machine recently to see how well it
> > handles SMP and I've noticed that with either native or green threads,
> > it only seems to use a single CPU for runni
bryan vold wrote:
> At the Java-Linux BOF at JavaOne, Steve talked a little about some of the
> delays. What I got as one of the main problems was a very difficult
> problem of Linux native threads and signal-handling in the JVM. Steve said
> that they are not only just porting, but also trying
Derek Glidden wrote:
>
> > Dan Iuster wrote:
> >
> > I would like to know if there is a different version of the JVM
> > compiled for multiprocessor Linux systems than for uniprocessor.
> >
> > Has anybody experienced any problems or performance issues with using
> > the uniprocessor version on m
On Thu, Jun 24, 1999 at 12:47:17PM -0700, Nathan Meyers wrote:
> > Dan Iuster wrote:
> >
> > I would like to know if there is a different version of the JVM
> > compiled for multiprocessor Linux systems than for uniprocessor.
> >
> > Has anybody experienced any problems or performance issues wit
> Dan Iuster wrote:
>
> I would like to know if there is a different version of the JVM
> compiled for multiprocessor Linux systems than for uniprocessor.
>
> Has anybody experienced any problems or performance issues with using
> the uniprocessor version on multiprocessor systems ?
I'm curious
> Dan Iuster wrote:
>
> I would like to know if there is a different version of the JVM
> compiled for multiprocessor Linux systems than for uniprocessor.
>
> Has anybody experienced any problems or performance issues with using
> the uniprocessor version on multiprocessor systems ?
>
> Any fee
At 06:50 AM 6/14/99 -0400, Jonathan Mark Brooks wrote:
>Thanks! Unfortunately, the Volano test suite probably won't meet my
>needs, since it is highly client/server oriented.
that might actually be a good thing... unless what you want to benchmark is
pure low level math or number crunching... in
>Thanks! Unfortunately, the Volano test suite probably won't meet my
>needs, since it is highly client/server oriented.
>
There's an older benchmark, CaffeineMark3, which I once grabbed from
Pendragon Software (www.pendragon-software.com). Don't know whether it's
still available, but it's client
Thanks! Unfortunately, the Volano test suite probably won't meet my
needs, since it is highly client/server oriented.
On Sun, 13 Jun 1999, Chris Abbey wrote:
> At 09:48 AM 6/13/99 -0400, Jonathan Mark Brooks wrote:
> >Can someone point me to a URL or resource that will allow me to
> >do a simple
At 09:48 AM 6/13/99 -0400, Jonathan Mark Brooks wrote:
>Can someone point me to a URL or resource that will allow me to
>do a simple and reasonably accurate speed comparison?
you do realize these are contradictory terms, do you not?
I think Volano might make some of their stuff public... yup
www
UNSUSCRIBE ME PLEASE!!
[EMAIL PROTECTED]
Miguel.°.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Get the a license agreement and then the sources at:
http://www.java.sun.com/products/jdk/1.1/source.html
Then download the relevant source patch from:
http://www.blackdown.org
(To my knowledge, the patch for Java2 isn't complete, yet. However,
looking at the Solaris build is a good place to se
in reality, select() was universal to all kerns' !. poll() was software
emmalated in the 2.0.xx series. poll() was the orig choice of system call,
but history took a different turn on the linux boxes, where the functi
onality of poll had to be recreated so that most of the linux world would
run on
Kevin B. Hendricks wrote:
> > On some OSes, poll() has
> >turned out to be a performance dog compared to select().
>
> .
> .
> .
>
> Given that select must look through all of the fds+1 that you are selecting
> over and poll does not, a true "poll" should work much much faster
>From the FAQ in glibc 2.0.109:
>2.25. I need lots of open files. What do I have to do?
>
>{AJ} This is at first a kernel issue. The kernel defines limits with
>OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
>number of used file descriptors. You need to change these v
Hi,
> On some OSes, poll() has
>turned out to be a performance dog compared to select(). If anyone
>listening has the configuration and time to try Kevin's suggested test:
>it would be worthwhile to hack together a little benchmark to ascertain
>whether poll() will give us another reason to comp
Kevin B. Hendricks wrote:
>
> A few words to clear this up.
>
> > The kernel does support it. The only problem is that the JVM is using
> > select(2) when it should use poll(2).
>
> No, this is not correct. The 1.1.7 JDK for glibc uses poll and not select (I
> know because I rewrote it t
A few words to clear this up.
> The kernel does support it. The only problem is that the JVM is using
> select(2) when it should use poll(2).
No, this is not correct. The 1.1.7 JDK for glibc uses poll and not select (I
know because I rewrote it to use poll). The problem is that glibc 2.0
On Mon, Jan 18, 1999 at 08:41:18AM +, David Warnock wrote:
>
> Alan Cox one of the key kernel developers mentions a patch to allow a
> lot more file handles in his on-line diary at
>
> http://www.linux.org.uk/diary/
>
> I suggest youn try looking there (I think it will have more detailed
>
Herbert,
Alan Cox one of the key kernel developers mentions a patch to allow a
lot more file handles in his on-line diary at
http://www.linux.org.uk/diary/
I suggest youn try looking there (I think it will have more detailed
references if you go further back.
I also think I may have seen somet
On Mon, Jan 18, 1999 at 11:56:30AM +0900, SHUDO Kazuyuki wrote:
> [EMAIL PROTECTED](Herbert Xu) wrote:
>
> > We have an Java application here that uses around 3000 file
> > descriptors at once.
>
> > Unfortunately, the
> > JVM (117) under Linux is trying to select over >1024 file descriptors
[EMAIL PROTECTED](Herbert Xu) wrote:
> We have an Java application here that uses around 3000 file
> descriptors at once.
> Unfortunately, the
> JVM (117) under Linux is trying to select over >1024 file descriptors, which
> is causing a core dump.
I think that it is a wrong behavior to ca
68 matches
Mail list logo
