This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
> Could you remind me what your platform is?It's my embedded 133 Mhz PPC405EP - so it's nothing like the pc analogies you mention ;-(
> For a modern PC, with a heap size of 8MB, and assuming the root size isSo, yes it's a slow processor, I guess... And there is no paging, no.
> reasonable, 60 msecs should be on the high side. (The GC time should be
> roughly proportional to <live data size> + <root size>. On a GC_Bench
> variant, the marker seems to scan roughly 200-250MB/sec on a single 2
> GHz P4 Xeon. There is a bit of other overhead associated with
> collections, but that's the lion's share.)
> > Unless you're on a very slow processor, the 360msecs seems anomalous to
> me. It would be useful to understand what's going on during that time.
> Presumably paging is not an issue?
Bummer! :-)> More generally, the GC provides some support for incremental collection, > but AFAIK that's not really supported by gcj, and hence may take some > effort to get to work for your application.
But, since I've seen gc-times of 60 msecs for a simple test-example, I guess the root-set scanning-time is below (~equal to) this time, and similar regardless the other application?! If this is the case, the remainder 300 msecs is <live data size>...With gcj our root set is way, way too big. Fixing this is at the top of my list of things to fix.
Best regards, Martin Egholm
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |