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 <[EMAIL PROTECTED]> 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 <[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]
