Re: Do you use a garbage collector (java vs c++ difference in "new")

Discussion in 'Java' started by Roedy Green, Apr 11, 2008.

  1. Roedy Green

    Roedy Green Guest

    On Thu, 10 Apr 2008 20:31:49 -0500, Razii
    <> wrote, quoted or indirectly quoted
    someone who said :

    >Creating 10000000 new objects with the keyword 'new' in tight loop.


    All Java has to do is add N (the size of the object) to a counter and
    zero out the object. In C++ it also has to look for a hole the right
    size and record it is some sort of collection. C++ typically does not
    move objects once allocated. Java does.

    In my C++ days, we used NuMega to find leaks, objects that were
    allocated butw never deleted even after there were no references to
    them. We never got anywhere near nailing them all. With Java this is
    automatic. You can't make that sort of screw up, though you can
    packrat. See http://mindprod.com/jgloss/packratting.html
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 11, 2008
    #1
    1. Advertising

  2. Roedy Green

    Roedy Green Guest

    On Thu, 10 Apr 2008 22:57:44 -0500, Razii
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >I am not sure what you mean by that ... can you post the code?


    You can download the source of the JVM if you sign some sort of
    agreement. That may be waived now.

    All Java "new" has to do is something like this in assembler:

    addressOfNewObject = nextFreeSlot;

    nextFreeSlot += sizeOfObject;

    if ( nextFreeSlot > limit ) { garbageCollect(); }

    fill( addressOfNewObject, sizeOfObject, 0 );
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 11, 2008
    #2
    1. Advertising

  3. Roedy Green

    Roedy Green Guest

    On Thu, 10 Apr 2008 22:36:54 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >If thread A allocates 256 bytes, and thread B races in and concurrently
    >attempts to allocate 128 bytes... Which thread is going to win?


    If all threads share a common heap, new code would have to be
    synchronised. If you have that synchronisation, you could use a
    single global counter to use to generate a hashCode. Keep in mind we
    are talking assembler here. This is the very guts of the JVM. You can
    take advantage of an assembler atomic memory increment instruction for
    very low overhead synchronisation.

    You could invent a JVM where each thread has its own mini-heap for
    freshly created objects. Then it would not need to synchronise to
    allocate an object. Long lived objects could be moved to a common
    synchronised heap.

    JVMs have extreme latitude to do things any way they please so long
    as the virtual machine behaves in a consistent way.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #3
  4. Roedy Green

    Roedy Green Guest

    On Thu, 10 Apr 2008 22:42:00 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >Oh yeah...


    Get stuffed. If you want people to take time to explain things to
    you, get that chip off your shoulder.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #4
  5. Roedy Green

    Mirek Fidler Guest

    On Apr 11, 5:24 am, Roedy Green <>
    wrote:
    > On Thu, 10 Apr 2008 20:31:49 -0500, Razii
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    > >Creating 10000000 new objects with the keyword 'new' in tight loop.

    >
    > All Java has to do is add N (the size of the object) to a counter and
    > zero out the object.


    Does it mean Java allocator is serialized? Well, that would be a
    problem... Good C++ allocators are not locked for the fast path.

    > In C++ it also has to look for a hole the right
    > size and record it is some sort of collection.


    Which for the fast path is (or should be) equivalent of about 20 asm
    ops.

    What you basically need to do is to divide the size by "small
    quantum" (e.g. 16) to get the bucket type, then unlink single item
    from the bucket. Allocation finished.

    Mirek
     
    Mirek Fidler, Apr 12, 2008
    #5
  6. Mirek Fidler wrote:
    >
    > Does it mean Java allocator is serialized? Well, that would be a
    > problem... Good C++ allocators are not locked for the fast path.
    >


    (Ignoring for now that there isn't one Java allocator), typically there
    is a per thread area so these counters do not need locks.

    Mark Thornton
     
    Mark Thornton, Apr 12, 2008
    #6
  7. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 06:08:16 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >Java can use a multitude of allocation techniques.


    Yes, in theory, but since Java uses garbage collection which nearly
    always would imply it can later move objects, it can get away with a
    very simple, very rapid allocation algorithm, namely adding the length
    of the object to the free space pointer. In Java there are all kinds
    of short-lived objects created. It makes sense to allocate them as
    rapidly as possible.

    In C++, objects typically don't move, so the allocation algorithm has
    to take more care with where it places them.

    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #7
  8. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 10:16:24 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >
    >How does research hurt me, or anybody else?


    It is not what you are saying, but HOW you are saying it. You come
    across like a prosecutor crossed with a bratty five year old.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #8
  9. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 06:13:51 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >
    >AFAICT, in a sense, you don't what your talking about. Explain how you
    >synchronize with this counter? Are you going to stripe it? If so, at what
    >level of granularity? Java can use advanced memory allocation techniques.


    All I said was JVMs can for the usual case use an extremely fast
    simple memory allocation mechanism. They just peel the next N bytes
    off the free space pool. They don't have to search around for the
    right sized hole. GC/memory allocation is the subject an astounding
    amount of cleverness and creativity. I get people started on that
    exploration with my essay at
    http://mindprod.com/jgloss/garbagecollection.html

    I had no intention of claiming this was all there was to memory
    allocation or garbage collection.

    I am not on trial. So get stuffed.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #9
  10. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 10:12:46 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >> How many memory allocators have you written?

    >
    >These questions are meaningless and irrelevant.


    Several simple ones, but I have not written a Java JVM. I wrote BBL
    Forth which was twice as fast as the competition, so I am not a
    complete newbie.

    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #10
  11. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 10:18:12 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >Roedy! Not Reedy... CRAP!


    Don't worry. Nearly everyone gets it wrong. Even my mother sometimes
    called me "Roger".
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #11
  12. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 10:08:31 -0700, "Chris Thomasson"
    <> wrote, quoted or indirectly quoted someone who
    said :

    >to increment a pointer location off of common base memory.


    The initial discussion was about how Object.hashCode could be
    implemented. That COULD be done with a global counter. You would
    need simple synchronisation (e.g. an atomic memory increment)
    instruction to share it among threads.

    In a similar way you can do a fast object allocation simply by
    incrementing the free space pointer, either one per thread with
    separate pools or with a synchronised global one.

    The two discussions became muddled and intertwined. I think also there
    was confusion between what you might write IN Java vs assembler code
    inside the JVM to handle to low level details of object allocation.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #12
  13. Roedy Green

    Roedy Green Guest

    On Sat, 12 Apr 2008 13:31:12 GMT, Mark Thornton
    <> wrote, quoted or indirectly quoted
    someone who said :

    >(Ignoring for now that there isn't one Java allocator), typically there
    >is a per thread area so these counters do not need locks.


    Also consider the JVM does not have to use heavyweight Java-type
    object locks. It can get away with much more light-weight techniques.
    It can "cheat". This object allocation code has to be blindingly fast,
    and all sorts of techniques you would never dream of using in
    application code become legit.

    All you have to do is read one GC paper to see this IS rocket science.
    We can only scratch the surface in these discussions.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Apr 12, 2008
    #13
  14. Roedy Green wrote:
    > On Sat, 12 Apr 2008 13:31:12 GMT, Mark Thornton
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >> (Ignoring for now that there isn't one Java allocator), typically there
    >> is a per thread area so these counters do not need locks.

    >
    > Also consider the JVM does not have to use heavyweight Java-type
    > object locks. It can get away with much more light-weight techniques.
    > It can "cheat".


    JVM's often use highly optimised locking techniques even for regular
    objects (e.g. synchronized methods). In some cases they can even
    eliminate a lock altogether via escape analysis. This gets done even for
    a newbies code whereas a junior programmer trying to achieve similar
    locking performance in C++ is unwise at best. Even 10 years ago, JVMs
    adapted locking to suit the machine at run time (faster locking on
    single processors than multi cpu systems).

    Mark Thornton
     
    Mark Thornton, Apr 12, 2008
    #14
  15. Roedy Green

    Mirek Fidler Guest

    On Apr 13, 7:42 pm, "Chris Thomasson" <> wrote:

    OFFTOPIC: Chris, I have tried to send you an email concerning AppCore.
    Have you got it?

    Mirek
     
    Mirek Fidler, Apr 14, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arne Vajhøj
    Replies:
    12
    Views:
    810
  2. Ian Collins
    Replies:
    0
    Views:
    573
    Ian Collins
    Apr 11, 2008
  3. asterisc
    Replies:
    6
    Views:
    499
    Mark Space
    Apr 12, 2008
  4. Ian Collins
    Replies:
    2
    Views:
    548
    Matthias Buelow
    Apr 11, 2008
  5. Juha Nieminen
    Replies:
    10
    Views:
    583
    Mike Schilling
    Apr 13, 2008
Loading...

Share This Page