2006/9/14, Pavel Pervov <[EMAIL PROTECTED]>:
>
> > > For example, private members of Method _parse_exceptions()
> > > _parse_local_vars(), _parse_line_numbers(), _parse_code() actually
> > > should be public members of respective entities.
> >
> > They should not. Nobody but Method knows nothing about local variable
> tables
> > and line numbers stored in it. It is again breaking incapsulation.
> Nope. Those attributes are self-contained entities on their own, so
> have to be incapsulated accordingly. So there is Handler class (which
> abstracts Method-specific attribute), and should be other which I
> mentioned above. This is more of consistency matter, dont' you agree?
Ah, now I see what you are at. Yes, if want full OOP in class support, then
you are right. And we probably do want that. :)
>
> > Those entities in
> > > turn need not be declared in Class.h, as Method incapsulates pointers
> > > to such members.
> >
> > Yes, they may be declared inside class Method.
> Yes, they may. Currently some of them are declared inside of Method,
> some aren't. Maybe it sounds weird at first, but we would improve
> modularity if all those items are outside of Method class:
>
> <file Method.h>
> class LocVarTable;
> class Method {
> public:
> int get_line_number(uint16 bc);
> private:
> LocVarTable* _table;
> }
> </file Method.h>
They should not only be outside class Method, but outside a header file
where class Method is declared to improve modularity of compilation you are
striving to achieve (AFAIU your original intention). Otherwise, it is the
issue of clear code design.
And outside of public API of vmcore altogether - that is the point.
Sorry if I didn't expressed it clearly enough. The details of class
file structure are internal to class_support and should not be
exposed, to keep public interface of the module clear and consice.
Good design is always practical thing, its effectiveness is the prime
measure of success. Effectiveness here means all of the convenience to
understand, use, compile, etc.
My feeling is that we aim the same approach but think of it in
different words, so the arguing. Maybe speak in patches will ease
communications ;)
OK, looking forward to see your major plan realized.
--
WBR,
Alexey
>
> > > 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?
> > This approach may be used in struct Class for array classes. Not sure
> one
> > level of indirection in memory access is worth saved memory. I'm afraid
> we
> > won't save more than 1MB of memory with this trick, but surely will have
> > performance penalty.
> Let's not guess - hopefully we can estimate this. For this particular
> example, how much interfaces/abstract classes do we have on typical
> Eclipse scenario, and how often particular Method members are
> accessed? I will try to get these numbers.
I only know the statistics on a number of classes loaded - as I mentioned it
earlier, ~3K. So, I'm dying to see exact numbers. You know my estimation,
let's see how big is the dirrerence. :)
> > 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.
> > Yes, this is absolutely another story. I would not advise using C++
> > exceptions in VM. We'll have all sorts of compatibility problems and,
> also,
> > performance degradation, if we start to.
> I heard this view on C++ exceptions from time to time, but did not
> have a chance to verify it on practice ;). And not in the near future,
> probably...
"I've heard it all before..."
There is THE difference in how C++ exceptions are implemented in different
compilers. There are even differences in different versions of GCC. So, from
my POV it is not worth trying until you have nothing to do at all and
everything else works seamlessly.
Best regards,
Pavel.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
