i now managed to use green threads with jre1.2.2 v3 ( i didnt get it to work
with 1.3.1 FCS-02b)
but now i get this error while the program is running (which i didnt get
witht he native on the 1.3.1)
java.lang.NoSuchMethodError: java.net.Socket: method shutdownInput()V not
found
at
Waes Bruno <[EMAIL PROTECTED]> writes:
> how do i enable green threads ? and how do i check if a java app is
> running with green threads or not ?
>
>
> export PATH="$PATH:/opt/j2re1.3.1/bin"
> export JAVA_COMPILER=NONE
> export THREADS_FLAG=green
> e
fi
vmtype=`echo ${default} | cut -c 2-`
fi
if [ "${vmtype}" = "classic" ]; then
if [ "${ttype}" = "green_threads" ]; then
LD_BIND_NOW=yes
export LD_BIND_NOW
fi
_JVM_THREADS_TYPE=${ttype}
export _JVM_THREADS_TYPE
fi
> when i run the java command with option '-green' it gives this error:
>
> Green threads support not available
> Could not create the Java virtual machine.
HotSpot Server and Client VM need native threads. They cannot work
with green threads. So, you have to choose Cla
when i run the java command with option '-green' it gives this error:
Green threads support not available
Could not create the Java virtual machine.
so it seems that there is no support for green threads anymore in
'j2re-1.3.1-02b-FCS-linux-i386.bin'
although there is a /bi
well ... it is running native threads then ...
that .java_wrapper file should decide if i want native or green threads
doesnt it ?
then why doesnt it do it
bruno
-Original Message-
From: Wilhelm *Rafial* Fitzpatrick [mailto:[EMAIL PROTECTED]]
Sent: vrijdag 7 juni 2002 2:17
To: Waes
At 4:43 PM +0200 6/6/02, Waes Bruno wrote:
>how do i enable green threads ?
>and how do i check if a java app is running with green threads or not ?
>
>
>export PATH="$PATH:/opt/j2re1.3.1/bin"
>export JAVA_COMPILER=NONE
>export THREADS_FLAG=green
>export THRE
how do i enable green threads ?
and how do i check if a java app is running with green threads or not ?
export PATH="$PATH:/opt/j2re1.3.1/bin"
export JAVA_COMPILER=NONE
export THREADS_FLAG=green
export THREADS_TYPE=green_threads
is in my bashrc file
but i dont think it runs
Wilhelm,
> I'm using the 1.3.1_02 version of the blackdown JDK with mozilla RC2
> on PPC. I'm trying to work around the fact that various applets
> SIGSEGV the JVM, and I've discovered via testing in appletviewer that
> these same applets work fine when I run the J
I'm using the 1.3.1_02 version of the blackdown JDK with mozilla RC2
on PPC. I'm trying to work around the fact that various applets
SIGSEGV the JVM, and I've discovered via testing in appletviewer that
these same applets work fine when I run the JVM with green threads.
No
Hi List
I'm using the JDK 1.3.0 on a PPC machine.
I need the JRE to run Green Threads per default.
How do I change this?
Best regards,
Jacob Vennervald
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
Hi,
I've got the following problem starting my application in
the green threads mode:
/usr/local/jdk1.3.1/bin/i386/green_threads/java: error while loading shared
libraries: /usr/local/jdk1.3.1/jre/lib/i386/libpreemptive_close.so:
undefined symbol: pthread_kill
do you have a clue?
iginal Message-
From: Hong Zhou [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 2:31 AM
To: A6<10G
Subject: Re: [blackdown1.3.1] segmentation fault using green threads
To me, green thread has less problems on Linux. I
suspect that your computer does not support green
thre
It is first to post the message to this newsgroups.
I ported the blackdown jvm to my boards.
The system spec for my board is
CPU:StrongArm sa1110
Flash memory: 32 M
RAM:32M
When I use the native thread, My java application works well.
shell) java -native -jar Myjar.jar
But W
cision a while back that it wasn't going to be the jvm's
job any more to manage threads. Thus no more green threads.
--
Joseph Shraibman
[EMAIL PROTECTED]
Increase signal to noise ratio. http://www.targabot.com
-
On Sun, 19 Nov 2000, Volker wrote:
> Hi,
>
> does HotSpot only support "native threads" but not "green ones"?
Yes, that seems to be the case with all of the the existing HotSpot VMs.
Scott
--
=
Scott Murray
Hi,
does HotSpot only support "native threads" but not "green ones"?
Best regards
Volker
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Richard Johnson wrote:
> It would be good if the Java reference platform had
> a java.util.Scheduler that perhaps configured itself
> with a policy object (java.util.SchedulerPolicy interface)
> whose implementations could do such things as query the system for
> resources (processor count, memor
the current,
flawed Java I/O model.
Nathan
>
> (it is open source, afterall) but small access to the Java
> implementations. This whole thread started when I said that one of the
> Sun engineers claims that Hotspot can't really work with green
> threads. That means that Sun&#
situation, we have control over the Linux kernel
(it is open source, afterall) but small access to the Java
implementations. This whole thread started when I said that one of the
Sun engineers claims that Hotspot can't really work with green
threads. That means that Sun's going to rely on
On Mon, Jun 12, 2000 at 09:36:27AM -0700, Matt Welsh wrote:
>
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
> > I still haven't seen one good argument for using thousands of threads
> > except for working around Java's _current_ IO limitations and doing
> > better on benchmarks which test work-
k on one computer (or
one
VM!) - my machine is perfectly capable of doing this with green
threads, but using native threads (<=kernel-2.2) is a complete no-go
in this situation.
Same here... I am hacking an icm-based agent framework. In order to get
a real agent from an object, you definetely
> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
> Michael Thome <[EMAIL PROTECTED]> writes:
>>
>> Agreed - beginners *do* tend to use too many threads,
> This has nothing to do with "beginners"!
Sorry - I didn't mean to imply that I think that use of many threads
is a bad idea... (quit
Michael Thome <[EMAIL PROTECTED]> writes:
>
> Agreed - beginners *do* tend to use too many threads,
This has nothing to do with "beginners"!
Currently, you *cannot* write a Web server in Java without using one
thread per socket connection. You can limit the number of "active"
connections, a
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> I still haven't seen one good argument for using thousands of threads
> except for working around Java's _current_ IO limitations and doing
> better on benchmarks which test work-arounds for these IO limitations.
This is the same kind of argument t
Michael Thome <[EMAIL PROTECTED]> writes:
> Yes - one would expect a general purpose hybrid/two-tier threading
> library to be at least at complex as the green threads implementation:
> presumably somewhat hairier.
I would go even further. If you are going to spend a huge amou
> "Juergen" == Juergen Kreileder <[EMAIL PROTECTED]> writes:
> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
Matt> In either case we need to get Linux native threads to scale
Matt> much better than they do now. This might mean convincing the
Matt> kernel developers that scaling up to th
n, regression and QA purposes,
it is often useful to start up a whole network on one computer (or one
VM!) - my machine is perfectly capable of doing this with green
threads, but using native threads (<=kernel-2.2) is a complete no-go
in this situation.
Now, the kernel-2.3 situation is much
Juergen Kreileder wrote:
> I still haven't seen one good argument for using thousands of threads
> except for working around Java's _current_ IO limitations and doing
> better on benchmarks which test work-arounds for these IO limitations.
>
If one uses Java's natural tools (no JNI/2nd-tier-serv
; the underlying kernel thread (such as a disk or socket I/O) be actually
> made non-blocking and the appropriate call to the thread scheduler made
> at the point where the block would occur. This adds a great deal of
> complexity, as evidenced by the implementation of green threads
> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
Matt> In either case we need to get Linux native threads to scale
Matt> much better than they do now. This might mean convincing the
Matt> kernel developers that scaling up to thousands of threads is
Matt> important --
I stil
> "Nelson" == Nelson Minar <[EMAIL PROTECTED]> writes:
Nelson> BTW, one last JavaOne tidbit - I met the guy at Volano
Nelson> who's done all the VolanoMark benchmarks over the
Nelson> years. Friendly chap, I thanked him for all his
Nelson> benchmarking work. He told me they ju
[EMAIL PROTECTED] (Nelson Minar) writes:
> And green threads, in many ways, are just a thread
> abstraction on top of the select() magic that you'd have to write
> special purpose.
Still, green threads do not work very well (see the first paper on my website
for details) -- and th
27;s actually
better if you multiplex your own I/O via select() rather than using
fork(), but the reality is it's a big pain in the neck to write code
that way. And green threads, in many ways, are just a thread
abstraction on top of the select() magic that you'd have to write
special purpose.
Stefaan A Eeckels wrote:
>
>
> I'm not one of the kernel folk, but can you give me an example of
> an application that would be impossible without hundreds of threads?
> Or even one that would significantly benefit from hundreds of threads?
A RMI server on the net. One of our servers is handlin
Stefaan A Eeckels wrote:
> Seriously, "hundreds" of threads in _Java_, the acknowledged speed-demon
> of languages?
I don't think you'll find too much argument that huge threadcounts do not
necessarily add up to brilliant programming. An unfortunate, early design
decision against supporting asyn
"Rousseau, John" <[EMAIL PROTECTED]> writes:
>
> A performance critical application server that needs to handle
> hundreds of simultaneous requests and wants to keep a pool of
> threads around so as to not re-instantiate a client thread per
> incoming request.
This is the scenario we discuss in
Artur Biesiadowski <[EMAIL PROTECTED]> writes:
> Of course you can tell: Let's make java support nonblocking io. But it
> is not possible for now, JCP process is quite long,
We are working on it (I am on the expert group for the JCP specification
to add nonblocking I/O APIs to Java). It is slat
ht block
the underlying kernel thread (such as a disk or socket I/O) be actually
made non-blocking and the appropriate call to the thread scheduler made
at the point where the block would occur. This adds a great deal of
complexity, as evidenced by the implementation of green threads itself.
On 09-Jun-2000 Avi Cherry wrote:
> >I'm not one of the kernel folk, but can you give me an example of
> >an application that would be impossible without hundreds of threads?
> >Or even one that would significantly benefit from hundreds of threads?
>
> Easy. How about any sort of stateful serv
On Friday Jun 9, 2000, Stefaan A Eeckels wrote:
>
> On 09-Jun-2000 Michael Thome wrote:
> > I think the best answer is to do the second tier threading in userspace
> > (best would be in glibc). The kernel folks have some good points
> > about doing it the kernel but seem to have a mental bl
On 09-Jun-2000 Michael Thome wrote:
> I think the best answer is to do the second tier threading in userspace
> (best would be in glibc). The kernel folks have some good points
> about doing it the kernel but seem to have a mental block as to why
> you'd *ever* want hundreds of threads in a
>I think the best answer is to do the second tier threading in
>userspace (best would be in glibc).
Do any systems that do mixed user/kernel threads work well? I've heard
nightmares about Solaris' threading system, with the complication of
hybrid threads as the prime culprit.
>The kernel folks h
>>>>> "Nelson" == Nelson Minar <[EMAIL PROTECTED]> writes:
> 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.
>
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 th
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 as
On 2000-01-21 13:46:30 +0100, Oliver Fels wrote:
> On 21 Jan 00, at 13:09, Martin Schröder wrote:
> > build Linux_JDK_1.2_pre-release-v2 -- No.
> >
> > And if you ask why we use this: It's the only Java2 running with
> > 2.0x kernels.
>
> And the last one actually running on a non glib2.1.2 syst
On 21 Jan 00, at 13:09, Martin Schröder wrote:
> build Linux_JDK_1.2_pre-release-v2 -- No.
>
> And if you ask why we use this: It's the only Java2 running with
> 2.0x kernels.
And the last one actually running on a non glib2.1.2 system.
Oliver
_
On 2000-01-21 11:31:29 +, Peter Pilgrim wrote:
> [EMAIL PROTECTED] wrote:
> > 1.2pre2 doesn't run with -green and JIT; -green works only
>
> Is this Release Candidate 3 ?
build Linux_JDK_1.2_pre-release-v2 -- No.
And if you ask why we use this: It's the only Java2 running with
2.0x kernels.
f the JCK tests on both green and native threads, with and
without the JIT. The table shows this by "G"
(green threads), "N" (native threads), "J", (using JIT) and "!J" (no JIT). "
--
Adios
Peter
-
On 2000-01-20 14:25:32 +0100, Martin Schröder wrote:
> Hi,
> on a Suse 6.3 installation (kernel 2.2.13) with only one cpu the
> 1.2pre2 doesn't run with -green and JIT; -green works only
> without JIT. Native threads work with and without JIT. Any idea
> what's wrong?
Addendum: I tried the glib 2
Hi,
on a Suse 6.3 installation (kernel 2.2.13) with only one cpu the
1.2pre2 doesn't run with -green and JIT; -green works only
without JIT. Native threads work with and without JIT. Any idea
what's wrong?
Best regards
Martin
--
Martin Schröder, [EMAIL PROTECTED]
We don't have to argue about native vs. green threads since the
Blackdown JDK 1.2.2 release does both.
I understand why people need native threads, but I need green threads on
Linux for handling a large number of dedicated connections to a pure
Java server (see
http://developer.java.su
Though, by its nature, green thread does not support SMP. Any comment /
Steve
- Original Message -
From: "Weiqi Gao" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 08, 1999 9:26 AM
Subject: Re: Native vs. green threads
> Scott Murray wro
On Tue, 7 Dec 1999, Weiqi Gao wrote:
> Scott Murray wrote:
> >
> > On Tue, 7 Dec 1999, Matt Welsh wrote:
> > >
> > > [EMAIL PROTECTED] (Nelson Minar) writes:
> > > >
> > > > However, I disagree that native threads are required for seri
Scott Murray wrote:
>
> On Tue, 7 Dec 1999, Matt Welsh wrote:
> >
> > [EMAIL PROTECTED] (Nelson Minar) writes:
> > >
> > > However, I disagree that native threads are required for serious
> > > applications. Green threads work surprisingly well fo
On Tue, 7 Dec 1999, Matt Welsh wrote:
>
> [EMAIL PROTECTED] (Nelson Minar) writes:
> >
> > However, I disagree that native threads are required for serious
> > applications. Green threads work surprisingly well for many
> > applications. In some, they work bet
[EMAIL PROTECTED] (Nelson Minar) writes:
>
> However, I disagree that native threads are required for serious
> applications. Green threads work surprisingly well for many
> applications. In some, they work better. I recently wrote a spider
> program that was invoking anoth
ning under this
> JDK, including JBuilder, and the performance is good. Now, I understand that
> some applications need native threads but a many others can run ok with
> green threads today.
The problem here is with specially written native code, i.e. device drivers.
Most of these don'
I'm sorry to ask this again but nobody replied to me before.
Did anybody get remote (rmi) objects to work with jdk1.2v2 glibc 2.1 and
green threads ?
Thanks.
--
Ramiro Díaz Trepat
[EMAIL PROTECTED]
ôèPÔ
ÿzf¢Ú#jöÿ)îÇúު笷øÚ½¯Û§
ation
stackpointer=0x41d345f0
Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green
threads):
"RMI TCP Connection(3)-prometeo.turas.com/172.16.1.128"
(TID:0x405025f0, sys_thread_t:0x834e0f
8, state:R) prio=5
at COM.ibm.db2.jdbc.app.DB2Statement.SQLAllocStmt(Nativ
Hi,
when running the jdb with the -green option and no other arguments, at
all, the prompt doesn't appear and the program continuously allocates
memory until you kill it. I am using jdk 1.2 pre v2 on SuSE linux 6.1
(kernel 2.2.3).
jdb with native thread works basically fine but with more compl
<[EMAIL PROTECTED]> writes:
> Can somebody tell me - how do we tell it to java to make use of which
> thread system (native/green)??
java -green ...
java -native ..
--
Jan-Henrik Haukeland
--
To UNSUBSCRIBE, email to [EMAIL
Hi,
Can somebody tell me - how do we tell it to java to make use of which
thread system (native/green)??
Thanks,
..praks
Linux Saggi #@%
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble?
the behaviours might mean.
On the glibc 2.0 machine, green threads work great with both 1.1.7-v3
and 1.2-pre2. Native threads work ok, but performance is actually worse
than with green threads, although, in either case I'm finding that
1.2-pre2 is appx 5x faster than 1.1.7-v3. (Also, I followe
> swansma writes:
>> Hm, rmid uses jdk1.2/jre/bin/java (which is a link to
>> jdk1.2/jre/bin/.java_wrapper) by default.
swansma> Yes, but rmid doesn't use .java_wrapper to start NEW VMs.
It does, trust me ;-)
It uses jdk1.2/jre/bin/.java_wrapper (not jdk1.2/bin/.java_wrapper).
On 25 May 1999, Juergen Kreileder wrote:
> >>>>> Mark Swanson writes:
>
> Mark> Since the green threads - no jit - passed the JCK, is it
> Mark> possible to have this configuration the default? RMID spawns
> Mark> new threads (reggie,
>>>>> Mark Swanson writes:
Mark> Since the green threads - no jit - passed the JCK, is it
Mark> possible to have this configuration the default? RMID spawns
Mark> new threads (reggie, txn_mgr, etc..) as native threads which
Mark> crash a lot. I'
Hello,
Since the green threads - no jit - passed the JCK, is it possible to
have this configuration the default? RMID spawns new threads (reggie,
txn_mgr, etc..) as native threads which crash a lot. I've modified the
.java_wrapper to force green threads, but rmid doesn't use the
.java-
Just to inform that Enhydra 2.0.2 runs OK on my linux machine, Redhat 5.2,
jdk1.1.7 v1a and tya 1.2v4. I don't know which version of lib that I have though
as I haven't upgraded to anything else. I just installed the stuff on top of my
5.2 installation.
hamdi
Stephan Greene wrote:
> I'm trying
On Thu, 6 May 1999 15:28:16 -0400 (EDT), Stephan Greene wrote:
>
>I'm trying to install and try out an XML app server called Enhydra
>( http://www.www.enhydra.org ); it requires a JDK be installed.
>
>With jdk117_v1a installed, I get the following error wjen I try to start
>it:
>
>> B./run_demos
I'm trying to install and try out an XML app server called Enhydra
( http://www.www.enhydra.org ); it requires a JDK be installed.
With jdk117_v1a installed, I get the following error wjen I try to start
it:
> B./run_demos
/usr/local/jdk117_v1a/bin/../bin/i486/green_threads/java: error in loadi
> tomas writes:
tomas> I'm getting these errors when executing "java", without any
tomas> more parameters, only to see the command line options. I
tomas> have installed JDK 1.1.2 and runs without any problems, but
tomas> neither JDK 1.1.7 nor JDK 1.2 don't work.
tomas> D
I'm getting these errors when executing "java", without any more
parameters, only to see the command line options. I have installed JDK
1.1.2 and runs without any problems, but neither JDK 1.1.7 nor JDK 1.2
don't work.
Do you know what I can do to solve this problem ?
/usr/local/jdk117_v1a/bi
Dear Sirs,
I upgraded my redhat system to the starbuck (blah) distribution and
it seems that this broke java, maybe due to the new glibc (2.1.1), here is the
error:
/usr/local/java/bin/../bin/i686/green_threads/java: error in loading shared libraries:
/usr/local/java/bin/../lib/i686/gree
Nathan Meyers wrote:
> 1) The kernel controls it, or
>
> 2) It's controlled in user space.
>
> Native threads use answer #1, while green threads are the (nearly)
> OS-independent Sun version of answer #2. They have the advantage of
> working, with some porting effort,
Lee Chee Wai wrote:
> I have read the README file associated with the 1.1.7b port on
> the native thread support package and am a little confused by the
> description of native and "green" threads.
>
> I'd first like to ask about "green" th
Hi,
I have read the README file associated with the 1.1.7b port on
the native thread support package and am a little confused by the
description of native and "green" threads.
I'd first like to ask about "green" threads. What exactly are
they and where c
78 matches
Mail list logo
