harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Wed, 13 Sep 2006 17:27:40 GMT
2006/9/13, Pavel Pervov <pmcfirst@gmail.com>:
> Not sure C++ "friend"s are good design.
Umm, what is wrong with friends?

> 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.
Both approaches have pros &cons, very good example in Java are
Serializable and Externalizable alternatives. Conceptually I have no
strong preference for our case. OK, we can choose the current design
for minimal disruption, then should follow it more  consistently. For
example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers(), _parse_code() actually
should be public members of respective entities. Those entities in
turn need not be declared in Class.h, as Method incapsulates pointers
to such members.
BTW, this would also allow us to economize on size of Method
instances, after we sort out such entities - e.g. instead of keeping
bunch of Code-related members (~10 members) directly, store just 1
pointer and win memory on absract and interface methods, etc. Of
course care should be taken to not incur performance penalty for extra
indirection, but you see the approach.
What do you think?

>  If something should be
> improved, ByteReader can be extended to provide more advanced "format
> extraction" methods than it has now.
I don't think so - if we follow the selected approach consistently,
ByteReader hardly needs to provide more... Please correct me if you
have concrete ideas.

> Treat the above as "I object". :)
> If you see some design issues in current class parsing code, please, fill
> free to share.
The problem is not parsing code itself, you know - just when someone
does a trivial fix in LocalVarTable parsing procedure, I have to
recompile the whole VM + GC (and maybe even JIT)! Where are you, vm
modularity ;)

Well, for the parsing code - I do not appreciate that JNI-like coding
pattern "If (troubles) {RAISE_FAILURE(); return false;}" used
everywhere in Class_File_Loader.cpp, would prefer using exceptions -
but that is another story.

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

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


Mime
View raw message