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 <[EMAIL PROTECTED]>:
2006/9/13, Pavel Pervov <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> wrote:
>
> > 2006/9/11, Weldon Washburn <[EMAIL PROTECTED]>:
> > > On 9/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > 2006/9/10, Pavel Pervov <[EMAIL PROTECTED]>:
> > > > > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
