Calvin Austin wrote:
> I had a simple roadmap up to 1.5 and some performance graphs between 1.3.0 to
> 1.4
>
> Questions from the attendees ranged from 64bit hammer support to readiness of
> the new ibm pthreads library. Would the libc_wait symbol be fixed for glibc
> 2.2.5. Can the performance t
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
Nelson Minar wrote:
> What a great discussion this has been!
>
> >I don't think anyone is arguing that high thread counts are always
> >wrong or that the current implementation is the best of all worlds.
>
> Phew!
>
> >Yes, the Linux kernel can do better and Java implementations can do better
>
>
What a great discussion this has been!
>I don't think anyone is arguing that high thread counts are always
>wrong or that the current implementation is the best of all worlds.
Phew!
>Yes, the Linux kernel can do better and Java implementations can do better
And in the current situation, we hav
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-
Michael Thome wrote:
1. Java proposes Thread as a general-purpose language
abstraction,
complete with syntactic support for synchronization. Any Java
VM
implementation which significantly limits the ability to use this
abstraction violates the spirit of the language design (if not the
letter, gi
> "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 amount of
effort to o
> "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
> "Stefaan" == Stefaan A Eeckels <[EMAIL PROTECTED]> writes:
> 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 me
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
> "Matt" == Matt Welsh <[EMAIL PROTECTED]> writes:
> Michael Thome <[EMAIL PROTECTED]> writes:
>> I think the best answer is to do the second tier threading in userspace
>> (best would be in glibc).
> While on the surface this looks like the simple solution, in practice it
> is very diffic
> "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
> "Nelson" == Nelson Minar <[EMAIL PROTECTED]> writes:
Nelson> There's a AWT on GTK port on the SCSL site, but they don't
Nelson> intend to do anything with it.
The port is incomplete and has been on the site for a long time. We
always were and still are interested in replacing Moti
[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 they cannot take
>> 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?
Many of these examples have a common theme - lots of network I/O to
different places. We've learned from web servers that it's actually
better if you multip
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
Michael Thome <[EMAIL PROTECTED]> writes:
> I think the best answer is to do the second tier threading in userspace
> (best would be in glibc).
While on the surface this looks like the simple solution, in practice it
is very difficult to do. It requires that any operation that might block
the
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.
> Thread management is the OS' job, not the applicati
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 the application's.
>
> We talke
Ah, so it was you who was asking the politically barbed question! :)
I enjoyed that.
It seemed that Eileen was just hyping up performance on 1.3 in
general - she just as easily could have been talking about 1.3 on Solaris.
Also, the fact that they weren't using the JIT with 1.2.2 when comparing
SHUDO Kazuyuki wrote:
>
> Mo DeJong wrote:
>
> > I would be interested in going to JavaGrande, but I hear bad things
> > about JavaOne.
>
> JavaOne costs us very expensive fee to attend it, at
> least US$ 1295. I'll attend Java Grande Conference but
> not JavaOne.
>
> > Where can I find more i
Mo DeJong wrote:
> I would be interested in going to JavaGrande, but I hear bad things
> about JavaOne.
JavaOne costs us very expensive fee to attend it, at
least US$ 1295. I'll attend Java Grande Conference but
not JavaOne.
> Where can I find more info about JavaGrande?
ACM Java Grande 2000
On Wed, 24 May 2000, Matt Welsh wrote:
> [EMAIL PROTECTED] (Nelson Minar) writes:
> > Are many Linux/Java folks coming to JavaOne? I'll be there.
>
> I am also interested in meeting people who may be coming to JavaGrande
> (which is held in SF just before JavaOne).
>
> If there is enough inte
[EMAIL PROTECTED] (Nelson Minar) writes:
> Are many Linux/Java folks coming to JavaOne? I'll be there.
I am also interested in meeting people who may be coming to JavaGrande
(which is held in SF just before JavaOne).
If there is enough interest, we should plan an informal Linux/Java BOF
somet
On Tue, 15 Jun 1999, Nelson Minar wrote:
> Seriously, that's great. What was the audience reaction? How much
> Linux presence is there at JavaOne? Hopefully IBM will make a big
> splash.
Well the Linux BOF was packed, and notes will be posted somewhere when
people get a chance. Steve Byrne, Ma
>He talked about how his daughter is even learning Java in high-school
>-- he brought her up on stage and the first question she asked was
>"So, when is Linux going to be supported?!".
Confidential to John Mitchell:
Right on! Make sure the forces of the Free Software Conspiracy send
her her payme
37 matches
Mail list logo
