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 Thu, 14 Sep 2006 04:50:50 GMT
Pavel,

What happened with your initial plan (cited below)? I suggest you
proceed with it, I may postpone more local activities until you've
done the major part.

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


2006/9/14, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> 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