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 Wed, 13 Sep 2006 16:21:01 GMT
Alexey,
I agree with what Pavel Pervov says below.  In looking at the code in
vmcore/src/class_support, creating another class adds another layer of
complexity and will make removal of unnecessary code more difficult.  C++
"friends" should be used very sparingly.  Can you try Pavel's suggestion
below as a first step?
  - Weldon


On 9/13/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
>
> Not sure C++ "friend"s are good design. Although class format is something
> one might want to localize to be known to only one entity (like
> ClassFileParser), it is much better to provide "format extractor" to
> anybody
> interested in its use and let them manage their content by themselves.
> This
> is how current implementation is designed. If something should be
> improved, ByteReader can be extended to provide more advanced "format
> extraction" methods than it has now.
>
> Treat the above as "I object". :)
>
> If you see some design issues in current class parsing code, please, fill
> free to share.
>
> Best regards,
>    Pavel.
> On 9/13/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> > 2006/9/11, Weldon Washburn <weldonwjw@gmail.com>:
> > > 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.
> > >
> >
> > As the very first step, I volunteer to extract items related to
> > class-file parsing. The idea is to move methods like
> > Class_Member::parseXXX() to a new ClassFileParser class and declare
> > this class a friend of Class_Member's descendants. This way we'll
> > isolate CFF parsing utilities from ordinary user interface of Class &
> > members.
> > I will proceed if nobody objects.
> >
> > --
> > Alexey
> >
> > [snip]
> >
> > ---------------------------------------------------------------------
> > 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