Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15311 > unrolled thread

Recommendations for Lightweight Threading?

Back to article view | Back to comp.lang.java.programmer

Contents

  Recommendations for Lightweight Threading? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-15 17:33 -0500
    Re: Recommendations for Lightweight Threading? markspace <-@.> - 2012-06-15 15:55 -0700
      Re: Recommendations for Lightweight Threading? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-15 18:12 -0500
        Re: Recommendations for Lightweight Threading? markspace <-@.> - 2012-06-15 16:31 -0700
          Re: Recommendations for Lightweight Threading? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-15 20:00 -0500
          Re: Recommendations for Lightweight Threading? Robert Klemme <shortcutter@googlemail.com> - 2012-06-16 14:39 +0200
            Re: Recommendations for Lightweight Threading? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-16 12:13 -0700
        Re: Recommendations for Lightweight Threading? Roedy Green <see_website@mindprod.com.invalid> - 2012-06-16 00:57 -0700
    Re: Recommendations for Lightweight Threading? Lew <lewbloch@gmail.com> - 2012-06-15 15:57 -0700
      Re: Recommendations for Lightweight Threading? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-15 18:12 -0500
    Re: Recommendations for Lightweight Threading? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-15 20:19 -0400
      Re: Recommendations for Lightweight Threading? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-15 19:59 -0500
        Re: Recommendations for Lightweight Threading? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-15 21:37 -0400
          Controlling the Garbage Collector "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-16 11:51 -0500
            Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-16 14:24 -0400
              Re: Controlling the Garbage Collector markspace <-@.> - 2012-06-16 12:24 -0700
                Re: Controlling the Garbage Collector Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-16 13:14 -0700
                  Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-16 16:35 -0400
                    Re: Controlling the Garbage Collector "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-16 19:43 -0500
                    Re: Controlling the Garbage Collector Wanja Gayk <brixomatic@yahoo.com> - 2012-06-23 13:36 +0200
                      Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-23 15:39 +0200
                  Re: Controlling the Garbage Collector markspace <-@.> - 2012-06-16 14:34 -0700
            Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-18 04:32 -0700
              Re: Controlling the Garbage Collector Roedy Green <see_website@mindprod.com.invalid> - 2012-06-24 14:31 -0700
            Re: Controlling the Garbage Collector Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 21:19 -0400
              Re: Controlling the Garbage Collector "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-21 13:24 -0500
                Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-21 11:37 -0700
                  Re: Controlling the Garbage Collector Fred Greer <fggreer@nospam.invalid> - 2012-06-21 21:20 +0000
                Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-21 15:24 -0400
                Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-21 23:46 +0200
                  Re: Controlling the Garbage Collector Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-06-25 15:28 +0300
                    Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 09:05 -0400
                      Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-25 17:01 +0000
                        Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 13:45 -0400
                          Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 13:49 -0400
                          Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-25 20:41 +0200
                            Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-26 12:25 +0000
                              Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-26 06:46 -0700
                                Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-26 16:26 +0000
                                  Re: Controlling the Garbage Collector Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 13:07 -0400
                                    Re: Controlling the Garbage Collector Robert Klemme <shortcutter@googlemail.com> - 2012-06-26 22:28 +0200
                                    Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-26 23:49 +0000
                                      Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-26 18:20 -0700
                                        Re: Controlling the Garbage Collector Highway to Hell <HtH49439112@gmail.com> - 2012-06-26 21:52 -0400
                                          Re: Controlling the Garbage Collector Gene Wirchenko <genew@ocis.net> - 2012-06-26 20:01 -0700
                                            Re: Controlling the Garbage Collector Highway to Hell <HtH49439112@gmail.com> - 2012-06-26 23:23 -0400
                                              Re: Controlling the Garbage Collector Gene Wirchenko <genew@ocis.net> - 2012-06-27 09:05 -0700
                                                Re: Controlling the Garbage Collector Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-27 20:15 +0000
                                                  Re: Controlling the Garbage Collector Gene Wirchenko <genew@ocis.net> - 2012-06-27 13:52 -0700
                                                  Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-27 13:41 -0700
                                                    Re: Controlling the Garbage Collector Gene Wirchenko <genew@ocis.net> - 2012-06-27 19:02 -0700
                                                    Re: Controlling the Garbage Collector Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-28 21:45 +0000
                                                      Re: [OT] Driver's license restrictions (Was: Controlling the Garbage Collector) Lew <lewbloch@gmail.com> - 2012-06-28 15:16 -0700
                                                        Re: [OT] Driver's license restrictions (Was: Controlling the Garbage Collector) Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-29 02:10 +0000
                                                        Re: [OT] Driver's license restrictions (Was: Controlling the Garbage Collector) Gene Wirchenko <genew@ocis.net> - 2012-06-28 19:57 -0700
                                                          Re: [OT] Driver's license restrictions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-29 04:06 +0000
                                                            Re: [OT] Driver's license restrictions Tim Slattery <Slattery_T@bls.gov> - 2012-06-29 08:35 -0400
                                                          Re: [OT] Driver's license restrictions (Was: Controlling the Garbage Collector) Tim Slattery <Slattery_T@bls.gov> - 2012-06-29 08:33 -0400
                                                      Re: Controlling the Garbage Collector Tim Slattery <Slattery_T@bls.gov> - 2012-06-29 08:30 -0400
                                                        Re: Controlling the Garbage Collector Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-29 23:04 +0000
                                                Re: Controlling the Garbage Collector Highway to Hell <HtH49439112@gmail.com> - 2012-06-27 16:53 -0400
                                              Re: Controlling the Garbage Collector Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-27 11:32 -0500
                                                Re: Controlling the Garbage Collector Highway to Hell <HtH49439112@gmail.com> - 2012-06-27 16:54 -0400
                                          Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-27 11:45 -0700
                                            Re: Controlling the Garbage Collector Highway to Hell <HtH49439112@gmail.com> - 2012-06-27 16:55 -0400
                                        Re: Controlling the Garbage Collector glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-27 02:06 +0000
                                      Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-27 16:34 +0000
                                      Re: Controlling the Garbage Collector Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-27 11:45 -0500
                                      Re: Controlling the Garbage Collector Wanja Gayk <brixomatic@yahoo.com> - 2012-07-02 11:21 +0200
                              Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-26 13:52 -0700
                                Re: Controlling the Garbage Collector Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-26 23:40 +0000
                                  Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-26 16:48 -0700
                Re: Controlling the Garbage Collector markspace <-@.> - 2012-06-21 15:15 -0700
                  Re: Controlling the Garbage Collector Lew <lewbloch@gmail.com> - 2012-06-21 15:33 -0700
                    Re: Controlling the Garbage Collector "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-21 21:24 -0500
                Re: Controlling the Garbage Collector markspace <-@.> - 2012-06-21 15:23 -0700
          Re: Recommendations for Lightweight Threading? Wanja Gayk <brixomatic@yahoo.com> - 2012-06-17 15:49 +0200
      Re: Recommendations for Lightweight Threading? Roedy Green <see_website@mindprod.com.invalid> - 2012-06-16 01:00 -0700
        Re: Recommendations for Lightweight Threading? Roedy Green <see_website@mindprod.com.invalid> - 2012-06-16 01:04 -0700
    Re: Recommendations for Lightweight Threading? Wanja Gayk <brixomatic@yahoo.com> - 2012-06-16 04:03 +0200
    Re: Recommendations for Lightweight Threading? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-15 22:27 -0700
      Re: Recommendations for Lightweight Threading? Robert Klemme <shortcutter@googlemail.com> - 2012-06-16 14:39 +0200
        Re: Recommendations for Lightweight Threading? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-18 19:37 -0700
          Re: Recommendations for Lightweight Threading? Robert Klemme <shortcutter@googlemail.com> - 2012-06-19 07:46 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#15311 — Recommendations for Lightweight Threading?

