Alexey, I agree with what Pavel Pervov says below. In looking at the code in vmcore/src/class_support, creating another class adds another layer of complexity and will make removal of unnecessary code more difficult. C++ "friends" should be used very sparingly. Can you try Pavel's suggestion below as a first step? - Weldon
On 9/13/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Not sure C++ "friend"s are good design. 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. If something should be improved, ByteReader can be extended to provide more advanced "format extraction" methods than it has now. Treat the above as "I object". :) If you see some design issues in current class parsing code, please, fill free to share. 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] > >
-- Weldon Washburn Intel Middleware Products Division
