Re: Memory / CPU requirements
79 views
Skip to first unread message
Gernot Kvas
Jun 26, 2012, 4:11:19 AM6/26/12
to Avian
On 25 Jun., 22:36, Gernot Kvas <gernot.k...@gmail.com> wrote:
> Out of interest: I've yet to dig through the source code, but what garbage
> collection algorithm is being used for Avian?
I better answer that myself: I read over the "Generational, copying
garbage collection ensures short pause times and good spatial
locality" bit on the "About" page.
Does that translate into a classical from-/to-space division of the
total heap with only have the memory being available for the heap?
Cheers,
Gernot
> Out of interest: I've yet to dig through the source code, but what garbage
> collection algorithm is being used for Avian?
I better answer that myself: I read over the "Generational, copying
garbage collection ensures short pause times and good spatial
locality" bit on the "About" page.
Does that translate into a classical from-/to-space division of the
total heap with only have the memory being available for the heap?
Cheers,
Gernot
Joel Dice
Jun 26, 2012, 10:20:04 AM6/26/12
to av...@googlegroups.com, gerno...@gmail.com
On Mon, 25 Jun 2012, Gernot Kvas wrote:
> I'm toying with the idea of putting Avian on a rather low-end embedded ARM
> device (ARM9 500 MHz) and I'm not really sure whether that is feasible. What
> would be the minimum requirements for Avian in terms of processor, footprint
> and memory consumption (VM + Avian class library, not OpenJDK)?
That depends on the application. A big, complicated application will
obviously require more memory than a simple "hello, world" example.
Likewise, an app that needs to do a lot of CPU-intensive calculation might
struggle on a low-end CPU. The only way to know if Avian is suitable for
your app is to try it. You might be able to get away with just 16 MB of
RAM and a 100 MHz processor if your needs are modest.
> Out of interest: I've yet to dig through the source code, but what garbage
> collection algorithm is being used for Avian?
It's a hybrid copying and mark/sweep collector, where small objects whose
addresses are allowed to changed are copied at GC time, while large
objects and those whose addresses may not change are subject to the
mark/sweep process. In both cases, the algorithm is generational, meaning
long-lived objects are visited only in relatively rare "major"
collections, while young ones are visited in both "major" and "minor"
collections. Finally, it's a stop-the-world collector, meaning a thread
which needs to collect must signal and wait for all other VM threads to
stop before it can start collecting.
> I'm toying with the idea of putting Avian on a rather low-end embedded ARM
> device (ARM9 500 MHz) and I'm not really sure whether that is feasible. What
> would be the minimum requirements for Avian in terms of processor, footprint
> and memory consumption (VM + Avian class library, not OpenJDK)?
That depends on the application. A big, complicated application will
obviously require more memory than a simple "hello, world" example.
Likewise, an app that needs to do a lot of CPU-intensive calculation might
struggle on a low-end CPU. The only way to know if Avian is suitable for
your app is to try it. You might be able to get away with just 16 MB of
RAM and a 100 MHz processor if your needs are modest.
> Out of interest: I've yet to dig through the source code, but what garbage
> collection algorithm is being used for Avian?
addresses are allowed to changed are copied at GC time, while large
objects and those whose addresses may not change are subject to the
mark/sweep process. In both cases, the algorithm is generational, meaning
long-lived objects are visited only in relatively rare "major"
collections, while young ones are visited in both "major" and "minor"
collections. Finally, it's a stop-the-world collector, meaning a thread
which needs to collect must signal and wait for all other VM threads to
stop before it can start collecting.
Reply all
Reply to author
Forward
0 new messages