gcj CNI

[dc0d32]

hi.

(this thread aims more towards linguistic features, i think this is it's right place)

in one line:
can someone please explain how to deal with exceptions in the CNI code generated by gcj? also how to handle classes, methods, virtual calls, interfaces etc.


i am just giving it a try. just hacking around. i just want to see if it is possible to develop a small tiny kernel in java (er.. well, most of it ), compiled in native form so that the overheads and problems of having a JIT in kernel are eliminated.

this is what i've done till now...
   -wrote VERY basic java library (java.lang.Object, Class, String, Exception etc.)
   -made classes out of these java files.
   -generated headers out of those classes using gcjh
   -compiled the java files to native code using gcj -c
   i have picked up some vital function signatures from the gcj and libgcj sources like _Jv_InitClass, which can be implemented when i get the structures in which the class information is stored. (the C++ support code is also compiled using Java style exception support, so that no conflicts arise when linking this support.o with ./java/lang/Object.o etc.)

i went through libgcj sources looking for exception handling support code, but the EH code is too cryptic to cleanly understand the logic behind [or maybe i'm dumb]. googling also didnt help. they seem to have given the general idea, but no hardcore details i could get.

i know nothing about the .eh_frame n stuff. also nothing about stack unwinding basics as done in gcc, in short the entire EH model of gcc. Can someone please explain that in detail, helping me to understand and possibly implement or copy from gcc sources.

what is the structure of things like for class information stored in this case? also the eh structures and vtables etc. I've got the basic structure/working, but if anyone can point me to the correct c/c++ 'structure' or 'class' for these data structures, that will save time.

i think the logic of loading a class, finding out a method from a specific class, resolving virtual method calls should be the same as it is done in JVMs which load a .class file (which are ELF files in my case, i think the metadata structure should be similar though).


please help me.
any help is welcome.

[mystran]

If I'm not mistaken, gcj does the same thing with Java exceptions that g++ does with C++ exceptions (and by design for C++/Java interop). So I think it might be helpful to look at OSFAQ for info about C++ exception handling.

edit: I hope you have some idea how you are going to handle garbage collection. You need that for Java even with native code.

[dc0d32]

i heard that there are smoe minor differences in the EH done by g++ and gcj. but as i am using gcj style exceptions in C++ code too, there should not be any problem in doing only a single support.

and yes, i do need to do GC in native code too. but that part comes later for me. just to start off, these things are only necessary, and i mean GC is not _the_ immediate concern for me right now. i am more concerned about handling classes, functions, exceptions,. just to get the basic code up and running.

[dc0d32]

suddenly i have started to think differently. why not port gcj and libgcj (well, atleast some basic subset of it) itself? it is quite easy do design HAL in C++, and most of the code will be picked up from my main kernel. then i'll provide __VERY__ basic operations in the C++ kernel which libgcj and gcj itself run on. (btw, what minimal set of rutime support should be programmed?).
here a question arises, do i libgcj that from the HAL code, i mean libgcj will then run the main java kernel.
or
what if i link the java compiled code with tweaked/reduced libgcj? obviously with trivial HAL support.

the main reason i think i started thinking about this alternative is the thought 'why reinvent the wheel?'. it is there, why not use it, rather than code it all by myself.