harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Thu, 14 Sep 2006 11:44:52 GMT
Alexey,

It is still alive and very active. :) But I'd rather wait until 1363 applied
before making any moves in that direction.

Regards,
    Pavel.

On 9/14/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message