FAQ
Hi.

Here is minimal example: https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
I have channel that I sent to and receive from. One of the
senders\receivers uses select. And seems that each select creates a little
bit of a garbage.

marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
2014/10/17 20:59:31 profile: memory profiling enabled,
/tmp/profile883713528/mem.pprof
^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
--alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
Adjusting heap profiles for 1-in-4096 sampling rate
Welcome to pprof! For help, type 'help'.
(pprof) top
Total: 29161720 objects
22648298 77.7% 77.7% 22648298 77.7% newselect
  6513152 22.3% 100.0% 6513152 22.3% main.main
      256 0.0% 100.0% 256 0.0% runtime.mallocinit
       14 0.0% 100.0% 14 0.0% allocg
        0 0.0% 100.0% 270 0.0% _rt0_go
        0 0.0% 100.0% 22648298 77.7% main.loop
        0 0.0% 100.0% 14 0.0% mcommoninit
(pprof)

If I use channel of integers instead of channel of pointers to integers,
than this garbage is not being created.

Can someone explain what is happening here?

Marko.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Dmitry Vyukov at Oct 17, 2014 at 5:53 pm
    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So it
    does not produce load on GC, but allocations are significantly skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.


    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
    Hi.

    Here is minimal example: https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the senders\receivers
    uses select. And seems that each select creates a little bit of a garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marko at Oct 17, 2014 at 6:06 pm
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but does
    not produce load for GC?
    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov wrote:

    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So it
    does not produce load on GC, but allocations are significantly skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.


    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a garbage.
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Oct 18, 2014 at 3:33 pm
    There were few other cases, but they are not important (like freeing
    env var string during startup).
    In Go1.4 I've removed explicit free entirely, so now it's not even
    possible. Everything that's allocated produces load on GC.
    On Fri, Oct 17, 2014 at 10:06 PM, marko@kevac.org wrote:
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but does
    not produce load for GC?
    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov wrote:

    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So it
    does not produce load on GC, but allocations are significantly skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.


    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a
    garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marko at Oct 18, 2014 at 4:27 pm
    Can you please elaborate why is it better than explicit free? I can't see
    why GC load and pauses it makes is better.
    On Sat, Oct 18, 2014 at 7:33 PM, Dmitry Vyukov wrote:

    There were few other cases, but they are not important (like freeing
    env var string during startup).
    In Go1.4 I've removed explicit free entirely, so now it's not even
    possible. Everything that's allocated produces load on GC.
    On Fri, Oct 17, 2014 at 10:06 PM, marko@kevac.org wrote:
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but does
    not produce load for GC?
    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov wrote:

    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So it
    does not produce load on GC, but allocations are significantly skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.


    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a
    garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to
    integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?


    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Oct 18, 2014 at 4:34 pm

    On Sat, Oct 18, 2014 at 8:26 PM, marko@kevac.org wrote:
    Can you please elaborate why is it better than explicit free? I can't see
    why GC load and pauses it makes is better.
    Select descriptors are not allocated on stack, which is even faster
    and does not produce GC load. Everything else was not important
    performance-wise.


    On Sat, Oct 18, 2014 at 7:33 PM, Dmitry Vyukov wrote:

    There were few other cases, but they are not important (like freeing
    env var string during startup).
    In Go1.4 I've removed explicit free entirely, so now it's not even
    possible. Everything that's allocated produces load on GC.
    On Fri, Oct 17, 2014 at 10:06 PM, marko@kevac.org wrote:
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but
    does
    not produce load for GC?

    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So it
    does not produce load on GC, but allocations are significantly skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.


    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a
    garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to
    integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ugorji Nwoke at Oct 18, 2014 at 4:56 pm
    Did you mean to say: select descriptors are *now* allocated on stack???
    On Saturday, October 18, 2014 12:34:33 PM UTC-4, Dmitry Vyukov wrote:

    On Sat, Oct 18, 2014 at 8:26 PM, ma...@kevac.org <javascript:> <
    ma...@kevac.org <javascript:>> wrote:
    Can you please elaborate why is it better than explicit free? I can't see
    why GC load and pauses it makes is better.
    Select descriptors are not allocated on stack, which is even faster
    and does not produce GC load. Everything else was not important
    performance-wise.


    On Sat, Oct 18, 2014 at 7:33 PM, Dmitry Vyukov <dvy...@google.com
    <javascript:>> wrote:
    There were few other cases, but they are not important (like freeing
    env var string during startup).
    In Go1.4 I've removed explicit free entirely, so now it's not even
    possible. Everything that's allocated produces load on GC.

    On Fri, Oct 17, 2014 at 10:06 PM, ma...@kevac.org <javascript:> <
    ma...@kevac.org <javascript:>> wrote:
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but
    does
    not produce load for GC?

    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov <dvy...@google.com
    <javascript:>>
    wrote:
    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So
    it
    does not produce load on GC, but allocations are significantly
    skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.



    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac <ma...@kevac.org
    <javascript:>> wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a
    garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool
    pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to
    integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Oct 18, 2014 at 5:03 pm
    yes, sorry
    select descriptors are *now* allocated on stack
    On Sat, Oct 18, 2014 at 8:56 PM, Ugorji Nwoke wrote:
    Did you mean to say: select descriptors are *now* allocated on stack???
    On Saturday, October 18, 2014 12:34:33 PM UTC-4, Dmitry Vyukov wrote:
    On Sat, Oct 18, 2014 at 8:26 PM, ma...@kevac.org wrote:
    Can you please elaborate why is it better than explicit free? I can't
    see
    why GC load and pauses it makes is better.
    Select descriptors are not allocated on stack, which is even faster
    and does not produce GC load. Everything else was not important
    performance-wise.


    On Sat, Oct 18, 2014 at 7:33 PM, Dmitry Vyukov <dvy...@google.com>
    wrote:
    There were few other cases, but they are not important (like freeing
    env var string during startup).
    In Go1.4 I've removed explicit free entirely, so now it's not even
    possible. Everything that's allocated produces load on GC.

    On Fri, Oct 17, 2014 at 10:06 PM, ma...@kevac.org <ma...@kevac.org>
    wrote:
    Thank you, Dmitry.

    Is it the only case when allocation is showed in memory profiler, but
    does
    not produce load for GC?

    On Fri, Oct 17, 2014 at 9:53 PM, Dmitry Vyukov <dvy...@google.com>
    wrote:
    It creates *allocations*, not garbage.
    And, yes, it is misleading.
    Select uses explicit freeing of memory rather than relies on GC. So
    it
    does not produce load on GC, but allocations are significantly
    skewed
    towards select.
    I've fixed it in Go1.4. Select won't cause allocations anymore.



    On Fri, Oct 17, 2014 at 9:46 PM, Marko Kevac <ma...@kevac.org>
    wrote:
    Hi.

    Here is minimal example:
    https://gist.github.com/mkevac/2006f7fa8be38fb1ee00
    I have channel that I sent to and receive from. One of the
    senders\receivers
    uses select. And seems that each select creates a little bit of a
    garbage.

    marko@fedora-server:~/goprojects/src/badoo/heaptest $ ./heaptest
    2014/10/17 20:59:31 profile: memory profiling enabled,
    /tmp/profile883713528/mem.pprof
    ^C2014/10/17 20:59:40 profile: caught interrupt, stopping profiles
    marko@fedora-server:~/goprojects/src/badoo/heaptest $ go tool
    pprof
    --alloc_objects ./heaptest /tmp/profile883713528/mem.pprof
    Adjusting heap profiles for 1-in-4096 sampling rate
    Welcome to pprof! For help, type 'help'.
    (pprof) top
    Total: 29161720 objects
    22648298 77.7% 77.7% 22648298 77.7% newselect
    6513152 22.3% 100.0% 6513152 22.3% main.main
    256 0.0% 100.0% 256 0.0% runtime.mallocinit
    14 0.0% 100.0% 14 0.0% allocg
    0 0.0% 100.0% 270 0.0% _rt0_go
    0 0.0% 100.0% 22648298 77.7% main.loop
    0 0.0% 100.0% 14 0.0% mcommoninit
    (pprof)

    If I use channel of integers instead of channel of pointers to
    integers,
    than this garbage is not being created.

    Can someone explain what is happening here?

    Marko.

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?



    --
    A. Because it breaks the logical sequence of discussion
    Q. Why is top posting bad?
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 17, '14 at 5:46p
activeOct 18, '14 at 5:03p
posts8
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase