Pavel, I would first like to see a patch that removes all the unused variables and cleans up comments. Once this is committed, it makes sense address the other items you mention.
Regarding C++. I would suggest looking at doing as much as possible in Java instead of C++. Vmmagic is mostly functional in Jitrino.JET. Vmmagic is very useful to read/write C structs from Java. On 9/10/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
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. On 9/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Pavel, > In general I like the idea of cleaning up this code. Maybe the best thing > to do is post some patches so that we have examples to discuss. > Weldon > > On 9/5/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > > It's been long time this discussion stopped. > > This may mean three things: > > - first, everyone agrees this should be done and I'm ok to provide > > consecutive patches; > > - second, noone clearly understand the purpose of what is suggested to > do; > > if this is the case, do not hesitate to ask (again?); > > - third, noone is really interested in making source code of DRLVM more > > readable and more understandable, and I should drop this activity. > > > > Meanwhile, I'd like to open jira and start posting patches there. > > > > Regards, > > Pavel. > > > > On 7/25/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > > > > > Geir, > > > > > > well, it is the argument at least for me to start thinking in this > > > direction and initiate this discussion. > > > > > > And there are places in VM core code where only definition of members > of > > a > > > class is required, but whole Class.h is included anyway. This is also > > > about localizing potential development in separate functional groups > to > > > reduce recompilation when working intensively with these files. > > > > > > Hope, I answered, what you were asking about. :) > > > > > > Regards, > > > Pavel. > > > > > > On 7/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Pavel Pervov wrote: > > > > > On 7/24/06, Alexey Petrenko < [EMAIL PROTECTED]> wrote: > > > > >> > > > > >> 2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>: > > > > > > > > >> > 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) > > > > >> > > > > >> Will these header files be useful separately? > > > > > > > > > > > > > > > Yes, sure, they will be. This is one of the arguments for doing > so. > > > > > > > > > > > > > > > > > To whom? > > > > > > > > geir > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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 > >
-- Weldon Washburn Intel Middleware Products Division
