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 Sun, 10 Sep 2006 19:55:38 GMT
Pavel,

I would first like to see a patch that removes all the unused variables and
cleans up comments.  Once this is committed, it makes sense address the
other items you mention.

Regarding C++.   I would suggest looking at doing as much as possible in
Java instead of C++.  Vmmagic is mostly functional in Jitrino.JET.  Vmmagic
is very useful to read/write C structs from Java.


On 9/10/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
>
> 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.
>
> 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
> >
> >
>
>


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