harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Mon, 11 Sep 2006 15:23:11 GMT
On 9/10/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> 2006/9/10, Pavel Pervov <pmcfirst@gmail.com>:
> > 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 <weldonwjw@gmail.com> 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 <pmcfirst@gmail.com> 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 <pmcfirst@gmail.com> 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 <geir@pobox.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Pavel Pervov wrote:
> > > > > > > On 7/24/06, Alexey Petrenko < alexey.a.petrenko@gmail.com>
> wrote:
> > > > > > >>
> > > > > > >> 2006/7/24, Pavel Pervov <pmcfirst@gmail.com>:
> > > > > >
> > > > > > >> > 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:
> harmony-dev-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail:
> > > harmony-dev-help@incubator.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > > Intel Middleware Products Division
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message