I am considering moving one of my projects from C to Java, but I am 
hoping to find a high-performance threading implementation, or something 
along the lines of libqthread, which offers Fill-Empty bit blocking and 
good cooperative lightweight threading as a library.

Is there a current "best" solution when doing many threaded programs in 
Java?  By many threads I mean many more than the cores or machines on the 
network.  Something that scales up efficiently to distributed computing 
would be nice as well.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [next] | [standalone]

#15312

On 6/15/2012 3:33 PM, Aaron W. Hsu wrote:
> I am considering moving one of my projects from C to Java, but I am
> hoping to find a high-performance threading implementation, or something
> along the lines of libqthread, which offers Fill-Empty bit blocking and
> good cooperative lightweight threading as a library.
>
> Is there a current "best" solution when doing many threaded programs in
> Java?  By many threads I mean many more than the cores or machines on the
> network.  Something that scales up efficiently to distributed computing
> would be nice as well.
>


As far as I know, the built-in class java.lang.Thread is the only game 
in town.  The JVM is responsible for implementation, it will use 
pthreads or native processes or whatever is considered "best" on a given 
platform.  (Did you really mean "libqthread" or "libpthread"?)

Java doesn't do "special libraries on each platform" like C does.  Java 
puts all its effort into making the one implementation there is be as 
fast and as efficient as possible.  That's a bit of a change of mind-set 
for a lot of folks, but it works very well in practice.  I'd do some 
bench-marking first before you decide to try to import special libraries.

