[Gc] Simple boehm fix

[Ivan Maidanski]

Some time ago I submitted a patch to refactor gcc boehmgc api to match that of gc7.6 (
https://gcc.gnu.org/ml/java-patches/2016-q2/msg00019.html) to make boehmgc merge with upstream just a simple replacement of boehm-gc content to bdwgc.
Unfortunately no feedback from gcc maintainers arrived. As I found in the mailing list recently, Andrew is going to drop gcj support completely.
Regards,
Ivan
--

I haven't submitted patches to the gcc tree in quite a few years. I guess
I'm still on the submit after approval list.
Andrew - Do you still have an active tree that would allow you to check
this in? Do you know who would?
The correct solution would probably be a much more major upstream merge.
https://github.com/ivmai/bdwgc/blob/master/os_dep.c , around line 1519 .

I could certainly do it, but the only code I can see is guarded with
#ifdef OS2.  I don't have such a system, and I don't think that anyone
else does either.
Andrew.

[NightStrike]

That's kind of sad that gcj will end. I find it very useful as an ahead of
time compiler that's easy to use (in that it matches the rest of the
language compilers) and at least up to Java 5 is pretty complete. With the
jit additions to gcc for c, there's a lot of possibility there for an
alternative to javac.

But I guess if there's a lack of maintainers, then nothing can be done.

Post by Ivan Maidanski
Some time ago I submitted a patch to refactor gcc boehmgc api to match that of gc7.6 (
https://gcc.gnu.org/ml/java-patches/2016-q2/msg00019.html) to make
boehmgc merge with upstream just a simple replacement of boehm-gc content
to bdwgc.
Unfortunately no feedback from gcc maintainers arrived. As I found in the
mailing list recently, Andrew is going to drop gcj support completely.
Regards,
Ivan
--

I haven't submitted patches to the gcc tree in quite a few years. I guess
I'm still on the submit after approval list.
Andrew - Do you still have an active tree that would allow you to check
this in? Do you know who would?
The correct solution would probably be a much more major upstream merge.
https://github.com/ivmai/bdwgc/blob/master/os_dep.c , around line 1519 .

I could certainly do it, but the only code I can see is guarded with
#ifdef OS2. I don't have such a system, and I don't think that anyone
else does either.
Andrew.

[Hans Boehm]

I unfortunately also don't have a good answer to the gcj support issue.

But this raises another bdwgc question: Is anyone actually still using the
OS2 code? I think the motivation for the current patch was that the code
fails cppcheck. Probably the best solution for such problems in general is
to remove support for dead platforms? Like Andrew, I don't recall seeing
any OS/2 use in quite a few years. According to Wikipedia, some ATMs may
still be running it, but I doubt we care.

Post by NightStrike
That's kind of sad that gcj will end. I find it very useful as an ahead of
time compiler that's easy to use (in that it matches the rest of the
language compilers) and at least up to Java 5 is pretty complete. With the
jit additions to gcc for c, there's a lot of possibility there for an
alternative to javac.
But I guess if there's a lack of maintainers, then nothing can be done.

Post by Ivan Maidanski
Some time ago I submitted a patch to refactor gcc boehmgc api to match that of gc7.6 (
https://gcc.gnu.org/ml/java-patches/2016-q2/msg00019.html) to make
boehmgc merge with upstream just a simple replacement of boehm-gc content
to bdwgc.
Unfortunately no feedback from gcc maintainers arrived. As I found in the
mailing list recently, Andrew is going to drop gcj support completely.
Regards,
Ivan
--

I haven't submitted patches to the gcc tree in quite a few years. I

guess

I'm still on the submit after approval list.
Andrew - Do you still have an active tree that would allow you to check
this in? Do you know who would?
The correct solution would probably be a much more major upstream merge.
https://github.com/ivmai/bdwgc/blob/master/os_dep.c , around line 1519

.
I could certainly do it, but the only code I can see is guarded with
#ifdef OS2. I don't have such a system, and I don't think that anyone
else does either.
Andrew.

[Andrew Haley]

I guess if there's a lack of [GCJ] maintainers, then nothing can be done.

Sightly off topic here, but:

gcj is indeed Java 5(ish). Java 5 is obsolete.

Java in use is moving more and more towards a highly dynamic language,
with dynamic optimization. It is possible to write static-ish Java
code, but it's not idiomatic. This means that any purely
ahead-of-time Java compiler is at a severe disadvantage.

The Classpath project, which provided GCJ's runtime library, is nearly
dead. We could use the libraries from OpenJDK, but converting GCJ to
use them would be expensive and time-consuming. For one thing, the
virtual machine is much more complex than it was, and has many more
interfaces we'd have to add. And there are new bytecode instructions
to support a more dynamic language interface.

For GCJ to live we'd have to start to use a more recent version of the
OpenJDK libraries, but we'd still be at a disadvantage with modern Java
code. It's not worth it.

Andrew.