Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java daemon

Reply
Thread Tools

Java daemon

 
 
sl@exabyte
Guest
Posts: n/a
 
      11-12-2012
I gather that PHP daemon suffers from memory leak problem due to its garbage
collector mechanism.

Since java also adopts the garbage collector mechanism, would java daemon
suffers from the same memory problem ?

Thanks.


 
Reply With Quote
 
 
 
 
David Lamb
Guest
Posts: n/a
 
      11-12-2012
On 12/11/2012 9:17 AM, sl@exabyte wrote:
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?


There are several different ways to do garbage collection, so flaws in
one implementation have no bearing on what goes on with another.

The most common complaint that crosses implementations is the
unpredictability of when a gc happens, which can be a problem for a
program with serious real-time constraints. IIRC Java implementations
often have the gc run continuously and incrementally in a separate
thread, which evens out the effect.
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      11-12-2012
On 11/12/2012 9:17 AM, sl@exabyte wrote:
> I gather that PHP daemon suffers from memory leak problem due to its garbage
> collector mechanism.
>
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?


PHP uses reference counting, which has some known problems (circular
references).

It is typical not a big problem in PHP due to everything going out
when request scope runs out.

(that of course does not cover native resources in extensions,
but Java does not do anything with those either)

There are many Java implementations and most of them support
multiple garbage collection algorithms, so it is difficult to say
what "Java" does.

But all the most popular uses some type of mark and sweep to
find what is still reachable and what is not.

That does not have the same problems as reference counting.

So assuming that you use a common Java implementation, then
you should not see the same problems as in PHP.

Arne



 
Reply With Quote
 
sl@exabyte
Guest
Posts: n/a
 
      11-12-2012
David Lamb wrote:
> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>
> The most common complaint that crosses implementations is the
> unpredictability of when a gc happens, which can be a problem for a
> program with serious real-time constraints. IIRC Java implementations
> often have the gc run continuously and incrementally in a separate
> thread, which evens out the effect.


This is an interesting pointer/direction (I am new with java, but have done
quite some C/C++ on windows).

I have sort of given up hope on PHP daemon; one cannot touch its GC I
suppose. I am adamant to go C/C++; I have not done anything on Linux. I
suppose it would take too long a time to get it up and running (my target is
end of December 2012). So my next best option is java.











 
Reply With Quote
 
Jim Janney
Guest
Posts: n/a
 
      11-12-2012
"sl@exabyte" <> writes:

> I gather that PHP daemon suffers from memory leak problem due to its garbage
> collector mechanism.
>
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?


Probably not: not all implementations of GC are equal, and you can't
generalize from one to another. For what it's worth, Twitter is in the
process of migrating from Ruby to Java due to problems with memory
management, and claims to be happy with the results:

http://www.theregister.co.uk/2012/11...saved_by_java/

--
Jim Janney
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-12-2012
Jim Janney wrote:
> "sl@exabyte" writes:
>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>> collector mechanism.


More likely it suffers from a packratting problem - failure to release memory.

>> Since java also adopts the garbage collector mechanism, would java daemon
>> suffers from the same memory problem ?


Not the same problem, but you can force Java to hang on to object references long
past their usefulness, and eventually use up your available memory.

Idiomatic Java avoids this.

--
Lew
 
Reply With Quote
 
sl@exabyte
Guest
Posts: n/a
 
      11-13-2012
Martin Gregorie wrote:
>>

> Actual Linux installation is fairly fast: the last install I did
> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
> the following times:
>
>....


Acutally I mean the my c/c++ programming in Linux would probably take too
long a time to meet my target since I have done anything on Linux.
My server program has to process XML string and MySQL. I had a look at a
sample C program with MySQL API last night, it did not look that
intimidating. At this stage I am a bit encouraged to dip my little toe into
the Linux pool. But my programming experience tells me there are always
surprises.



 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      11-13-2012
On 11/12/2012 4:35 PM, Lew wrote:
> Jim Janney wrote:
>> "sl@exabyte" writes:
>>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>>> collector mechanism.

>
> More likely it suffers from a packratting problem - failure to release memory.


Reference counted GC has known problems even without packratting.

>>> Since java also adopts the garbage collector mechanism, would java daemon
>>> suffers from the same memory problem ?

>
> Not the same problem, but you can force Java to hang on to object references long
> past their usefulness, and eventually use up your available memory.
>
> Idiomatic Java avoids this.


And none of the common Java implementations use reference counting for GC.

Arne


 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      11-13-2012
On 11/12/2012 5:07 PM, Martin Gregorie wrote:
> On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:
>> I have sort of given up hope on PHP daemon; one cannot touch its GC I
>> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>>

> I've not done a lot with PHP, but haven't (so far) run into any
> particular problems with the Apache/PHP combination under Linux.


For the typical web page the request scope is sufficient to
avoid problems.

But a daemon is not a typical web page.

Arne

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      11-13-2012
On 11/12/2012 9:56 PM, sl@exabyte wrote:
> Martin Gregorie wrote:
>>>

>> Actual Linux installation is fairly fast: the last install I did
>> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
>> the following times:
>>
>> ....

>
> Acutally I mean the my c/c++ programming in Linux would probably take too
> long a time to meet my target since I have done anything on Linux.
> My server program has to process XML string and MySQL. I had a look at a
> sample C program with MySQL API last night, it did not look that
> intimidating. At this stage I am a bit encouraged to dip my little toe into
> the Linux pool. But my programming experience tells me there are always
> surprises.


The MySQL C API is indeed rather easy to work with.

If you have worked with PHP nysql or mysqli extensions, then it
will be even easier.

Arne


 
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
writing java daemon server: start and stop calvin01 Java 5 05-30-2009 05:39 PM
Re: PEP 3143: Standard daemon process library (was: Writing awell-behaved daemon) Floris Bruynooghe Python 1 03-24-2009 02:58 PM
Re: PEP 3143: Standard daemon process library (was: Writing awell-behaved daemon) Jean-Paul Calderone Python 0 03-20-2009 01:02 PM
Daemon Win32::Daemon; ph1975@gmail.com Perl Misc 0 09-07-2006 10:58 AM
running java program as daemon on Unix System Fatih Java 4 04-09-2004 09:40 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57