> > As for possible solutions? The quick and dirty way > > would be to just bound the pool sizes to some > > reasonable limit. The best solution would be to fix > > the jitter since the peak usage is still ginormous. > > Does the jitter really need all of that data > (labels/const/seq objects) after it has finished > dealing with a method? I'd think a quick & dirty > solution would be to just "free" the object pools once > the jitter is done with them.
Exactly, they're kept in a pool as an "optimization". Although I don't know how much time is actually saved by doing this instead of just malloc'ing and free'ing them all. > Nevertheless, that wouldn't take care of peek usage. > Where should we start fixing it? I have only browsed > that code so far, and found your docs for janosvm > quite helpful ... I think the main problem in this case is that the jitter isn't optimizing away the array bounds checks. Looking at the pocketlinux code i think they've already done most/all of this so it would be just a matter of rolling their changes back in... > cheers, > > dalibor topic tim stack _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
