Re: java intl. input method on linux
On Mon, Feb 11, 2002 at 01:47:00PM -0800, Calvin Austin wrote: > The Sun 1.3.1 release was tested with Japanese Redhat 6.2J, are you using > a similar Japanese distribution? I know we have tests with kinput2 and eucJP well, the latest debian, with all the proper encodings and locales installed, and kinput2, but that still does not work. -- # Stef Epardaud, # Teachers have potentially more power than military, # Java Defeater # the former can teach us how to not need the latter. # Earth # Lunatech Research, # Solar System # soon we'll quit researching and start finding... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Why do threads take so long to wake up underlinux
Martin,
Change the following line of the code to sleep for 20 sec instead of the
counter(variable i). You will find the penalty to be 10 msec.
BTW, does the fix proposed to change the kernel with HZ=1000 worked??
Reg
Ved
-Original Message-
From: Martin, Stephen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 12:55 PM
To: '[EMAIL PROTECTED]'
Subject: Why do threads take so long to wake up underlinux
I've been doing some benchmarks on my machine (a dual 733 running redhat
7.2)
and there seems to be a 20 millisecond penalty for doing a sleep or a wait.
Here
is code that illustrates it:
try {
for (int i = 0; i < 30; i++) {
long start = System.currentTimeMillis();
Thread.currentThread().sleep(i);
long end = System.currentTimeMillis();
System.out.println("total time = " + (end - start) + " for
sleep(" + i + ")");
}
} catch (Exception ex) {}
The output i get is
total time = 2 for sleep(0)
total time = 21 for sleep(1)
total time = 20 for sleep(2)
total time = 16 for sleep(3)
total time = 23 for sleep(4)
total time = 19 for sleep(5)
total time = 20 for sleep(6)
total time = 19 for sleep(7)
total time = 20 for sleep(8)
total time = 20 for sleep(9)
total time = 20 for sleep(10)
total time = 29 for sleep(11)
total time = 29 for sleep(12)
total time = 29 for sleep(13)
total time = 29 for sleep(14)
total time = 29 for sleep(15)
total time = 29 for sleep(16)
total time = 26 for sleep(17)
total time = 33 for sleep(18)
total time = 29 for sleep(19)
total time = 29 for sleep(20)
total time = 39 for sleep(21)
total time = 39 for sleep(22)
total time = 39 for sleep(23)
total time = 39 for sleep(24)
total time = 40 for sleep(25)
total time = 39 for sleep(26)
total time = 39 for sleep(27)
total time = 39 for sleep(28)
total time = 39 for sleep(29)
This is pretty much consistent on all jvms that i've tried blackdown, sun
(1.3.x and 1.4) and IBM
and would seem to therefore be an OS issue. Can anyone provide me with more
info on this and is
there a workaround?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JVM Size Limitations on Linux x86
I am depserately trying to get a single JVM to grow beyond the 2GB size limit that I've hit. I've tried both the IBM and Sun JVM's but without any luck. They both use mmap() to allocate memory, so there isn't a way to drop in a better memory allocation ssytem such as the "hoard" malloc(). My Linux configuration is: Debian woody with a 2.4.17 kernel on a Compaq Proliant 6500 with 4 Xeon 500's and 4GB of RAM along with about 800MB of swap. I have tried the latest IBM 1.3.1, blackdown 1.3.1, and Sun 1.4 releases. The problems with the Sun and blackdown JVM is as http://developer.java.sun.com/developer/bugParade/bugs/4401509.html puts it...the call to mmap is just plain over the linux x86 limit. However, the IBM one is more mysterious...it seems to be just not mmaping the right spot; the last mmap just hangs (and it's not trying to mmap more than the limit)...it just doesn't mmap a whole gigabyte of process address space from the end of its binary at 0x0804d000 to 0x400. Does anyone have any idea how to fix this? Would it be a big job to fix it in the JVM? Thanks, eric. -- _ _ | |(_) http://ir.iit.edu/~ej | _| | | Research Assistant | |___ | | Information Retrieval Laboratory |__/ | Illinois Institute of Technology |__/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Why do threads take so long to wake up underlinux
It's interesting. Did anybody try rebuilding the kernel with HZ=1000?
I'm also curious about it.
--
Fengguang
> Martin,
>
> Change the following line of the code to sleep for 20 sec instead of the
> counter(variable i). You will find the penalty to be 10 msec.
>
> BTW, does the fix proposed to change the kernel with HZ=1000 worked??
>
> Reg
> Ved
>
> -Original Message-
> From: Martin, Stephen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 06, 2002 12:55 PM
> To: '[EMAIL PROTECTED]'
> Subject: Why do threads take so long to wake up underlinux
>
>
> I've been doing some benchmarks on my machine (a dual 733 running redhat
> 7.2)
> and there seems to be a 20 millisecond penalty for doing a sleep or a wait.
> Here
> is code that illustrates it:
>
> try {
> for (int i = 0; i < 30; i++) {
> long start = System.currentTimeMillis();
> Thread.currentThread().sleep(i);
> long end = System.currentTimeMillis();
> System.out.println("total time = " + (end - start) + " for
> sleep(" + i + ")");
> }
> } catch (Exception ex) {}
>
> The output i get is
>
> total time = 2 for sleep(0)
> total time = 21 for sleep(1)
> total time = 20 for sleep(2)
> total time = 16 for sleep(3)
> total time = 23 for sleep(4)
> total time = 19 for sleep(5)
> total time = 20 for sleep(6)
> total time = 19 for sleep(7)
> total time = 20 for sleep(8)
> total time = 20 for sleep(9)
> total time = 20 for sleep(10)
> total time = 29 for sleep(11)
> total time = 29 for sleep(12)
> total time = 29 for sleep(13)
> total time = 29 for sleep(14)
> total time = 29 for sleep(15)
> total time = 29 for sleep(16)
> total time = 26 for sleep(17)
> total time = 33 for sleep(18)
> total time = 29 for sleep(19)
> total time = 29 for sleep(20)
> total time = 39 for sleep(21)
> total time = 39 for sleep(22)
> total time = 39 for sleep(23)
> total time = 39 for sleep(24)
> total time = 40 for sleep(25)
> total time = 39 for sleep(26)
> total time = 39 for sleep(27)
> total time = 39 for sleep(28)
> total time = 39 for sleep(29)
>
> This is pretty much consistent on all jvms that i've tried blackdown, sun
> (1.3.x and 1.4) and IBM
> and would seem to therefore be an OS issue. Can anyone provide me with more
> info on this and is
> there a workaround?
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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 to use your own allocation strategy. All of the platform specific stuff the VM does goes through HPI, I'm pretty sure this would work & it doesn't seem like too much work... - Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do threads take so long to wake up underlinux
On Tue, Feb 12, 2002 at 10:07:59AM -0800, Fengguang Song wrote:
>
> It's interesting. Did anybody try rebuilding the kernel with HZ=1000?
> I'm also curious about it.
Well I've done this long time ago - it helps for the 'sleep' case
however linux latency might be quite huge thus it could be stuck
in the kernel for more then 20ms in case the machine is busy.
Lately (2.5.4) there has been accepted low latency patch (finaly)
however if someone need real hard real time scheduling - I would
suggest to use RTLinux.
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- When in doubt, just blame the Euro. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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) processor.h:268:#define TASK_SIZE (PAGE_OFFSET) I assume that these are changed when you compile with CONFIG_HIGHMEM64GB. --- Vladimir Vladimir G. Ivanovichttp://leonora.org/~vladimir 2770 Cowper St. [EMAIL PROTECTED] Palo Alto, CA 94306-2447 +1 650 678 8014 "e" == ej writes: e> I am depserately trying to get a single JVM to grow beyond the 2GB e> size limit that I've hit. I've tried both the IBM and Sun JVM's but e> without any luck. They both use mmap() to allocate memory, so there e> isn't a way to drop in a better memory allocation ssytem such as the e> "hoard" malloc(). e> My Linux configuration is: Debian woody with a 2.4.17 kernel on a e> Compaq Proliant 6500 with 4 Xeon 500's and 4GB of RAM along with about e> 800MB of swap. e> I have tried the latest IBM 1.3.1, blackdown 1.3.1, and Sun 1.4 e> releases. The problems with the Sun and blackdown JVM is as e> http://developer.java.sun.com/developer/bugParade/bugs/4401509.html e> puts it...the call to mmap is just plain over the linux x86 limit. e> However, the IBM one is more mysterious...it seems to be just not e> mmaping the right spot; the last mmap just hangs (and it's not trying e> to mmap more than the limit)...it just doesn't mmap a whole gigabyte e> of process address space from the end of its binary at 0x0804d000 to e> 0x400. e> Does anyone have any idea how to fix this? Would it be a big job to e> fix it in the JVM? e> Thanks, e> eric. e> -- e> _ _ > (_) http://ir.iit.edu/~ej _> | | Research Assistant >> |___ | | Information Retrieval Laboratory >> __/ | Illinois Institute of Technology >> __/ e> -- e> To UNSUBSCRIBE, email to [EMAIL PROTECTED] e> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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 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) > processor.h:268:#define TASK_SIZE (PAGE_OFFSET) > > I assume that these are changed when you compile with > CONFIG_HIGHMEM64GB. > > --- Vladimir > > > Vladimir G. Ivanovichttp://leonora.org/~vladimir > 2770 Cowper St. [EMAIL PROTECTED] > Palo Alto, CA 94306-2447 +1 650 678 8014 > > "e" == ej writes: > > e> I am depserately trying to get a single JVM to grow beyond the 2GB > e> size limit that I've hit. I've tried both the IBM and Sun JVM's but > e> without any luck. They both use mmap() to allocate memory, so there > e> isn't a way to drop in a better memory allocation ssytem such as the > e> "hoard" malloc(). > > e> My Linux configuration is: Debian woody with a 2.4.17 kernel on a > e> Compaq Proliant 6500 with 4 Xeon 500's and 4GB of RAM along with about > e> 800MB of swap. > > e> I have tried the latest IBM 1.3.1, blackdown 1.3.1, and Sun 1.4 > e> releases. The problems with the Sun and blackdown JVM is as > e> http://developer.java.sun.com/developer/bugParade/bugs/4401509.html > e> puts it...the call to mmap is just plain over the linux x86 limit. > e> However, the IBM one is more mysterious...it seems to be just not > e> mmaping the right spot; the last mmap just hangs (and it's not trying > e> to mmap more than the limit)...it just doesn't mmap a whole gigabyte > e> of process address space from the end of its binary at 0x0804d000 to > e> 0x400. > > e> Does anyone have any idea how to fix this? Would it be a big job to > e> fix it in the JVM? > > e> Thanks, > e> eric. > > e> -- > e> _ _ > > (_) http://ir.iit.edu/~ej > _> | | Research Assistant > >> |___ | | Information Retrieval Laboratory > >> __/ | Illinois Institute of Technology > >> __/ > > > e> -- > e> To UNSUBSCRIBE, email to [EMAIL PROTECTED] > e> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- _ _ | |(_) http://ir.iit.edu/~ej | _| | | Research Assistant | |___ | | Information Retrieval Laboratory |__/ | Illinois Institute of Technology |__/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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 with libjvm_g.so comes from and OPEN_MAX wasn't defined in some file and my yacc didn't like line 125 of parser.y and signals_md.o has a bunch of unresolved symbols that should be in threads_md.o Seems like if I actually reverted to the version of GCC they recommend it might fix some of these problems, but I don't think all. Does anyone actually compile this thing? :) Someone want to help me with getting one that has -DUSE_MALLOC? eric. On Tue, Feb 12, 2002 at 02:24:40PM -0500, Paul Mclachlan wrote: > 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 > > to use your own allocation strategy. All of the platform specific stuff the VM > does goes through HPI, I'm pretty sure this would work & it doesn't seem like > too much work... > > - Paul -- _ _ | |(_) http://ir.iit.edu/~ej | _| | | Research Assistant | |___ | | Information Retrieval Laboratory |__/ | Illinois Institute of Technology |__/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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 > > jdk131src/j2sdk1.3.1/src/solaris/hpi/src/memory_md.c > > to use your own allocation strategy. All of the platform specific > stuff the VM does goes through HPI, I'm pretty sure this would work > & it doesn't seem like too much work... memory_md.c is for the the classic VM. Changing the HotSpot VM is more tricky. Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html Run Java 2 SE v1.3.1 on your iPAQ: http://www.handhelds.org/pipermail/ipaq/2001-June/007221.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
magic line in unix
I have been having problems making beanshell shell scripts on linux. Bascially #! /usr/local/jdk/bin/java bsh.Interpreter works, while #! /usr/local/jdk/bin/java -client bsh.Interpreter does not work. The problem seems to be that all arguments are lumped together when passed to the program, so java doesn't get two arguments '-client' and 'bsh.Interpreter', it gets one '-client bsh.Interpreter'. Who is responsible for magic line interpretation, the shell that calls the script or the kernel? Where is the spec for magic lines? -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://xis.xtenit.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: magic line in unix
I found some mailing list archives from 2000 mentioning #! but it was a mess and refered to things the readers of that list knew about but I don't. For example I couldn't figure out what XCUd3 ERN 6 is. Could you point me to something more specific? Dan Kegel wrote: > Joseph Shraibman wrote: > >>I have been having problems making beanshell shell scripts on linux. >> >>Bascially #! /usr/local/jdk/bin/java bsh.Interpreter works, while >>#! /usr/local/jdk/bin/java -client bsh.Interpreter does not work. The problem seems >to be >>that all arguments are lumped together when passed to the program, so java doesn't >get two >>arguments '-client' and 'bsh.Interpreter', it gets one '-client bsh.Interpreter'. >Who is >>responsible for magic line interpretation, the shell that calls the script or the >kernel? >> Where is the spec for magic lines? >> > > It's a sad story. Search for #! in bodies at > http://www.opengroup.org/sophocles/show_archive.tpl?listname=austin-group-l > > - Dan > -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://xis.xtenit.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: magic line in unix
OK figured out what xcu is, but where in there does it discuss #! ? For the rest of you: http://www.unix-systems.org/version3/xcu_contents.html Dan Kegel wrote: > Joseph Shraibman wrote: > >>I have been having problems making beanshell shell scripts on linux. >> >>Bascially #! /usr/local/jdk/bin/java bsh.Interpreter works, while >>#! /usr/local/jdk/bin/java -client bsh.Interpreter does not work. The problem seems >to be >>that all arguments are lumped together when passed to the program, so java doesn't >get two >>arguments '-client' and 'bsh.Interpreter', it gets one '-client bsh.Interpreter'. >Who is >>responsible for magic line interpretation, the shell that calls the script or the >kernel? >> Where is the spec for magic lines? >> > > It's a sad story. Search for #! in bodies at > http://www.opengroup.org/sophocles/show_archive.tpl?listname=austin-group-l > > - Dan > -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://xis.xtenit.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JVM Size Limitations on Linux x86
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 pain to get this thing to compile... > I have no idea where a JDK with libjvm_g.so comes from and OPEN_MAX > wasn't defined in some file and my yacc didn't like line 125 of > parser.y and signals_md.o has a bunch of unresolved symbols that > should be in threads_md.o > > Seems like if I actually reverted to the version of GCC they recommend > it might fix some of these problems, but I don't think all. Does > anyone actually compile this thing? :) Someone want to help me with > getting one that has -DUSE_MALLOC? While USE_MALLOC is still in the code methinks its not had any attention for quite some time. I eventually got it to compile at one point with this but it then promptly segfaulted (or at least thats my recollection). Just FYI :) -- Greg LewisEmail : [EMAIL PROTECTED] Eyes Beyond Phone : (801) 796 6999 Information TechnologyWeb : http://www.eyesbeyond.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
