This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: GCJ's URLClassloader and 'core' protocol
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "'tromey at redhat dot com'" <tromey at redhat dot com>,gnustuff at thisiscool dot com
- Cc: Sal <gcj at svf dot dreamhost dot com>, Andrew Haley <aph at redhat dot com>,java at gcc dot gnu dot org
- Date: Tue, 29 Jun 2004 11:10:22 -0700
- Subject: RE: GCJ's URLClassloader and 'core' protocol
I'm not sure there is still a GC issue with the dll. Once upon a time
we had a problem with needing structured exception handling in the marker
in that case. But Ranjit contributed in-line assembly code to do that
with gcc a long time ago.
Independent of that, it would be good to either have explicit root
registration, or a way to reliably avoid tracing from the frame buffer on
Windows.
Hans
> -----Original Message-----
> From: java-owner@gcc.gnu.org
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Tom Tromey
> Sent: Monday, June 28, 2004 5:53 PM
> To: gnustuff@thisiscool.com
> Cc: Sal; Andrew Haley; java@gcc.gnu.org
> Subject: Re: GCJ's URLClassloader and 'core' protocol
>
>
> >>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:
>
> Mohan> That approach won't currently work on Windows.
>
> IMO we really need someone to fix things so we can build a .dll on
> Windows. For the GC parts, this may also imply tightening CNI a bit
> so that roots must be explicitly registered (or whatever, see the many
> discussions on this topic). There's just no way we're going to make
> static linking work reliably, it is too far from the java model, IMO.
>
> Mohan> Here's a hare-brained brainstorm which might not be based in
> Mohan> reality - I don't know whether this will work in real life:
> Mohan> - compile the classe(s) in question into .class files
> Mohan> - compile the .class files into the executable as
> Mohan> <i>resources</i> rather than executable code
>
> Yes, I think this will work just fine. I haven't tried this but it
> shouldn't require any changes to libgcj at all.
>
> Tom
>