Language:
switch to room list switch to menu My folders
Go to page: First ... 61 62 63 64 [65] 66 67 68 69 ... Last
[#] Fri Jul 23 2010 21:34:08 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ok, it's not that bad and you can collect while other threads are running.

I don't know what the overhead is, but stop-the-world is more efficient in throughput terms.

[#] Fri Jul 23 2010 23:41:52 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

What about interactive environments that require predictable response times?
Just how long do we "stop the world" ?

[#] Sat Jul 24 2010 11:45:01 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

as long as neccesary.
as I understand it there are different levels of cleaning, you clean once you get memory back you clean again you get more, so it depends how intensive your cleaning is.

[#] Sat Jul 24 2010 20:44:59 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I don't know the characteristics of the concurrent collectors... there are a few different implementations that claim to provide soft realtime capability though. JRockit is one of those.

Erlang also has a number of unique features in that area.

[#] Sun Jul 25 2010 18:16:05 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I bet it's slow as hell though, and that would be fine if it didn't hurt performance of the applications it was collecting for, but Ibet it does.
And of course what if the programs make a mess faster than that one thread can concurrently keep up with? You'd have to stop the world anyway.

[#] Sun Jul 25 2010 18:44:49 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I've been using it in Eclipse and it works well enough. shrug

And there are people using -XX:UseConcurrentGC on production web servers.

The thing is, it *is* possible to tolerate programs that perform allocation/deallocation while the concurrent collector is running; in a compacting GC environment, allocation is veryvery simple because you're always allocating sequentially down the same region, which might be implemented as one region per processor code/thread. Allocation doesn't ever have to deal with freelists. A concurrent collector might take advantage of this by refusing to sweep objects that are past wherever the allocation pointer was when the current mark/sweep cycle started...

So, in the Sun 1.6.0 world anyway, I think the new generation collector might still be a stop-the-world thing with a concurrent old generation collector... can't rememeber the details off top of head.

[#] Sun Jul 25 2010 20:46:33 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

ls is getting old. :-)

[#] Sun Jul 25 2010 23:44:51 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

as I understand it there are different levels of cleaning, you clean

once you get memory back you clean again you get more, so it depends
how intensive your cleaning is.

Ok, then I want the memory equivalent of one of those shower cleaners that you just spray on every day and never have to actually stop and scrub anything.
:)

[#] Mon Jul 26 2010 16:54:58 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Re: Garbage collection and multi-threading.

I was reading that the standard Haskell runtime has the same issue: i.e. the garbage collector has to stop all threads while it does its stuff. However, a new garbage collector is under development that will take advantage of multi-core CPUs and won't have to stop all threads when collecting.
Garbage Binder

[#] Mon Jul 26 2010 17:39:28 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

i.e. the garbage collector has to stop all threads while it does its
stuff. However, a new garbage collector is under development that will


If you're doing batch processing and your only concern is throughput, stopping the world is not a problem as long as your collector is itself parallel, i.e., if you have a single threaded collector and you stop the world, you don't get that nice linear SMP scalability because beyond a certain point you're dependent on one thread to get your work done. But if you can just mark/sweep/compact in parallel, that part of the problem goes away and you don't have to worry about running concurrently with application threads.

[#] Mon Jul 26 2010 18:46:19 EDT from dothebart @ Uncensored

Subject: Re:�0

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Jul 26 2010 16:54:58 EDT von Spell Binder @ Uncensored
Re: Garbage collection and multi-threading.

I was reading that the standard Haskell runtime has the same issue: i.e. the garbage collector has to stop all threads while it does its stuff. However, a new garbage collector is under development that will take advantage of multi-core CPUs and won't have to stop all threads when collecting.
Garbage Binder

I also heard its going to be released in some not to distant future. doing a hot race with the hurd ;-P

no, just kidding, no clue. I'm picking my own garbage.



[#] Tue Jul 27 2010 20:36:01 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ok, then I want the memory equivalent of one of those shower cleaners

that you just spray on every day and never have to actually stop and
scrub anything.
:)

You ever try them? They don't work.

[#] Tue Jul 27 2010 20:37:41 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

well, by stop the world I presume you're also freeing up all available cpu for garbage collecting you'd be pretty dumb to do it all in one thread, no?

[#] Tue Jul 27 2010 21:09:57 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You ever try them? They don't work.



We tried but couldn't resist the urge to scrub.

[#] Wed Jul 28 2010 00:27:57 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

cpu for garbage collecting you'd be pretty dumb to do it all in one
thread, no?

Unless you were on one of those quaint little single-core cpus that were popular up until about 4-5 years ago.

[#] Wed Jul 28 2010 00:28:36 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ford's getting old.

[#] Wed Jul 28 2010 15:59:47 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

We tried but couldn't resist the urge to scrub.

I resisted the urge to scrub like I resist the urge to clean anything, and as a result I found out they don't work.
It must be nice to be a compulsive cleaner.
I'm a compulsive fixer, I find I can't leave something broken if there's a chance I could poke around and fix it, but I just can't stand cleaning.

[#] Wed Jul 28 2010 16:00:44 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ford's getting old.

I've been old for a while. certainly most servers were multiprocessor and hyperthreaded long before a few years ago.
whatever. it's done.

[#] Wed Jul 28 2010 16:05:51 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

hey here's a good one.
are there threads in javascript?
I need to process a lot of shit in javascript and the browser hands which leads me to believe that there's on thread, but that may be a firefox/ie thing, maybe chrome is different.
so what I plan on doing is processing some, then setting a timer to process more 1-5ms later to give up time to the browser so it doesn't hang, but if I do that then more data can come in, and I can deal with that as long as I can be sure I'm not processing while I'm adding to my queue.

[#] Wed Jul 28 2010 16:16:33 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Oh wow, it's the Windows 3.1 event loop all over again.

Go to page: First ... 61 62 63 64 [65] 66 67 68 69 ... Last