This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Sal writes:
> Andrew Haley wrote:
> > > There's no code to allow a jarfile to be separately compiled to a .so
> > and loaded automagically, though. It's quite tricky to figure out how
> > to do it.
> > This is one of the things I would like to get to work, once an elegant > solution is found. In a way its a simpler issue in that the code is > already compiled, we just need a way to tell gcj to grab a hold of it > from within a custom classloader.
Tom Tromey suggested that we should create a database of mappings from checksum->shared object. So, ClassLoader.defineClass() generates a checksum and then finds the appropriate shared library and loads it. Most times, the shared library will already be loaded, so it's only necessary to return a pointer to th class. The other tool we need is one that compiles the jar file and creates the database of mappings.
Another approach that bypasses the checksumming is to attach an attribute to a jarfile that points to a shared object file that is the compiled jarfile. I'm not quite sure what form that attribute would take, but JFFS2 has xattr().
> A variation of the issue I'm having, is when the compiled code already > exists but is statically linked into my executable. Everything works > great, and I can even use Class.forName() to grab the object. But my > CCLs are unable to pull this object out, nor load it from the disk > because it is combined into the executable. Do you have any insight on > how I may be able get around this?
I don't really know where the problem lies. If your custom class loader inherits from VMClassLoader, when it calls LoadClass it will do the right thing.
> An ugly hack I can think of would be to have defineClass return some > custom data, such that it doesn't define a class with VM bytecode, but > returns some string that references a native object > (ugly_native_hack://foo.bar.classname). We'de have to bypass any > standard bytecode verification in these special cases and pull that > statically linked image out of storage instead. (Of course this is just > speculation, I don't know enough about GCJ architecture to say it would > be possible.) Has this already been accounted for in some design work > previously?
This doesn't sound like the right thing to do.
> A third solution might be to have some eternal override. Maybe a > directory with SOs or a configuration file that will list objects. Any > objects in this list, when referenced via defineClass will 'thunk' down > to use a staticly compiled version, or a native .so regardless of what > data the application is trying to define the class with.
Yeah, that's more or less Tromey's idea. That's what we'll go with, I expect.
> I'll start digging through code. GCC is still a bit daunting as I'm new > to it, so it may take a little while before I'll be able to > contribute... if you know of some reading offhand (online or off) to > bring me up to speed that would be great.
Don't worry about the compiler. The library (gcc/libjava) is mostly Java code.
BTW, there are some legal niceties that we'll need to talk about before you contribute anything.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |