This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
[patch proposal] mark GCJ local code
- From: Andreas Tobler <toa at pop dot agri dot ch>
- To: Java Patches <java-patches at gcc dot gnu dot org>
- Date: Tue, 28 Sep 2004 21:19:28 +0200
- Subject: [patch proposal] mark GCJ local code
Hi all,
merging classpath to gcj and the otherway round can be quite difficult
if you do not know all the details.
So, my proposal is to mark code in libgcj with GCJ LOCAL /GCJ LOCAL END
which should not be merged. (as already done in a few places, but we
should continue....)
I tried for java/lang/Runtime.java.
Would this be an improvement for others too?
This patchlet is just a try to get some opinions.
Also, I'm not sure yet if we should mark whole blocks or each function
with GCJ LOCAL /GCJ LOCAL END? Or even other markers ?
Any ideas ?
Thanks,
Andreas
Index: java/lang/Runtime.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/Runtime.java,v
retrieving revision 1.16
diff -u -r1.16 Runtime.java
--- java/lang/Runtime.java 12 Aug 2004 16:20:10 -0000 1.16
+++ java/lang/Runtime.java 28 Sep 2004 19:15:12 -0000
@@ -544,6 +544,7 @@
*
* @return the number of processors available, at least 1
*/
+ // GCJ LOCAL: We diverge from Classpath for efficiency.
public native int availableProcessors();
/**
@@ -605,6 +606,7 @@
* @param on whether to turn method tracing on
*/
public native void traceMethodCalls(boolean on);
+ // END GCJ LOCAL
/**
* Load a native library using the system-dependent filename. This is similar
@@ -682,6 +684,7 @@
return out;
}
+ //GCJ LOCAL: We diverge from Classpath for efficiency.
/**
* Native method that actually shuts down the virtual machine.
*
@@ -782,4 +785,5 @@
* @param p the Properties object to insert the system properties into
*/
static native void insertSystemProperties(Properties p);
+ // END GCJ LOCAL
} // class Runtime