harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Thu, 14 Sep 2006 14:01:17 GMT
2006/9/14, Pavel Pervov <pmcfirst@gmail.com>:
> >
> > 2006/9/13, Pavel Pervov <pmcfirst@gmail.com>:
> > > Not sure C++ "friend"s are good design.
> > Umm, what is wrong with friends?
> It's sort of breaking incapsulation ideology. Nothing more. :)
> <SNIP>
> > 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?
>  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 {
int get_line_number(uint16 bc);
LocVarTable* _table;
</file Method.h>

For the header above, any user of Method  API is not aware of
LocVarTable design or impl peculiarities, we are free to change it any
way we like - we may only need to recompile Method implementation.

> > 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.

> >  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.
> Yes, you are right here. I looked through ByteReader and found nothing to
> improve.
> > 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 ;)
> No, you don't. If someone change "LocalVarTable parsing procedure" you only
> need to recompile Class_File_Loader.cpp. ;)
> But if that one happen to change something in Class.h, you'll recompile 97
> files in VM. Recompilation of GCV4 is due to erroneous direct  inclusion of
> Class.h into some of GCV4 headers. GCV41 does not have this peculiarity.
> > 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,

> Best regards,
>      Pavel.
> <SNIP>

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message