harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Thu, 14 Sep 2006 11:42:44 GMT
> 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. :)


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

 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.

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

>  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

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

Best regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message