Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of weldonwjw@gmail.com
 designates 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=C8ypvTBL8y65VAK4eUm456XD81MlhF9gH17uG/1X7G7SP0ZYmg+UzvYvBN/ZCG4ubFP8YU5zpNLj85akznmyFByc8aMOEWq41h9aa6K82WaJaVURi4e7jnlDrH/U1XyysG06RJgLrQXmqq8bXHqOmTZEBC+sgXCms0qr7eod670=
Message-ID: <4dd1f3f00609130921h53a01972w588a84c4d3bd94c5@mail.gmail.com>
Date: Wed, 13 Sep 2006 09:21:01 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Cleaning insides of Class.h header
In-Reply-To: <e0f125db0609130725v305b1d09xa4adfc9c9d0382bd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_124198_26938864.1158164461807"
References: <e0f125db0607240324w15fba97bj3f1573826b3b27fb@mail.gmail.com>
	 <44C4E656.4050101@pobox.com>
	 <e0f125db0607250208i26bcbd61h331410fc06f6ddc6@mail.gmail.com>
	 <e0f125db0609050325v75420bb0i7b3cdb0bcbf087d8@mail.gmail.com>
	 <4dd1f3f00609062031n57ff664ck976e424628ca65f5@mail.gmail.com>
	 <e0f125db0609100211s36549501j4a7dcae27c70b39e@mail.gmail.com>
	 <f944d83d0609102325s30e3c257h84dba52bdcddb614@mail.gmail.com>
	 <4dd1f3f00609110823l15a186a4rf82ee6ec9a8c22c2@mail.gmail.com>
	 <f944d83d0609130710w77edda98g480115620221d3d1@mail.gmail.com>
	 <e0f125db0609130725v305b1d09xa4adfc9c9d0382bd@mail.gmail.com>

------=_Part_124198_26938864.1158164461807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_124198_26938864.1158164461807--