Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: Recommendations for Lightweight Threading?

Reply
Thread Tools

Re: Recommendations for Lightweight Threading?

 
 
Arne Vajhøj
Guest
Posts: n/a
 
      06-21-2012
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.


What do you mean by corner case?

GC and real time does usually not fit well (*), but I would not consider
real time a corner case. Some need it - many don't.

Arne

*) There is RTSJ (Real-Time Specification for Java) but it does not
seem to have that much traction.


 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      06-21-2012
Aaron W. Hsu wrote:
> Arne Vajhj wrote:
>> Aaron W. Hsu wrote:
>>> 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.

>>
>> What do you mean by corner case?

>
> So, you mentioned that you thought real-time was not a corner case, but I
> guess I would consider it one compared to general purpose programming in
> the majority. However, there are other, less broad things where I have
> found it extremely helpful to have control of the collector.
>
> For instance, I implemented a number of weak pointer structures which


WeakReference.

> required me to be able to extend what happened during collections. This


Object#finalize()
WeakHashMap

> can be done in user-space efficiently if there is an efficient way to
> extend the garbage collector and trigger events to occur on certain
> conditions. This would be an example of a relatively obscure data
> structure that can be really useful in some situations.


Java has the infrastructure for what you need.

> On the other side, there are times when I know that I am going to be
> doing a number of very small, little allocations all in a row, and I do
> not want the GC to run during this tight loop, because it will cause a
> noticeable hit. I would rather delay the collector, consuming more memory
> until the end when I can explicitly trigger the collector at that point.


Have you looked at the parameters to control GC?

> Or, I may know that some structure is going to be extremely long lived
> and I need to keep it out of the collector entirely.


Are you absolutely certain you can do this better than the collector?
I'm not.

> Finally, there are times when I want to do a large bulk allocation
> outside of the collector, and then selectively move certain things into
> the collected space, but still have a checked, high-level way of
> accessing data structures in the uncollected space.


Not Java.

> Now, all of these are corner cases to me because you can get by without
> them in most situations, unless you are trying to eek out all of the
> performance you can from your system.


I'm not so sure that you could do what you want the way you say you want to..

I feel highly confident that by appropriate choice of collectors and tuning
their parameters you can achieve your performance goals.

--
Lew

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-21-2012
On 6/21/2012 2:24 PM, Aaron W. Hsu wrote:
> [...]
> On the other side, there are times when I know that I am going to be
> doing a number of very small, little allocations all in a row, and I do
> not want the GC to run during this tight loop, because it will cause a
> noticeable hit. I would rather delay the collector, consuming more memory
> until the end when I can explicitly trigger the collector at that point.


Sounds like you might be better off collecting first, when there
are fewer objects to be discovered and analyzed. Also, since you've
said you're not speaking of real-time applications, I don't see why
you should be concerned about the precise timing of the "hit:" Before,
after, during, what difference does it make? (If you're worried about
GC roiling the caches, please provide actual measurements.)

> Or, I may know that some structure is going to be extremely long lived
> and I need to keep it out of the collector entirely.


Generational collectors do a pretty good imitation of this. It's
not perfect because it takes time for the GC to discover what's long-
lived and what's not, but it's pretty effective. Also, it has the
huge advantage of always being right; few programmers can match that
accuracy. (See also "memory leak.")

> Finally, there are times when I want to do a large bulk allocation
> outside of the collector, and then selectively move certain things into
> the collected space, but still have a checked, high-level way of
> accessing data structures in the uncollected space.


JNI, if you simply must.

> Now, all of these are corner cases to me because you can get by without
> them in most situations, unless you are trying to eek out all of the
> performance you can from your system.


"Eek" is right ...

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d


 
Reply With Quote
 
Fred Greer
Guest
Posts: n/a
 
      06-21-2012
On Thu, 21 Jun 2012 11:37:09 -0700, Lew wrote:

> Aaron W. Hsu wrote:
>> Arne Vajhøj wrote:
>>> Aaron W. Hsu wrote:
>>>> 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.
>>>
>>> What do you mean by corner case?

>>
>> So, you mentioned that you thought real-time was not a corner case, but
>> I guess I would consider it one compared to general purpose programming
>> in the majority. However, there are other, less broad things where I
>> have found it extremely helpful to have control of the collector.
>>
>> For instance, I implemented a number of weak pointer structures which

>
> WeakReference.
>
>> required me to be able to extend what happened during collections. This

>
> Object#finalize()
> WeakHashMap
>
>> can be done in user-space efficiently if there is an efficient way to
>> extend the garbage collector and trigger events to occur on certain
>> conditions. This would be an example of a relatively obscure data
>> structure that can be really useful in some situations.


ReferenceQueue
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      06-21-2012
On 21.06.2012 20:24, Aaron W. Hsu wrote:
> On Wed, 20 Jun 2012 21:19:01 -0400, Arne Vajhj wrote:
>
>> On 6/16/2012 12:51 PM, Aaron W. Hsu wrote:

>
>>> 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.

>>
>> What do you mean by corner case?

>
> So, you mentioned that you thought real-time was not a corner case, butI
> guess I would consider it one compared to general purpose programming in
> the majority. However, there are other, less broad things where I have
> found it extremely helpful to have control of the collector.


