On 9/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/9/10, Pavel Pervov <[EMAIL PROTECTED]>: > Weldon, > > one of good examples is static_method_block member variable of struct Class. > Its size if calculated, memory is allocated for it, but it is never used > throughout the code. Roughly 3K classes loaded in simple Eclipse usage > scenario (open Eclipse, create "hello, world" application, run it, exit > Eclipse), which means 3K useless memory allocations are made during this > simple run. Heap is fragmented and Visual C runtime has locking on each > memory allocation. > > Regards, > Pavel. Pavel, I believe the first step should be re-structuring of this ubiquitous and huge (~1800 lines!) header to several more dedicated ones, and regrouping of other related headers, like class_interface.h and classloader.h. Then we can go with reduction of possible duplicates in interfaces, and optimizing structures layouts and memory usage. What do you think?
This works also! In any case, please attempt to break the work into several stages. --
Regards, Alexey > > On 9/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > Pavel, > > In general I like the idea of cleaning up this code. Maybe the best thing > > to do is post some patches so that we have examples to discuss. > > Weldon > > > > On 9/5/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > > > > It's been long time this discussion stopped. > > > This may mean three things: > > > - first, everyone agrees this should be done and I'm ok to provide > > > consecutive patches; > > > - second, noone clearly understand the purpose of what is suggested to > > do; > > > if this is the case, do not hesitate to ask (again?); > > > - third, noone is really interested in making source code of DRLVM more > > > readable and more understandable, and I should drop this activity. > > > > > > Meanwhile, I'd like to open jira and start posting patches there. > > > > > > Regards, > > > Pavel. > > > > > > On 7/25/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > > > > > > Geir, > > > > > > > > well, it is the argument at least for me to start thinking in this > > > > direction and initiate this discussion. > > > > > > > > And there are places in VM core code where only definition of members > > of > > > a > > > > class is required, but whole Class.h is included anyway. This is also > > > > about localizing potential development in separate functional groups > > to > > > > reduce recompilation when working intensively with these files. > > > > > > > > Hope, I answered, what you were asking about. :) > > > > > > > > Regards, > > > > Pavel. > > > > > > > > On 7/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > Pavel Pervov wrote: > > > > > > On 7/24/06, Alexey Petrenko < [EMAIL PROTECTED]> wrote: > > > > > >> > > > > > >> 2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>: > > > > > > > > > > >> > First thing I would like to do is to split the file into a > > group > > > of > > > > > > > > > > >> files, > > > > > >> > each of which would contain only one entity (and some closely > > > > > related > > > > > >> > entities, if any). This would produce the following headers: > > > > > >> > 1) Class.h – constant pool and class > > > > > >> > 2) vtable.h – vtable > > > > > >> > 3) class_member.h – field and method entities > > descriptors, > > > > > >> exception > > > > > >> > handler descriptor > > > > > >> > 4) cci.h – code chunk entity (part of compiled method > > code) > > > > > >> > > > > > >> Will these header files be useful separately? > > > > > > > > > > > > > > > > > > Yes, sure, they will be. This is one of the arguments for doing > > so. > > > > > > > > > > > > > > > > > > > > > To whom? > > > > > > > > > > geir > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Weldon Washburn > > Intel Middleware Products Division > > > > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
