Re: Patch: remove C++ keywords
Tom Tromey wrote: Ingo == Ingo Prötel [EMAIL PROTECTED] writes: Ingo I would like to suggest removing all C++ keywords as names in Ingo the native implementations of GNU Classpath. We have a customer Ingo who insists on using C++ because of the more thorough code Ingo inspection. To be able to compile with such a compiler we need Ingo to change all names that are C++ keywords. I think this idea is fine. It doesn't bother me anyway... though I'd suggest waiting for a response from folks who hack on the JNI code more than me :-) I guess I will wait a week or so. (Going on a long Easter weekend anyway ;-) 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. We could declare all the JNI code to actually be C++, of course. But then we'd see real C++ usage slip in. No we should stay within C. But compiling was C++ code once in a while does give a little code review. 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. Tom We are currently in the works of making our complete VM C++ compilable. Once we have achieved this we will have a nightly integration build with a C++ compiler. I will then be glad to submit patches to fix the C++ building (we will need to do those anyway). ingo -- Ingo Prötel [EMAIL PROTECTED] aicas GmbHhttp://www.aicas.com Haid-und-Neu-Str. 18phone +49 721 663 968-32 76131 Karlsruhe fax +49 721 663 968-93 Germany ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Localization patches for gnu.regexp
Am Donnerstag, 8. April 2004 05:06 schrieb Steven Augart: Here are some localization patches for the gnu.regexp package's messages. Shouldnt this get submitted upstream first ? Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Grzegorz B. Prokopski wrote:
On (07/04/04 13:47), Jeroen Frijters wrote:
Andrew Haley wrote:
This seems to be identical to my proposal.
I no longer understand what we're arguing about...
I know. I thought we were still trying to convince Etienne :-)
I thought the goal was finding the optimal solution that would be spec
compliant, portable and efficient.
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient. Since I obviously believe that my
proposal is better than the byte[] proposal, I would like to convice
Etienne (and you) of this. I fail to see how you can take issue with
that.
And I still haven't seen good example from Andrew about how native
part of his opaque class would look like and what burden would it
have.
I don't feel like writing real JNI code, but here is the general idea:
jobject WrapPointer(JNIEnv* env, void* p)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData32);
jmethodID mid = env-GetMethodID(pclass, init, (I)V);
return env-NewObject(pclass, mid, p);
#else if PLATFORM_HAS_64_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData64);
jmethodID mid = env-GetMethodID(pclass, init, (J)V);
return env-NewObject(pclass, mid, p);
#else if PLATFORM_HAS_128_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData128);
jmethodID mid = env-GetMethodID(pclass, init, (JJ)V);
jlong hi = HI_FROM_PTR(p);
jlong lo = LO_FROM_PTR(p);
return env-NewObject(pclass, mid, hi, lo);
#else
#error unsupported
#endif
}
void* UnwrapPointer(JNIEnv* env, jobject pobj)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData32);
jfieldID fid = env-GetFieldID(pclass, ptr, I);
return (void*)env-GetIntField(pobj, fid);
#else if PLATFORM_HAS_64_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData64);
jfieldID fid = env-GetFieldID(pclass, ptr, J);
return (void*)env-GetLongField(pobj, fid);
#else if PLATFORM_HAS_128_BIT_NATIVE_POINTER
jclass pclass = env-FindClass(RawData128);
jfieldID fidHi = env-GetFieldID(pclass, ptrHi, J);
jfieldID fidLo = env-GetFieldID(pclass, ptrLo, J);
jlong hi = env-GetLongField(pobj, fidLo);
jlong lo = env-GetLongField(pobj, fidLo);
return PTR_FROM_HI_LO(hi, lo);
#else
#error unsupported
#endif
}
I a real implementation you'd obviously cache the jclass and
jmethodID/jfieldID. I don't think this is less efficient or less
portable than using a byte[]. It only requires a (tiny) bit of extra
code to support different pointer sizes.
About the other solution - a comment. Why again use
something magical?
A magica class in this case called RawData.
There is nothing magical about it, but it does allow JITs (on VMs that
don't use JNI to interact with the RawData pointers) to optimize access.
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: An interessting change for shared char[] in String/StringBuffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 08 April 2004 01:24, Artur Biesiadowski wrote: Tom Tromey wrote: From http://java.sun.com/j2se/1.5.0/jcp/beta1/index.html#java.lang: In this release, the sharing between String and StringBuffer has been eliminated. Does this mean to change to change the implementation in Classpath too? I like this optimization... I don't think we necessarily have to change this. IMO it would depend on whether the change is observable by user code. Our implementation doesn't always share, anyway. It only shares if the buffer is mostly in use. 'Observable by user code' is very broad term. It is possible to write a short program which will throw OutOfMemoryException with sharing on and work without problems when data is always copied - does it counts as observation from user code ? No, I don't think so. If the only difference (as I understand from Tom's email) is faster/effecient implementation then copying behavior from Sus JVM is not needed in the first place. Waiting for the 1.5 release and seeing if this proved too unstable for the Sun JVM gives you a good indication weather this feature is a nice advancement in Classpath.. Just my 2 cents. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdRWJCojCW6H2z/QRAt2aAKClbQqTWl8NU5rjZDH08JzXVvj/ywCeJkZn X3IMy1RwPHMrHs3oXh0J+Sc= =1AOO -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon wrote: Andrew Haley wrote: Okay, but ANS specifically does not allow you to do this subtraction. Also, there is no guarantee that every pointer is representable as a ptrdiff_t. (6.5.6 Para 9, if you're interested) The point is: if your platform is one that does *not* have 8-bit chars (!!!), http://www.36bit.org/ for platforms where CHAR_BITS is 9. And for some non-related fun, http://www-1.ibm.com/servers/enable/site/porting/iseries/overview/faq_misc.html for a platform with 128 bit pointers. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
[Problem]glibj.zip conflict with kaffe vm's rt.jar
hi, i'm a java developer, yet new to use classpath such project. currently i test how to use classpath to develop my project. however, after kaffe (/usr/local/kaffe) and classpath (/usr/local/classpath) installed, when compiling a simple HelloWorld program, there's a dilemma occurred. if i put classpath lib - glibj.zip, in env variable CLASSPATH. the kaffe vm issues problem that has package conflict with kaffe's lib, rt.jar. what can i do to that, if i want to use classpath's glibj.zip? or where did i do it wrong? i appreacite any suggestions, sincerely. - Email Yahoo! http://tw.companion.yahoo.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Problem]glibj.zip conflict with kaffe vm's rt.jar
Hi Arsene, [EMAIL PROTECTED] wrote: hi, i'm a java developer, yet new to use classpath such project. currently i test how to use classpath to develop my project. however, after kaffe (/usr/local/kaffe) and classpath (/usr/local/classpath) installed, when compiling a simple HelloWorld program, there's a dilemma occurred. if i put classpath lib - glibj.zip, in env variable CLASSPATH. the kaffe vm issues problem that has package conflict with kaffe's lib, rt.jar. what can i do to that, if i want to use classpath's glibj.zip? or where did i do it wrong? i appreacite any suggestions, sincerely. you can not use Classpath's class library with Kaffe, since some fundamental classes conflict. when compiling programs, yuu can usually pass the compiler a specific classpath to use for the compilation. I assume you're using kjc, so that should be the --classpath option. cheers, dalibor topic ___ 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. Since I obviously believe that my
proposal is better than the byte[] proposal, I would like to convice
Etienne (and you) of this. I fail to see how you can take issue with
that.
Fair.
I don't feel like writing real JNI code, but here is the
general idea:
So, you don't have a real proposal... We need to compare *real* JNI
code to real JNI code, otherwise, we'll be arguing about
misconceptions.
I still think that my proposal is better than the one you
sketched below.
jobject WrapPointer(JNIEnv* env, void* p)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
For one thing, my proposal does not need any specific #ifdef
per pointer size.
Absolutely, that is a big advantage of the byte[] approach, but IMHO it
optimizes for the wrong scenario. I (and I suspect most others) don't
care about pointer sizes other than 32/64 bit.
jclass pclass = env-FindClass(RawData32);
jmethodID mid = env-GetMethodID(pclass, init, (I)V);
That's supposed to be faster than my proposal
This is only done once. But you are missing my point about efficiency.
The JNI approach isn't about performance, it is going to be slow, no
matter what. I just want the option the make my implementation fast. The
byte[] approach doesn't give me this option. It forces me into
suboptimal implementation.
return env-NewObject(pclass, mid, p);
** Bzzzt *** Please try again...
Now that my proposal has been criticised to death on the smallest
nitpicks of pure ISO C portability, let me comment on the portability
]of your code.
I'm not the one nitpicking about pure ISO C portability (I don't use
JNI, so I couldn't care less), but we could use the exact same trick you
used in your JBYTE_IS_NOT_SIGNED_CHAR versions of wrap/unwrap. So this
is a non-issue.
So, no, your proposal is NOT portable,
It is portable (can be made portable by someone who cares, i.e. not me).
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.
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient. Since I obviously believe that my
proposal is better than the byte[] proposal, I would like to convice
Etienne (and you) of this. I fail to see how you can take issue with
that.
Fair.
I don't feel like writing real JNI code, but here is the general idea:
So, you don't have a real proposal... We need to compare *real* JNI
code to real JNI code, otherwise, we'll be arguing about misconceptions.
I still think that my proposal is better than the one you sketched below.
jobject WrapPointer(JNIEnv* env, void* p)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
For one thing, my proposal does not need any specific #ifdef per pointer
size.
jclass pclass = env-FindClass(RawData32);
jmethodID mid = env-GetMethodID(pclass, init, (I)V);
That's supposed to be faster than my proposal
return env-NewObject(pclass, mid, p);
** Bzzzt *** Please try again...
Now that my proposal has been criticised to death on the smallest
nitpicks of pure ISO C portability, let me comment on the portability
]of your code.
The ISO C standard says:
[#6] Any pointer type may be converted to an integer type;
the result is implementation-defined. If the result cannot
be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of |
any integer type.
So, the conversion of p to jlong or jint yields a *compiler-specific*
value; ISO C does not guarantees anything about the actual value resulting
from the cast. In other words, a compiler would be allowed to change
the bits of the pointer value when converting.
Now, *my* proposal, when jbyte == signed char, does not convert
the pointer to an integer, which is something non-portable across
*compilers* on a same platform. [Remember: the *main* objective of
JNI is portability across VMs (and compilers) on the same platform,
because you shouldn't have to recompile the library to work with
another VM].
So, no, your proposal is NOT portable, and is of thus ranks lower than
my proposal on 2 counts:
1- Efficiency:
- my approach needs no call to FindClass GetMethodID
- wrapping the pointer causes no execution of Java byte code,
but in your case, the constructor init must be executed.
2- Portability:
- Your code uses an implementation-defined (i.e. compiler-specific)
conversion; and cannot guarantee that the pointer will be actually
restored on unwrapping.
FYI: Annex K portability Issues (informative) of the ISO C specification
specifically points out the following as being implementation defined:
K.3.7 Arrays and pointers
[#1]
-- The result of converting a pointer to an integer or
vice versa (6.3.2.3).
Your proposal fails portability on this account.
I a real implementation you'd obviously cache the jclass and
jmethodID/jfieldID. I don't think this is less efficient or less
portable than using a byte[].
Caching jclass/jmethodID/jfieldID will not solve all the problems;
you still call the constructor init. Not only will this cause
execution of Java code (which is not required in my proposal), but
on non-optimizing JVMs, it will cause execution of 3 constructors(!!):
1- RawData32.init
2- RawData.init
3- Object.init
It only requires a (tiny) bit of extra
code to support different pointer sizes.
Mine requires none.
Also, it is highly probable that we'll get to 128-bit platforms one
day: just imagine if you could use a secure hash, like SHA-1 as
hashcode to store data in a virtual memory implementation with 128-bit
addresses! :-) I *am* serious.
There is nothing magical about it, but it does allow JITs (on VMs that
don't use JNI to interact with the RawData pointers) to optimize access.
Your proposal is slower for JNI-compliant VMs, and it is not portable.
You see: this is why I wanted you to show me JNI code, as I have thought
about the problem for quite a while before settling with the idea of
byte arrays.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: Classpath build process and VM-specific issues
Jeroen Frijters writes: return env-NewObject(pclass, mid, p); ** Bzzzt *** Please try again... Now that my proposal has been criticised to death on the smallest nitpicks of pure ISO C portability, let me comment on the portability of your code. That wasn't my point in nitpicking. What I was attempting was showing that to prefer one approach to another soley on the grounds of pure ISO compatibility is probably a mistake. Every approach so far has lacked correctness in some way. Strong typing for legibility and reliability is IMO for more important. Here's a real example from SWT: public static final synchronized native int g_signal_handlers_unblock_matched(long /*PTR*/ instance, int mask, int signal_id, int detail, long /*PTR*/ closure, long /*PTR*/ func, long /*PTR*/ data); Here it is with passing the pointers as byte arrays: public static final synchronized native int g_signal_handlers_unblock_matched(byte[] instance, int mask, int signal_id, int detail, byte[] closure, byte[] func, byte[] data); And here it is with named opaque types: public static final synchronized native int g_signal_handlers_unblock_matched(gpointer instance, int mask, int signal_id, int detail, GClosurePointer closure, gpointer func, gpointer data); Just for reference, here is the corresponding C declaration: guint g_signal_handlers_unblock_matched (gpointer instance, GSignalMatchType mask, guint signal_id, GQuark detail, GClosure *closure, gpointer func, gpointer data); Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon writes: Now that my proposal has been criticised to death on the smallest nitpicks of pure ISO C portability, let me comment on the portability ]of your code. The ISO C standard says: [#6] Any pointer type may be converted to an integer type; the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of | any integer type. So, the conversion of p to jlong or jint yields a *compiler-specific* value; ISO C does not guarantees anything about the actual value resulting from the cast. In other words, a compiler would be allowed to change the bits of the pointer value when converting. Exactly: the only reliable way I can see to do this is to use memcpy() from the big pointer to a byte array. But, compared to the overhead of a JNI call, that is no big deal. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: An interessting change for shared char[] in String/StringBuffer
Tom Tromey wrote: == Chr Ullenboom [EMAIL PROTECTED] writes: From http://java.sun.com/j2se/1.5.0/jcp/beta1/index.html#java.lang: In this release, the sharing between String and StringBuffer has been eliminated. Does this mean to change to change the implementation in Classpath too? I like this optimization... I don't think we necessarily have to change this. IMO it would depend on whether the change is observable by user code. Our implementation doesn't always share, anyway. It only shares if the buffer is mostly in use. Part of Sun's rationale for their change is that in 1.5, they introduced java.lang.StringBuilder, a non-synchronized copy of StringBuffer with otherwise identical semantics. Similar to gnu.java.lang.StringBuffer used in gcj, if StringBuilder exists, it allows the compiler to emit more efficient string concatenation (and jikes already knows how to use it). My understanding of Sun's implementation of StringBuilder is that it is rather simplistic (based on a bug report to Sun's site complaining that the javadoc was misleading because of the non-public superclass) - they renamed the old StringBuffer into a new package-private class java.lang.AbstractStringBuffer (or some such name) for all the implementation, then created StringBuffer and StringBuilder as public extension classes with no further implementation (other than the fact that all the StringBuffer methods add synchronization). So perhaps they made the change on sharing the char[] because their class-shuffling broke something. I agree with Tom that we would have to benchmark it to see if sharing or not sharing is more efficient, before blindly choosing one way over the other just to match Sun. If I understand correctly, back in JDK 1.0, Sun did NOT use char[] sharing - it was added later as an optimization before JIT compilers were as good as they are now (and now Sun claims to be deleting it as an optimization). Also, we will have to be careful that we handle serialization of StringBuffer correctly, whichever way we choose. I also wonder if the following implementation would be more efficient. In the common case, StringBuffer/StringBuilder is used for appends, and then converted to a String just before being discarded. Currently, for every append, we adjust the underlying char[] and copy the appended String into that array. Would it be better to just build a String[] that caches all the appended Strings, and then create a single char[] at the time toString() is called, rather than updating the char[] for every append()? Of course, we would have to create the char[] for any non-append() method. And one of the disadvantages of this method is that we end up creating intermediate Strings when we append primitive types, whereas the current implementation can update the char[] without creating any intermediate objects. I haven't coded this up to experiment on the difference, but it would be an interesting experiment. -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: An interessting change for shared char[] in String/StringBuffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 08 April 2004 15:24, Eric Blake wrote: Tom Tromey wrote: I also wonder if the following implementation would be more efficient. In the common case, StringBuffer/StringBuilder is used for appends, and then converted to a String just before being discarded. Currently, for every append, we adjust the underlying char[] and copy the appended String into that array. Would it be better ... An alternate approach; some time ago I noticed that the ByteArrayOutputStream copied all data already present on each add, which is when we came up with the following approach that would be usefull here as well; Use a list of byte[] 's (or char[]'s) and optimistically allocate space in the first array. At appends copy all the bytes that will fit into the already allocated byte[], and allocate a second one for the rest. Use some algoritm that allocates based on previous size (say; 20% of current size) so you will get increasingly bigger arrays which you copy into. At the end you will have a list of arrays which you can copy into one big array on toString() or similar. We found that this is the most effecient way of accumulating data in one class with minimum garbage collection / allocations. Hope thats clear. - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdVc1CojCW6H2z/QRAqsSAKDrtFYdfBLrpSmVgd20zR+uDOespgCgnhBz Q3bBChRLpbavbuKmP2lePdY= =x02e -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
The Mauve unicode testcase and VM performance
Folks, I've just checked in a new version of the Mauve testcase for Unicode character handling. This fixes previous problems that resulted in huge numbers of test failures with the current version of Classpath. [It turns out that they were partly because the testcase used an old Unicode table, but mostly because of testcase bugs; i.e. tests that were wrong vis-a-vis the JDK 1.4 javadoc.] The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath from CVS. The interesting thing is that the test run 200 times faster with JDK 1.4.2 than with Kissme. Yes TWO HUNDRED TIMES! $ cat /tmp/foo gnu.testlet.java.lang.Character.unicode $ /usr/java/j2sdk1.4.2/bin/java -cp ../mauve gnu.testlet.SimpleTestHarness \ -debug /tmp/foo Reading unicode database... done Benchmark : load:288ms tests:505ms 0 of 3578944 tests failed $ useful_scripts/kissme -cp ../mauve gnu.testlet.SimpleTestHarness -debug /tmp/foo Reading unicode database... done Benchmark : load:13892ms tests:104699ms 0 of 3578944 tests failed (This is on a 2.5Ghz Pentium IV) Question: what figures do people get with other open source VMs? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
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. OK. So, it is clear that I am wasting my time, here. I now clearly understand that the main motivation is for Classpath to use less portable approaches when they make CNI faster, as the performance of CNI and the other non-spec compliant interfaces is the main objective. Fine. I'll devote my time elsewhere. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: The Mauve unicode testcase and VM performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Crawley wrote: | Folks, | | I've just checked in a new version of the Mauve testcase for Unicode | character handling. This fixes previous problems that resulted in | huge numbers of test failures with the current version of Classpath. | [It turns out that they were partly because the testcase used an old | Unicode table, but mostly because of testcase bugs; i.e. tests that | were wrong vis-a-vis the JDK 1.4 javadoc.] | | The testcase now runs clean for JDK 1.4.2 as well as Kissme/Classpath | from CVS. | | The interesting thing is that the test run 200 times faster with JDK 1.4.2 | than with Kissme. Yes TWO HUNDRED TIMES! | | $ cat /tmp/foo | gnu.testlet.java.lang.Character.unicode | | $ /usr/java/j2sdk1.4.2/bin/java -cp ../mauve gnu.testlet.SimpleTestHarness \ |-debug /tmp/foo | Reading unicode database... | done | Benchmark : load:288ms tests:505ms | 0 of 3578944 tests failed | | $ useful_scripts/kissme -cp ../mauve gnu.testlet.SimpleTestHarness - -debug /tmp/foo | Reading unicode database... | done | Benchmark : load:13892ms tests:104699ms | 0 of 3578944 tests failed | | (This is on a 2.5Ghz Pentium IV) | | Question: what figures do people get with other open source VMs? | Thanks for fixing unicode ! On my PIV 2.5 it gives with kaffe jit3: [EMAIL PROTECTED] mauve]$ echo gnu.testlet.java.lang.Character.unicode | kaffe gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:1052ms tests:334ms 0 of 3578944 tests failed [EMAIL PROTECTED] mauve]$ echo gnu.testlet.java.lang.Character.unicode | /usr/j2sdk1.4.2/bin/java gnu.testlet.SimpleTestHarness -debug Reading unicode database... done Benchmark : load:266ms tests:406ms 0 of 3578944 tests failed Answer: h 70ms faster for tests but 5 times slower for loading. Cheers, Guilhem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAdYkLWRk4qbNiTwgRArf+AKCOFjQu0gMirvywMCGUdNHvbE1q2QCgjceY GkG9MpJGgZIDsh1auJQ/RpY= =Pft5 -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon writes: 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. OK. So, it is clear that I am wasting my time, here. I now clearly understand that the main motivation is for Classpath to use less portable approaches when they make CNI faster, as the performance of CNI and the other non-spec compliant interfaces is the main objective. Come on now. We need to find a clean way to do this, and although it may seem like I'm being overly pushy, my main concern is to do what's right for everyone who uses JNI in Classpath, long term. Perhaps we need to define what we're really aiming at. I would have thought: 1. Correctness (well-defined on the platforms we care about.) 2. Portability (to the platforms we care about.) 3. Maintainability/Readability of code. 4. Efficiency. Does anyone really disagree with these priorities? Okay, perhaps we need to agree what platforms we care about. Fine. I'll devote my time elsewhere. That's a shame. I wouldn't like to think I was responsible in some way for pushing you (and SableVM) away form the Classpath list. It seems to me that we've been focussing on small details without agreeing on our goals. The goals of IKVM and SableVM are different, but I feel sure that a compromise is possible. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon wrote: the main motivation is for Classpath to use less portable approaches when they make CNI faster, as the performance of CNI and the other non-spec compliant interfaces is the main objective. Jikes RVM uses JNI and is unlikely to ever implement CNI. There are other classpath-using VMs that implement JNI. Obviously, most of those of us who work on a specific VM are thinking about what proposals will mean for our particular VM. For the Jikes RVM crowd, Dave Grove, Mike Hind, and I will object loudly to anything that really messes up JNI, and I'm sure the other JNI users will speak up for their VMs. -- 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
Andrew Haley wrote: Perhaps we need to define what we're really aiming at. I would have thought: 1. Correctness (well-defined on the platforms we care about.) 2. Portability (to the platforms we care about.) 3. Maintainability/Readability of code. 4. Efficiency. Does anyone really disagree with these priorities? Not me. Okay, perhaps we need to agree what platforms we care about. Here are my votes... - We don't care about platforms that don't have 8 bit bytes or where typeof(jchar) != signed char. - We don't care about platforms where 'jlong' is insufficient to hold VM private data. E.g., on a platform with 128 bit pointers, then the VM must use a hash table or something to derive the actual pointer (or whatever it needs). I.e., we deem 64 bits enough to uniquely describe all unique VM-private data structures. - We don't use ``because it runs faster on my VM'' as evidence of being more efficient; It must run faster on ALL VM's for it to mean anything. - When there are non-obvious tradeoffs in efficiency (i.e., it's faster on some VMs, slower on others, or otherwise muddy) then we choose the option which is the most portable and/or generic. - Requiring the VM to specially recognize and not trace a RawData object pointer type decreases portability (having a RawData type that merely is a normal object holding a long does not). 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. 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. byte[] is portable to 128 bit platforms while RawData containing long is not (sure, probably won't happen in my lifetime, but... ). Finally, RawData as opaque pointer doesn't require any unwraping but does hit GC cycle time severely as every object has to be check for being in this special RawData class. So for JC byte[] is best. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Andrew Haley wrote: Strong typing for legibility and reliability is IMO for more important. I strongly agree with this, on software engineering grounds. And here it is with named opaque types: public static final synchronized native int g_signal_handlers_unblock_matched(gpointer instance, int mask, int signal_id, int detail, GClosurePointer closure, gpointer func, gpointer data); These are great examples from SWT. 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. I have no idea what we will do when 128-bit machines become available. Probably by that time Sun will have added a type called long long or long128, and we'll expand gpointer to that on the 128-bit machines. Like Andrew, I am uncomfortable with using byte[] to represent a raw pointer. I also see Etienne's point of view that a class to encapsulate the data is pretty heavy-weight, and that only a few VMs would implement special handling for the RawPointer type. Worse, a VM that did handle it specially would not binary-compatible with one that treated it as just another class. Ick; there are no good solutions. I hate to introduce the notion of a preprocessor. Oh well, I guess I just did. -- 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
Etienne Gagnon [EMAIL PROTECTED] writes: Michael Koch wrote: Personally I think using obj or so is better then using thiz. Agree. I like obj instead of this. [I don't like thiz] Similarly, I like cls instead of class. [I don't like clazz] thiz makes sense if you are trying to maintain proper indentation w/o reindenting in some cases, e.g. (*(thiz-closure)) (one, vs (*(obj-closure)) (one, two);two); I suggest `self', which I like better than `this' anyway, being a Python/Smalltalk fan. I can't think of an alternative for class. -- Stephen Compall or s11 or sirian Errata f y cn rd ths y cn gt gd jb n cmptr prgrmng (146656) MD5 Consul AVN World Trade Center radar lock picking Nazi ARPA high security Exon Shell White House global ISEC 22nd SAS Craig Livingstone ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Archie Cobbs writes: 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. 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. byte[] is portable to 128 bit platforms while RawData containing long is not (sure, probably won't happen in my lifetime, but... ). Am I the only one who cares about type checking? :-) Finally, RawData as opaque pointer doesn't require any unwraping but does hit GC cycle time severely as every object has to be check for being in this special RawData class. So for JC byte[] is best. We get away with this in GCJ because a pointer outside the heap is ignored. I would have thought that many other GCs do this too. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Archie Cobbs wrote: Okay, perhaps we need to agree what platforms we care about. Here are my votes... - We don't care about platforms that don't have 8 bit bytes or where typeof(jchar) != signed char. - We don't care about platforms where 'jlong' is insufficient to hold VM private data. E.g., on a platform with 128 bit pointers, then the VM must use a hash table or something to derive the actual pointer (or whatever it needs). I.e., we deem 64 bits enough to uniquely describe all unique VM-private data structures. I'd like to see some qualification of don't care. Seems to me that there are multiple levels of caring: 1) Normal VMs on Normal platforms. Use JNI, don't have any weirdnesses about the sizes or types of JNI data types. 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. 3) Unusual platforms: Any real and existing platforms to which a Classpath port is a real possibility, but violate one of the two criteria above, or other normally reasonable assumptions about the behavior of the CPU, OS or C compiler. 4) Non-free VMs: generally JDK derivatives that we have no control over and are unlikely to change to adopt our practices, or even optimize for them. 5) Nonexistent VMs or nonexistent platforms: VMs or platforms that are theoretically possible or theoretically permitted by the standards, but which never actually occur in any real platform now or in the forseeable future, or will never be able to run even a minimal JVM (Z80 or 6502 chips probably fall into the latter category?) Seems to me that whatever is adopted needs to take into account the existence of types 2 and 3, but it's okay to optimize for performance on type 1. I'm not sure that we should invest *any* time worrying about types 4 or 5 (although I can conceive of situations where portability to type 4 is desirable, it's certainly not the general case *within Classpath*) The byte array solution has negative implications for, at least, type 2: it's generally impossible to round-trip between an object reference and a byte[] without a hashtable and serious inefficiency. The opaque RawData class may have negative performance implications for type 1 (does everyone agree on this? hard to tell), which makes it undesirable, but it is at least usable on all types (including the ones we don't care about). Nobody yet in this thread has talked about the possibility of just using Object references, unless I've missed it. The advantage would be that you can store whatever type you like - byte[] or an opaque RawData class or a native pointer or anything - the disadvantage would be that the native code couldn't be shared when different things were stored there. This solution would help type 2 systems (which generally don't share the JNI native code anyway) while still allowing the JNI default code to use byte[] (or for the flamewar to continue over what it should use ;) ) I think that it's important to draw a distinction between these various types of VM, because they have different needs, different performance characteristics, and in some cases (like the byte[] solution on type 2) can't use one particular approach *at all* - or at least, not without severe, orders-of-magnitude-worse performance problems. Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Andrew Haley wrote: Finally, RawData as opaque pointer doesn't require any unwraping but does hit GC cycle time severely as every object has to be check for being in this special RawData class. So for JC byte[] is best. We get away with this in GCJ because a pointer outside the heap is ignored. I would have thought that many other GCs do this too. They probably do, but JC doesn't right now.. it assumes objects live either in the heap or in per-loader memory, and in the latter case, it assumes the object must be a Class instance. Relaxing these assumptions wouldn't cost that much, but the point is of course that there would be a non-zero impact so the change wouldn't be free. In the future JC may support stack-allocated objects, in which case it would then know to ignore any reference pointing to a weird place, so this will probably change. As I've stated before, there are lots of different tradeoffs with all the VM's out there and IMHO Classpath should not try to assume too much about what's efficient, how things should be done, etc. but rather specific a fairly generic way of doing things and let the VM implementors do their VM-specific tweaks, as they are surely going to have to do anyway. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Mauve patches.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd really like to see my stuff committed, or commented on if just committing is unacceptable. Are there any people actually maintaining mauve? Nobody commented on the fixed needed for the website either. In short who is the core maintainer for mauve? On Tuesday 06 April 2004 10:46, Michael Koch wrote: Am Dienstag, 6. April 2004 09:56 schrieb Thomas: I've submitted several patches to both list and hear nothing; is there anyone who can comment/commit on these? We are all doing this in our freetime so we need some time nee out backlogs sometimes. Personally I have Mauve CVS access but I'm using not using ant so I cant really vote on your patch. I think Tom Tromey or Mark Wielaard will look into this in some days. If not please ping me and I will do it. Michael - -- Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdakLCojCW6H2z/QRAvPAAJ9VIVsdIvvJo9XvNIKvkKtho1FqgQCglYT1 004SB9mIxk/3Z8FF04TrxHE= =dK+F -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Mauve patches.
Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander: I'd really like to see my stuff committed, or commented on if just committing is unacceptable. Are there any people actually maintaining mauve? Nobody commented on the fixed needed for the website either. In short who is the core maintainer for mauve? Mauve has no real maintainer. There are just some people that commit stuff in a chaotic way. Michael On Tuesday 06 April 2004 10:46, Michael Koch wrote: Am Dienstag, 6. April 2004 09:56 schrieb Thomas: I've submitted several patches to both list and hear nothing; is there anyone who can comment/commit on these? We are all doing this in our freetime so we need some time nee out backlogs sometimes. Personally I have Mauve CVS access but I'm using not using ant so I cant really vote on your patch. I think Tom Tromey or Mark Wielaard will look into this in some days. If not please ping me and I will do it. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
The big NIO
Hi list, 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. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Support for installation of glibj.zip and separate class files
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