There are of course libraries in the Java API.  Be sure to check out the 
java.util.concurrent package.  Actually using Thread directly is 
considered noobish these days.

Here's a primer:

<http://docs.oracle.com/javase/tutorial/essential/concurrency/>

[toc] | [prev] | [next] | [standalone]

#15315

On Fri, 15 Jun 2012 15:55:39 -0700, markspace wrote:

> There are of course libraries in the Java API.  Be sure to check out the
> java.util.concurrent package.  Actually using Thread directly is
> considered noobish these days.

I was not aware of the java.util.concurrent package, but it looks like it 
contains pretty much all of the serious things that I want to use or work 
with. Thank you.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15316

On 6/15/2012 4:12 PM, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 15:55:39 -0700, markspace wrote:
>
>> There are of course libraries in the Java API.  Be sure to check out the
>> java.util.concurrent package.  Actually using Thread directly is
>> considered noobish these days.
>
> I was not aware of the java.util.concurrent package, but it looks like it
> contains pretty much all of the serious things that I want to use or work
> with. Thank you.


Good.  I've experimented with that package quite a bit, and I also found 
it very intelligently designed.  If you're not familiar with the Java 
memory model, I recommend Java Concurrency in Practice by Brian Goetz. 
(Even if you are familiar with the Java memory model, I still recommend 
that book.  It's very very good.)  It's pretty much the be-all and 
end-all of Java concurrency.

http://jcip.net/

I have a hobbyist interest in concurrency.  I don't work with large 
systems, just use multi-threading on commodity hardware, but it seems to 
me that concurrency is the wave of the future, if not realistically the 
wave of the present.  If you'd like to keep us abreast of your project, 
I'd love to know how Java fares in something approaching the environment 
qthreads was designed for.

[toc] | [prev] | [next] | [standalone]

#15319

On Fri, 15 Jun 2012 16:31:55 -0700, markspace wrote:

> If you'd like to keep us abreast of your project,
> I'd love to know how Java fares in something approaching the environment
> qthreads was designed for.

Sure, once I have more of the elements put into Java and have tested 
them, I am happy to report on my findings. 

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15330

On 16.06.2012 01:31, markspace wrote:
> On 6/15/2012 4:12 PM, Aaron W. Hsu wrote:
>> On Fri, 15 Jun 2012 15:55:39 -0700, markspace wrote:
>>
>>> There are of course libraries in the Java API. Be sure to check out the
>>> java.util.concurrent package. Actually using Thread directly is
>>> considered noobish these days.
>>
>> I was not aware of the java.util.concurrent package, but it looks like it
>> contains pretty much all of the serious things that I want to use or work
>> with. Thank you.
>
>
> Good. I've experimented with that package quite a bit, and I also found
> it very intelligently designed. If you're not familiar with the Java
> memory model, I recommend Java Concurrency in Practice by Brian Goetz.
> (Even if you are familiar with the Java memory model, I still recommend
> that book. It's very very good.) It's pretty much the be-all and end-all
> of Java concurrency.

Also "Concurrent Programming in Java" by Doug Lea (who did most of 
java.uti.concurrent.* AFAIK) is a very good read.

http://www.informit.com/store/product.aspx?isbn=0201310090

His homepage is at http://g.oswego.edu/

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#15335

On 6/16/12 5:39 AM, Robert Klemme wrote:
> On 16.06.2012 01:31, markspace wrote:
>> On 6/15/2012 4:12 PM, Aaron W. Hsu wrote:
>>> On Fri, 15 Jun 2012 15:55:39 -0700, markspace wrote:
>>>
>>>> There are of course libraries in the Java API. Be sure to check out the
>>>> java.util.concurrent package. Actually using Thread directly is
>>>> considered noobish these days.
>>>
>>> I was not aware of the java.util.concurrent package, but it looks
>>> like it
>>> contains pretty much all of the serious things that I want to use or
>>> work
>>> with. Thank you.
>>
>>
>> Good. I've experimented with that package quite a bit, and I also found
>> it very intelligently designed. If you're not familiar with the Java
>> memory model, I recommend Java Concurrency in Practice by Brian Goetz.
>> (Even if you are familiar with the Java memory model, I still recommend
>> that book. It's very very good.) It's pretty much the be-all and end-all
>> of Java concurrency.
>
> Also "Concurrent Programming in Java" by Doug Lea (who did most of
> java.uti.concurrent.* AFAIK) is a very good read.
>
> http://www.informit.com/store/product.aspx?isbn=0201310090
I haven't read that one, but I feel obliged to note that Doug Lea is 
also listed as one of the co-authors of JCIP.

[toc] | [prev] | [next] | [standalone]

#15326

On Fri, 15 Jun 2012 18:12:45 -0500, "Aaron W. Hsu"
<arcfide@sacrideo.us> wrote, quoted or indirectly quoted someone who
said :

>I was not aware of the java.util.concurrent package, but it looks like it 
>contains pretty much all of the serious things that I want to use or work 
>with. Thank you.

see http://mindprod.com/jgloss/thread.html and look for the book with
the three high speed locomotives on the cover.  It explains how to use
java.util.concurrent. 
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
.

[toc] | [prev] | [next] | [standalone]

#15313

Aaron W. Hsu wrote:
> I am considering moving one of my projects from C to Java, but I am 
> hoping to find a high-performance threading implementation, or something 
> along the lines of libqthread, which offers Fill-Empty bit blocking and 
> good cooperative lightweight threading as a library.
> 
> Is there a current "best" solution when doing many threaded programs in 
> Java?  By many threads I mean many more than the cores or machines on the 
> network.  Something that scales up efficiently to distributed computing 
> would be nice as well.

Yes.

The Java standard API sports the 'java.util.concurrent' package (and related)
<http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-frame.html>

Multi-threading is built into the very language. Even normal "synchronized" 
blocks perform well under many typical circumstances.

I don't know what "Fill-Empty bit blocking" is, but if you give up looking for 
specific idioms and specify the strategic goals, you'll find what you need in 
Java.

As to which combination of the API calls will be "best" for you, that depends 
entirely on your needs. Different parts are "best" for different use cases.

So the question is, something that scales *what* up efficiently would be nice 
for you?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15314

On Fri, 15 Jun 2012 15:57:47 -0700, Lew wrote:

> The Java standard API sports the 'java.util.concurrent' package (and
> related)

Thanks for this! It seems like java.util.concurrent is a good mapping to 
the functionality that I want.  Most notably, the idea of executors and 
thread pools as well as atomic variables will work nicely for what I want 
to do.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15317

On 6/15/2012 6:33 PM, Aaron W. Hsu wrote:
> I am considering moving one of my projects from C to Java, but I am
> hoping to find a high-performance threading implementation, or something
> along the lines of libqthread, which offers Fill-Empty bit blocking and
> good cooperative lightweight threading as a library.
>[...]

     Others have covered the essentials, but I'd like to raise an
eyebrow at the word "cooperative."  In the usual argot, "cooperative
threading" refers to schemes where a thread runs until it chooses
to relinguish the CPU, voluntarily.  This may be contrasted to
"preemptive" schemes, where an external scheduler decides which
threads will run on which CPU's and when, and may choose to evict
a running thread or start a stalled thread at any arbitrary moment.

     The "collegial" nature of cooperative threading offers a degree
of calmness, and some freedom from worry about critical sections
(if you're on a uniprocessor, you may be able to avoid taking an
explicit lock to guard a critical section: Just don't yield the CPU
while you're in it).  But this cooperation is fragile in the extreme,
and becomes almost completely untenable once you start assembling an
application out of classes from disparate sources.  Unless you're
writing for a very tightly controlled environment where you have
audited all the components or developed them yourself -- embedded
software in a Mars rover, say -- I think "cooperative multithreading"
is too brittle for most practical applications.

     If that's not what you meant by "cooperative," well, never mind.
But if it is, my advice is Don't Do That.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15318

On Fri, 15 Jun 2012 20:19:12 -0400, Eric Sosman wrote:

> Unless you're writing for a very tightly controlled environment where
> you have audited all the components or developed them yourself --
> embedded software in a Mars rover, say -- I think "cooperative
> multithreading"
> is too brittle for most practical applications.

In some sense, this is the environment.  I am building on top of non-
deterministic concurrency primitives to construct deterministic models.  
In these models, I prefer to have more control over when thread 
preemption happens, as well as what lightweight threads get associated 
with what worker thread (thread pool) and similarly what worker threads 
get associated with what CPUs.  This is to allow me to make more fine 
grained decisions about scheduling, which may affect cache behavior. 

Preemptive multi-threading is certainly the more reliable when dealing 
with a general programming interface, but since these models specifically 
constrain the problems in certain ways, I know the points at which I 
would like to preempt a thread, and I also know that preempting earlier 
or later than these points is relatively useless.

Once I have a model written up in Java, I will see how things go.  It is 
likely that for small scale tests I will not notice a difference in 
cooperative versus preemptive models.


-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15320

On 6/15/2012 8:59 PM, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 20:19:12 -0400, Eric Sosman wrote:
>
>> Unless you're writing for a very tightly controlled environment where
>> you have audited all the components or developed them yourself --
>> embedded software in a Mars rover, say -- I think "cooperative
>> multithreading"
>> is too brittle for most practical applications.
>
> In some sense, this is the environment.  I am building on top of non-
> deterministic concurrency primitives to construct deterministic models.
> In these models, I prefer to have more control over when thread
> preemption happens, as well as what lightweight threads get associated
> with what worker thread (thread pool) and similarly what worker threads
> get associated with what CPUs.  This is to allow me to make more fine
> grained decisions about scheduling, which may affect cache behavior.
>
> Preemptive multi-threading is certainly the more reliable when dealing
> with a general programming interface, but since these models specifically
> constrain the problems in certain ways, I know the points at which I
> would like to preempt a thread, and I also know that preempting earlier
> or later than these points is relatively useless.
>
> Once I have a model written up in Java, I will see how things go.  It is
> likely that for small scale tests I will not notice a difference in
> cooperative versus preemptive models.

     Okay.  Keep in mind that in Java it is very difficult to avoid
being preempted: Even if the thread you're interested in is careful
not to create new object instances, object creation in other threads
can trigger the garbage collector at pretty much any time.  You may
be able to get some scheduling benefits out of a cooperative scheme,
but I doubt you'll get thread safety.  Locking or the concurrency
libraries will be all but unavoidable.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15332 — Controlling the Garbage Collector

On Fri, 15 Jun 2012 21:37:32 -0400, Eric Sosman wrote:

> Even if the thread you're interested in is careful not to create new
> object instances, object creation in other threads can trigger the
> garbage collector at pretty much any time.

The garbage collector is one of the reasons that I have hesitated to move 
to Java.  In some languages (Chez Scheme) I can get quite explicit 
control over when and how garbage collection occurs, which can make it 
possible to do very fine grained things to avoid some of the corner case 
problems that can manifest in garbage collected languages.  Usually this 
is not a problem at all, but I would like to have the control nonetheless.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15333 — Re: Controlling the Garbage Collector

On 6/16/2012 12:51 PM, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 21:37:32 -0400, Eric Sosman wrote:
>
>> Even if the thread you're interested in is careful not to create new
>> object instances, object creation in other threads can trigger the
>> garbage collector at pretty much any time.
>
> The garbage collector is one of the reasons that I have hesitated to move
> to Java.  In some languages (Chez Scheme) I can get quite explicit
> control over when and how garbage collection occurs, which can make it
> possible to do very fine grained things to avoid some of the corner case
> problems that can manifest in garbage collected languages.  Usually this
> is not a problem at all, but I would like to have the control nonetheless.

     Then I'd suggest Java may be ill-suited to your needs.

     You may be able to get some level of GC control on a particular
JVM implementation, but it won't be robust.  Your control is likely
to slip if you move your Java to another machine, or if you upgrade
the JVM, or even if you do something as innocuous as adjusting the
sizes of assorted memory pools.

     For good or ill, Java's "attitude" about garbage collection is
that it's a service provided by the JVM -- in whatever way the JVM
sees fit to provide it, and the JVM is allowed to be capricious.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15336 — Re: Controlling the Garbage Collector

On 6/16/2012 11:24 AM, Eric Sosman wrote:
>      Then I'd suggest Java may be ill-suited to your needs.


For us production coders, that's true.  Depending on how experimental 
Aaron's project is however, hacking the JVM may not be out of the 
question.  What he's talking about certainly sounds more academic to me, 
so I'm sort of curious what methods he's going to use to achieve his goals.

[toc] | [prev] | [next] | [standalone]

#15337 — Re: Controlling the Garbage Collector

On 6/16/12 12:24 PM, markspace wrote:
> On 6/16/2012 11:24 AM, Eric Sosman wrote:
>> Then I'd suggest Java may be ill-suited to your needs.
>
>
> For us production coders, that's true. Depending on how experimental
> Aaron's project is however, hacking the JVM may not be out of the
> question. What he's talking about certainly sounds more academic to me,
> so I'm sort of curious what methods he's going to use to achieve his goals.
It almost sounds like the Aaron may be better off using Event Loop style 
architecture, with one event dispatch thread per CPU core. Allow the GC 
to do what it does best, and have the operations be smaller and more 
decoupled.

[toc] | [prev] | [next] | [standalone]

#15338 — Re: Controlling the Garbage Collector

On 6/16/2012 4:14 PM, Daniel Pitts wrote:
> On 6/16/12 12:24 PM, markspace wrote:
>> On 6/16/2012 11:24 AM, Eric Sosman wrote:
>>> Then I'd suggest Java may be ill-suited to your needs.
>>
>>
>> For us production coders, that's true. Depending on how experimental
>> Aaron's project is however, hacking the JVM may not be out of the
>> question. What he's talking about certainly sounds more academic to me,
>> so I'm sort of curious what methods he's going to use to achieve his
>> goals.
> It almost sounds like the Aaron may be better off using Event Loop style
> architecture, with one event dispatch thread per CPU core. Allow the GC
> to do what it does best, and have the operations be smaller and more
> decoupled.

     I, too, am mystified about what he's up to.  It's hard to reconcile
an interest in tight control over GC with "Something that scales up
efficiently to distributed computing" -- the aims seem divergent.

     Aaron: Care to share?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15342 — Re: Controlling the Garbage Collector

On Sat, 16 Jun 2012 16:35:49 -0400, Eric Sosman wrote:

> Aaron: Care to share?

I can share what I feel able to. :-)  As you and others have probably 
guessed, this is academic research into programming languages. In 
particular, I am doing static analysis of arrays and array accesses in a 
language designed specifically for deterministic parallel programming.  
The success of the parallelism relies a great deal on how well I can 
schedule and layout the various arrays that are globally available, and 
on what machines/cores, and how that allocation is done.

This is why controlling the GC is a nice feature, though not strictly 
necessary.  It's also why cooperative threading is nice, but also not 
strictly necessary.  At the moment, depending on the results of my 
experiments with a simple Java implementation of some core runtime 
features, Java presents an increasingly attractive target, both socially 
and technically.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15543 — Re: Controlling the Garbage Collector

In article <jriqn9$og$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

>      I, too, am mystified about what he's up to.  It's hard to reconcile
> an interest in tight control over GC with "Something that scales up
> efficiently to distributed computing" -- the aims seem divergent.

I agree. If it was about realtime constraints I would understand it, but 
the "distributed" part seems to contradict this, even though timeouts 
exist.

Maybe it's just because sometimes people don't like to give up control 
they once had, just to be sure they could if they needed, even though in 
99.99% of all cases they don't.

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web