Your statement illustrates one of the biggest problems of Java (or maybe
even any GC'ed language): GC should be automatic but humans still need
control (just count the collectors and all the JVM options for GC)
because the automatisms are not good enough (yet). Question is: will
they ever be good enough that we can get by without settings - or at
least a dramatic reduced number of settings? I do not see that coming
soon. Sun took seven or eight years from the first experimental
implementation of G1 to production ready. Go figure.

> For instance, I implemented a number of weak pointer structures which
> required me to be able to extend what happened during collections. This
> can be done in user-space efficiently if there is an efficient way to
> extend the garbage collector and trigger events to occur on certain
> conditions. This would be an example of a relatively obscure data
> structure that can be really useful in some situations.


Can you explain what you did at collection time? I am asking because
anytime I would prefer to do cleanup when I do not need an object any
more. This is the typical resource deallocation in a finally block or
other piece of code which is invoked after some operation has finished
(hooks for example). Advantage is that you free your resources as early
as possible and do not need to cope with the downsides of finalizers.
Finalizers in Java have so many disadvantages (i.e. when making objects
live again, effects on GC performance) that they are short of being
deprecated - at least that's my impression from what I read.

> On the other side, there are times when I know that I am going to be
> doing a number of very small, little allocations all in a row, and I do
> not want the GC to run during this tight loop, because it will cause a
> noticeable hit. I would rather delay the collector, consuming more memory
> until the end when I can explicitly trigger the collector at that point.


But what do you gain if a GC pause occurs after this operation? The
time is spent either way. Btw, depending on collector chosen you might
not even notice that it is running because it works in separate threads.

> Or, I may know that some structure is going to be extremely long lived
> and I need to keep it out of the collector entirely.


Long lived objects which live shorter than the application (i.e. not
classes) are actually the Achilles heel of GC because it is very hard to
tune the collector in a way that it does not visit those long living
objects too often and yet run often enough to ensure enough free memory
is available.

> Finally, there are times when I want to do a large bulk allocation
> outside of the collector, and then selectively move certain things into
> the collected space, but still have a checked, high-level way of
> accessing data structures in the uncollected space.


I once mused about such a thing as well. I you think a bit longer about
this then you'll notice that it won't work: these objects still have to
be visited because they may have references to other objects not in the
uncollectable space. You'll probably do not gain much - if anything at all.

> Now, all of these are corner cases to me because you can get by without
> them in most situations, unless you are trying to eek out all of the
> performance you can from your system.


Use many cores and G1. At least try it out.

Kind regards

robert

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



 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      06-21-2012
markspace wrote:
> System.gc() will


request to
> run the GC,


which request might not be honored, but if it is, it will

> move objects into one or more permanent generation spaces, and then dump
> the large blocks of temporary objects.
>
> Many things can alter this, and I see you have some special
> requirements, but the main bits of the Java GC should give you something
> very close to what you are looking for.


Agreed.

Tell us why the existing options don't reach your goals, OP.

--
Lew
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      06-23-2012
On 23.06.2012 13:36, Wanja Gayk wrote:

> 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.


In my experience it's different: you need to have control because the
automatic mechanisms in GC implementations still do not cope well with
all use cases (at least those we had). Although that does not mean that
for many use cases defaults are sufficient (which they are I believe).

Kind regards

robert

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


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      06-24-2012
On Mon, 18 Jun 2012 04:32:15 -0700 (PDT), Robert Klemme
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>Be sure to try out G1 collector. In my brief tests so far it worked pretty
>well with regard to the target timings albeit at the expense of a bit of CPU overhead.


There is also the GC in Jet. It does not seem to have the lurchiness
of Oracle GC.

see http://mindprod.com/jgloss/jet.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Computers are machines that do exactly what you tell them,
but they still can surprise you with the results.
~ Dr. Richard Dawkins 1941-03-26
 
Reply With Quote
 
Jukka Lahtinen
Guest
Posts: n/a
 
      06-25-2012
Robert Klemme <(E-Mail Removed)> writes:

> Long lived objects which live shorter than the application (i.e. not
> classes) are actually the Achilles heel of GC because it is very hard to
> tune the collector in a way that it does not visit those long living
> objects too often and yet run often enough to ensure enough free memory is


It might be good to have a method to gell the GC that a certain
long-lived object is no longer needed.
For example, something like
System.gc(Object old)
where old is the object that has just been needed the last time.

--
Jukka Lahtinen
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-25-2012
On 6/25/2012 8:28 AM, Jukka Lahtinen wrote:
> Robert Klemme <(E-Mail Removed)> writes:
>
>> Long lived objects which live shorter than the application (i.e. not
>> classes) are actually the Achilles heel of GC because it is very hard to
>> tune the collector in a way that it does not visit those long living
>> objects too often and yet run often enough to ensure enough free memory is

>
> It might be good to have a method to gell the GC that a certain
> long-lived object is no longer needed.
> For example, something like
> System.gc(Object old)
> where old is the object that has just been needed the last time.


How would you call the method?

--
Eric Sosman
(E-Mail Removed)d


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Recommendations for Lightweight Threading? Kevin McMurtrie Java 3 06-19-2012 02:46 PM
Re: Recommendations for Lightweight Threading? markspace Java 4 06-16-2012 07:13 PM
Re: Recommendations for Lightweight Threading? Lew Java 0 06-15-2012 10:57 PM
When I spawn a lightweight process in ASP.NET Does it time out?? MS News ASP .Net 2 07-31-2003 11:53 PM
lightweight XSLT-based page flow: anyone thought of this? SUPER KOOL 223 Java 0 07-29-2003 08:01 PM



Advertisments