On 9/14/06, Pavel Pervov <[EMAIL PROTECTED]> 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
