Re: Support for installation of glibj.zip and separate class files
Brian, I think you're thinking of --without-zip? This option still exists, but it hasn't seemed to work since classpath 0.05... Rob. Original Message Follows From: "C. Brian Jones" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Michael Koch <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: Support for installation of glibj.zip and separate class files Date: Fri, 09 Apr 2004 17:44:34 -0400 On Thu, 2004-04-08 at 16:36, Michael Koch wrote: > Hi all, > > > > With my big NIO commit I accidently commited the first part (the parts > in configure.ac) for this patch and so I decided to commit it fully. > We now have two options for installing our classes > > --enable-glibj > installs glibj.zip (enabled by default) > > --enable-class-install > installs all classes as separate files as needed by jamvm and sablevm > (disabled by default) > > Both options are indepedently from each other. You can even disable both > options but this does not make really sense. > > I'm not really satisfied with the name "--enable-class-install". If > someone finds a better name please shout at me. Michael I thought this logic was already in lib/Makefile.am anyway without the extra config option? Maybe that was an old version I was thinking about. Brian << signature.asc >> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon wrote: I am starting to have difficulty understanding Classpath's goals and motivations. When I proposed to add to Classpath some mechanism to allow it to be customized to each VM, I was told that it would be a heresy to encode any VM-specific thing into Classpath, as the vision was: a single Classpath installation would be shared by many VMs on a single system, e.g. common class libraries, common JNI libraries, etc. Now, what you are proposing is that JNI libraries would be compiled specifically for each VM. What have I missed? That I do not speak for Classpath, and that different people have different goals and opinions. Personally, I don't see much point in "common class libraries, common JNI libraries". It might be neat, but: (a) it complicates getting good performance, and (b) coordinating Classpath and VM releses would be too difficult. Yes, it's more elegant to install a single copy of Classpath, but GCJ is not going to use the "system installation" of Classpath, and I wouldn't expect others to do so either. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Support for installation of glibj.zip and separate class files
On Thu, 2004-04-08 at 16:36, Michael Koch wrote: > Hi all, > > > > With my big NIO commit I accidently commited the first part (the parts > in configure.ac) for this patch and so I decided to commit it fully. > We now have two options for installing our classes > > --enable-glibj > installs glibj.zip (enabled by default) > > --enable-class-install > installs all classes as separate files as needed by jamvm and sablevm > (disabled by default) > > Both options are indepedently from each other. You can even disable both > options but this does not make really sense. > > I'm not really satisfied with the name "--enable-class-install". If > someone finds a better name please shout at me. Michael I thought this logic was already in lib/Makefile.am anyway without the extra config option? Maybe that was an old version I was thinking about. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patch: remove C++ keywords
Tom Tromey wrote: [...] A third option would be for you to periodically try it out and check in patches like the one you sent :-). Assuming the other developers are ok with this, it wouldn't be unreasonable, just a bit messy. This seems like the best way to handle the situation. I have a minor readability nit to pick with the class=>clazz and this=>thiz : There are many places in English when "s" has the phonetic spelling of "z" (when it's "voiced"), but the words "this" and "class" aren't among those places. So, if one is doing a straight substitution, I prefer class=>klass, where at least the phonetic spelling matches the mainstream pronounciation of the word. I also like Stephen Compall's suggestion of maintaining the author's indentation by keeping the replacement text the same length, so his suggestion of this=>self seems to be the best choice to me. -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patch: remove C++ keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thats a hack; its dirty and its non-intuitive. I'd advice against that. What about having a source formatter that checks this? A make check seems like a good candidate to report warnings like these. On Friday 09 April 2004 15:49, Eric Blake wrote: > Tom Tromey wrote: > > My only comment or criticism is that, in the absence of regular > > checking for this, we'll just see more code like it checked in. > > That's been the experience with non-C89 constructs, I don't see why > > this would be any different. It's just too hard to remember to write > > in some language subset without compiler-assisted checking. > > To avoid regressions, would we want to use a common header file to > #define the C++ keywords into something that will generate a > compile-time error when compiling under C? That is > > #define this do not use C++ keywords, JNI must compile in C and C++ - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAduFpCojCW6H2z/QRAhmgAKCQQi2bMbb6WwOu47cRKlpKKRL9PwCgxG1I 1S/Pv3uNVguHiOY0yLBkzbM= =iStU -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: FYI: Patch: URLConnection
Michael Koch wrote:
> Am Freitag, 9. April 2004 16:47 schrieb Jeroen Frijters:
>
> > @@ -872,7 +872,7 @@
> > */
> >public static synchronized void
> > setContentHandlerFactory(ContentHandlerFactory factory)
> >{
> > -if (factory != null)
> > +if (URLConnection.factory != null)
> >throw new Error("ContentHandlerFactory already set");
>
> Thx, but how did you find this ? By reading source or using some tool?
I was trying to start Eclipse 3.0M8 and it barfed on this. Of course,
after I fixed that it barfed on something else ;-)
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: Patch: URLConnection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 9. April 2004 16:47 schrieb Jeroen Frijters:
> @@ -872,7 +872,7 @@
> */
>public static synchronized void
> setContentHandlerFactory(ContentHandlerFactory factory)
>{
> -if (factory != null)
> +if (URLConnection.factory != null)
>throw new Error("ContentHandlerFactory already set");
Thx, but how did you find this ? By reading source or using some tool?
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAdsFvWSOgCCdjSDsRAgV7AJ0ctFAlxVSYRIM3pxN+NOhuXjNc/QCfWgXp
mVHDnKiVBmIGCk+bX0Xsgk8=
=yFsJ
-END PGP SIGNATURE-
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
FYI: Patch: java/lang/SecurityManager.java
Hi all,
I've committed the attached patch to clean up a direct use of an
internal field in java.lang.Thread instead of using the API method for
it. I've tried to improve the docs a little bit, too.
2004-04-09 Dalibor Topic <[EMAIL PROTECTED]>
* java/lang/SecurityManager.java: (checkAccess): Use
getThreadGroup(). Improved documentation.
cheers,
dalibor topic
Index: java/lang/SecurityManager.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/SecurityManager.java,v
retrieving revision 1.16
diff -u -r1.16 SecurityManager.java
--- java/lang/SecurityManager.java 6 Jan 2004 09:56:04 - 1.16
+++ java/lang/SecurityManager.java 8 Apr 2004 15:31:04 -
@@ -375,9 +375,9 @@
* RuntimePermission("modifyThread"), return silently, so that
* core classes (the Classpath library!) can modify any thread.
*
- * @param t the other Thread to check
+ * @param thread the other Thread to check
* @throws SecurityException if permission is denied
- * @throws NullPointerException if t is null
+ * @throws NullPointerException if thread is null
* @see Thread#stop()
* @see Thread#suspend()
* @see Thread#resume()
@@ -385,9 +385,10 @@
* @see Thread#setName(String)
* @see Thread#setDaemon(boolean)
*/
- public void checkAccess(Thread t)
+ public void checkAccess(Thread thread)
{
-if (t.group != null && t.group.getParent() != null)
+if (thread.getThreadGroup() != null
+ && thread.getThreadGroup().getParent() != null)
checkPermission(new RuntimePermission("modifyThread"));
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
FYI: Patch: URLConnection
Hi,
Committed.
Regards,
Jeroen
2004-04-09 Jeroen Frijters <[EMAIL PROTECTED]>
* java/net/URLConnection.java: (setContentHandlerFactory): Fixed
to check static field instead of argument.
Index: java/net/URLConnection.java
===
RCS file: /cvsroot/classpath/classpath/java/net/URLConnection.java,v
retrieving revision 1.24
diff -u -r1.24 URLConnection.java
--- java/net/URLConnection.java 8 Apr 2004 17:25:02 - 1.24
+++ java/net/URLConnection.java 9 Apr 2004 14:44:49 -
@@ -872,7 +872,7 @@
*/
public static synchronized void
setContentHandlerFactory(ContentHandlerFactory factory)
{
-if (factory != null)
+if (URLConnection.factory != null)
throw new Error("ContentHandlerFactory already set");
// Throw an exception if an extant security mgr precludes
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: The big NIO
Am Freitag, 9. April 2004 15:24 schrieb Jeroen Frijters: > Michael Koch wrote: > > I just commited my big NIO patch. I doesnt contain yet > > anything from the big pointer discussion. It is just a merge from > > libgcj. > > > It reworks java.io file operations to use java.nio.channels > > internally for performance. I have done a full mauve run and found > > no new strange > > > > failures with jamvm. If any problems occur please mail to me. > > Thanks! I integrated the changes and everything went very smooth. I > really appreciate your efforts. Attached are a few minor suggestions > for FileChannelImpl. I removed some things that appeared to be > unused, but if someone does use it, please just ignore that part of > the patch. Please commit this. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FileDescriptor patch
Am Freitag, 9. April 2004 16:27 schrieb Jeroen Frijters: > Michael Koch wrote: > > Am Freitag, 9. April 2004 15:38 schrieb Jeroen Frijters: > > > Hi, > > > > > > If there aren't any objections, I'll commit the attached fix. > > > > Why do you need this ? Is this for network related stuff ? > > No, FileDescriptor is documented to have a public constructor. I > don't see the point either. Ouch, you are right. I should look into japitools output more often ... Please commit. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FileDescriptor patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 9. April 2004 15:38 schrieb Jeroen Frijters: > Hi, > > If there aren't any objections, I'll commit the attached fix. Why do you need this ? Is this for network related stuff ? Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdrKBWSOgCCdjSDsRAu03AKCHyuR1cQ3L5n5XOfAvCC06cSSctQCgi8tm BLzYTOBHmIV7MIoXEfOb0g0= =PyRl -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: FileDescriptor patch
Michael Koch wrote: > Am Freitag, 9. April 2004 15:38 schrieb Jeroen Frijters: > > Hi, > > > > If there aren't any objections, I'll commit the attached fix. > > Why do you need this ? Is this for network related stuff ? No, FileDescriptor is documented to have a public constructor. I don't see the point either. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patch: remove C++ keywords
Tom Tromey wrote: My only comment or criticism is that, in the absence of regular checking for this, we'll just see more code like it checked in. That's been the experience with non-C89 constructs, I don't see why this would be any different. It's just too hard to remember to write in some language subset without compiler-assisted checking. To avoid regressions, would we want to use a common header file to #define the C++ keywords into something that will generate a compile-time error when compiling under C? That is #define this do not use C++ keywords, JNI must compile in C and C++ -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
FileDescriptor patch
Hi, If there aren't any objections, I'll commit the attached fix. Regards, Jeroen FileDescriptor.patch Description: FileDescriptor.patch ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
Hi Guilhelm, Thanks for the info. Your numbers tend to confirm my suspicion that the factor of 200 is a Kissme-specific problem. In the meantime, I think I have come across a problem in Kissme's implementation of the CONSTANT_STRING instruction that does some way towards explaining this. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: The big NIO
Michael Koch wrote: > I just commited my big NIO patch. I doesnt contain yet > anything from the big pointer discussion. It is just a merge from libgcj. > It reworks java.io file operations to use java.nio.channels internally > for performance. I have done a full mauve run and found no new strange > failures with jamvm. If any problems occur please mail to me. Thanks! I integrated the changes and everything went very smooth. I really appreciate your efforts. Attached are a few minor suggestions for FileChannelImpl. I removed some things that appeared to be unused, but if someone does use it, please just ignore that part of the patch. Regards, Jeroen FileChannelImpl.diff Description: FileChannelImpl.diff ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Steven Augart wrote: > If the RawData type were to be used, would you be able to share a > Classpath installation with other Classpath-based virtual machines? For some purposes yes. For performance (and some bootstrapping) reasons I compile Classpath code ahead of time to a CLI assembly, so at runtime there wouldn't be any sharing, but the compilation process could use the shared Classpath installation. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
If the RawData type were to be used, would you be able to share a Classpath installation with other Classpath-based virtual machines? --Steve Augart Jeroen Frijters wrote: Steven Augart wrote: If we were to do this in the GNU Classpath Java code, then the only solution I see is to use a preprocessor, and expand gpointer to an int or long as appropriate, based upon the standard pointer representation in that platform's usual ABI. That wouldn't work for me. My (single) binary runs on both 32 and 64 bit platforms. That's why I like using an object reference. BTW, I don't actually store a native pointer in an object reference. I replace RawData references with a native pointer type that the CLI support (System.IntPtr). This is a primitive type, but it can also be boxed when you assign it to an object reference. -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Stuart Ballard wrote: > 2) "Unusual" VMs: Things where JNI-centric assumptions don't > hold true. > For example, IKVM and Jaos(?) don't use JNI at all within > Classpath, and their natural "pointer" type is just a normal > object reference. gcj with CNI also falls into this category. I'd like to qualify this. IKVM does have native pointers. This discussion is about RawData use in NIO, in which case we are talking about native memory (presumably in most/all VM types). For general VM state, I wouldn't like to see RawData used, because on IKVM, Jaos and Jikes RVM, you'd typically want the VM state to be in a Java heap object as well. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Archie Cobbs wrote: > Note: by this logic byte[] is the most portable/generic way to hold > VM private data. It places no portability restrictions, only > (possibly) performance ones. However, I have yet to hear a > convincing argument that proves byte[] is slower than RawData > (or whatever) on ALL platforms. IMHO, that is a flawed argument. RawData allows better performance (for VMs that do extra work), byte[] actively prevents that. So the trade-off is *marginally* better portability (byte[]) or the option of better performance (RawData). Not to mention the fact that RawData is a distinct type and opaque from the Java side. The contents byte[] can be manipulated in Java, or a completely wrong byte array could be passed. So I agree with Andrew and Steve, that it is also a better option from a software engineering pov. > E.g., take JC as an example. byte[] and "RawData containing long" both > require one "unwrap" to get the pointer. "RawData containing long" > wastes 4 bytes on 32-bit platforms, but byte[]->length also > costs 4 bytes, so size is a wash. But the beauty of RawData is that you can use 32 bit pointers on 32 bit platforms! Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Steven Augart wrote: > If we were to do this in the GNU Classpath Java code, then the only > solution I see is to use a preprocessor, and expand gpointer > to an int or long as appropriate, based upon the standard pointer > representation in that platform's usual ABI. That wouldn't work for me. My (single) binary runs on both 32 and 64 bit platforms. That's why I like using an object reference. BTW, I don't actually store a native pointer in an object reference. I replace RawData references with a native pointer type that the CLI support (System.IntPtr). This is a primitive type, but it can also be boxed when you assign it to an object reference. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Etienne Gagnon wrote: > Jeroen Frijters wrote: > >>>Indeed. The goal is to find the optimal solution that would be spec > >>>compliant, portable and efficient. > > and later: > > I'm not the one nitpicking about pure ISO C portability (I don't use > > JNI, so I couldn't care less), ... > > and later: > >>and is of thus ranks lower than my proposal on 2 counts: > >>1- Efficiency: > > > > For a JNI based implementation, maybe, but I'd argue that > anyone using > > JNI doesn't care about performance anyway. > > You contradict yourself. First you say that the optimal is > spec compliant, portable, and efficient. Then you say that > you couldn't care less about the spec compliant JNI interface, > that portability across JVMs/compilers on a single platform is > of no interest, and that efficiency of JNI is not an objective > of your proposal. Let me explain. I don't see Classpath as a monolithic entitity. I see Classpath as two parts, Java and native. I use the Java part, I don't use the native part. I care about Classpath as a whole. I think the native part is valuable (because it increases the value of Classpath as a whole, it also increases the value of the Java part). In the particular case we are discussing (memory mapped NIO), I think that JNI is a lousy interface. I think it will prove to be far too slow, therefor I want to use the proper abstractions that allow VMs to optimize these operations. IMHO, RawData is better abstraction than a byte[] for this particular purpose. I just wrote a little benchmark comparing byte[] and RawData for reading bytes (i.e. dereferencing the pointer) and another one that tests alloc/free. It turns out that RawData is actually marginally faster (in both cases). This is on x86 32bit on Sun JDK 1.4.1 using standard JNI. I'm not going to give the code, because that'll just trigger another round of language lawyering, but I'm convinced that C language issues do not have any significant impact on the performance of either solution. For reference, my (partially) optimized implementation of dereferencing the RawData pointer is almost an order of magnitude faster than the JNI implementation running on the Sun JVM (and two orders of magnitude faster than the JNI implementation running on my VM). Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Support for installation of glibj.zip and separate class files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Perhaps a better interface (more intuitive) would be something like this: - --enable-install=[both|classes|zip] On Thursday 08 April 2004 22:36, Michael Koch wrote: > Hi all, > > > > With my big NIO commit I accidently commited the first part (the parts > in configure.ac) for this patch and so I decided to commit it fully. > We now have two options for installing our classes > > --enable-glibj > installs glibj.zip (enabled by default) > > --enable-class-install > installs all classes as separate files as needed by jamvm and sablevm > (disabled by default) > > Both options are indepedently from each other. You can even disable both > options but this does not make really sense. > > I'm not really satisfied with the name "--enable-class-install". If > someone finds a better name please shout at me. > > > Michael > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath - -- Regards Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAdkvMCojCW6H2z/QRAmqSAJ4tYJtHMT+pXXaO5Orm7QWBeKoLQQCgtcWu K56xK+ssGRlT2ONCqXur0fA= =YVXS -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
