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?
--
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]
