Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of pmcfirst@gmail.com designates
 64.233.166.179 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=Icj4RCiaIQlQ/Lv6GDp6WE8sSdpeUDssw5yUe6dPZj7E1Vy+ATn0LCpMILUv0I3KOSfIKjqmXf+1pK8acKjcAFBNgomuneytbgbX3xX+5+5/DZcQCfqbLshnhenAgH9PbOgFWK3RX9Ih+HVfFmqdHTEsPF0JTqsIdBckfA89Dcg=
Message-ID: <e0f125db0609130725v305b1d09xa4adfc9c9d0382bd@mail.gmail.com>
Date: Wed, 13 Sep 2006 18:25:37 +0400
From: "Pavel Pervov" <pmcfirst@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Cleaning insides of Class.h header
In-Reply-To: <f944d83d0609130710w77edda98g480115620221d3d1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9081_11247175.1158157537974"
References: <e0f125db0607240324w15fba97bj3f1573826b3b27fb@mail.gmail.com>
	 <e0f125db0607240402w28067574n28f7aab45f07e833@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>

------=_Part_9081_11247175.1158157537974
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_9081_11247175.1158157537974--