harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Cleaning insides of Class.h header
Date Thu, 14 Sep 2006 15:46:23 GMT
On 9/14/06, Pavel Pervov <pmcfirst@gmail.com> wrote:

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


The inclusion of external header files in GC is a continual battle.  From a
modularity standpoint, the external header files need to be excluded.
During GC debug its often useful to access class name, subclass name, etc.
What really needs to happen is class.h accessors need to be created.


> 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 agree.  No C++ exceptions.  We already have java exceptions, OS/HW
exceptions as well as debug exceptions running up and down the stack.  C++
adds too much complextity.

Best regards,
>      Pavel.
> <SNIP>
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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