RE: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger(compressed)
Raif S. Naffah wrote: the attached patch adds support for GNU MP in BigInteger if/when configured. How/why is the native version better? Is it really worthwhile to complicate the code this way? Where are the benchmarks that prove the native code is faster? I assume it is already widely know that I dislike native code (because of how IKVM works), but let me try to explain why native code sucks for all VMs: - Some VMs are hardened against stack overflow, this means that stack overflow in Java or VM code will not result in terminating the process, but simply a StackOverflowException. Is the native code you are introducing similarly harneded? - Some VMs are hardened against OOM, this means that memory allocation failures (both in Java and in the VM) will not result in terminating the process, but simply a OutOfMemoryError. Is the native code you are introducing similarly harneded? - Native memory allocation potentially fragments the heap and this can have significant performance implications. - Can you prove there aren't any security holes in your native code? Most people do not understand the (security) implications of using native code in combination with handles and most of the code out there is simply wrong (as is the current patch). See [1]. Regards, Jeroen [1] http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pd f
Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger (compressed)
hello Robert, On Sunday 03 September 2006 15:26, Robert Lougher wrote: Hi, What architecture were you running JamVM on? here is the uname related lines in my jamvm config.log: uname -m = i686 uname -r = 2.6.17-1.2174_FC5smp uname -s = Linux uname -v = #1 SMP Tue Aug 8 16:00:39 EDT 2006 cheers; rsn pgpDx62OSIWcJ.pgp Description: PGP signature
Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger(compressed)
hello Jeroen, On Sunday 03 September 2006 18:02, Jeroen Frijters wrote: ... How/why is the native version better? Is it really worthwhile to complicate the code this way? Where are the benchmarks that prove the native code is faster? the attractiveness of the native code is performance. to quickly see how the new methods improve for example RSA key generation, one can modify the code in TestOfRSAKeyGeneration (Mauve) to call the generate() method N times and print the duration --on my machine i get for 5 rounds: + with GMP969ms. - without GMP 11,718ms. I assume it is already widely know that I dislike native code (because of how IKVM works), but let me try to explain why native code sucks for all VMs: - Some VMs are hardened against stack overflow, this means that stack overflow in Java or VM code will not result in terminating the process, but simply a StackOverflowException. Is the native code you are introducing similarly harneded? no it is not. - Some VMs are hardened against OOM, this means that memory allocation failures (both in Java and in the VM) will not result in terminating the process, but simply a OutOfMemoryError. Is the native code you are introducing similarly harneded? no it is not. - Native memory allocation potentially fragments the heap and this can have significant performance implications. - Can you prove there aren't any security holes in your native code? there are none to my knowledge. Most people do not understand the (security) implications of using native code in combination with handles and most of the code out there is simply wrong (as is the current patch). See [1]. i'll have to read this document first. Regards, Jeroen [1] http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pd f -- cheers; rsn pgp6yVFG73SSP.pgp Description: PGP signature
Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger(compressed)
hello Sven, On Sunday 03 September 2006 19:46, Sven de Marothy wrote: On Sun, 2006-09-03 at 10:02 +0200, Jeroen Frijters wrote: Raif S. Naffah wrote: the attached patch adds support for GNU MP in BigInteger if/when configured. How/why is the native version better? Is it really worthwhile to complicate the code this way? Where are the benchmarks that prove the native code is faster? Valid questions, indeed... indeed. see my previous reply to Jeroen about the performance. ... What I'd like to propose here is that in any case, the choice of implementation should be strictly a build-time option, and the two implementations kept entirely seperate. i thought having the java code in one place is clearer, and helps showing the common elements... but this is my opinion. I'm not very happy about the alternatives: Having two implementations in one class (as in the proposed patch), or moving the actual impl into yet another VM* class. (Indeed I've been increasingly critical recently over that part. I've still not worked out an exact solution, but suffice to say that I'll be proposing some changes in that area soon). from the sound of it, it looks like now is the time! Anyway enough disgression, I hope I didn't sound harsh, Raif! :)... not at all. cheers; rsn pgp1XgzgloFe0.pgp Description: PGP signature
RE: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger(compressed)
Raif S. Naffah wrote: the attractiveness of the native code is performance. to quickly see how the new methods improve for example RSA key generation, one can modify the code in TestOfRSAKeyGeneration (Mauve) to call the generate() method N times and print the duration --on my machine i get for 5 rounds: + with GMP969ms. - without GMP 11,718ms. Hmm. That is indeed significant. However, looking at the profile for generate(), it spends nearly all its time in BigInteger.isProbablePrime() and I ran a few comparisons between our implementation of isProbablePrime() and Sun's and we're not that much slower (on IKVM only about 50% slower), I'm not sure what to make of that. - Can you prove there aren't any security holes in your native code? there are none to my knowledge. The finalizer looks dangerous. For example, a subclass could call finalize multiple times, resulting in multiple calls to free() (which may or may not be exploitable). Note that you cannot solve this by only fixing the finalizer (see the PDF I linked to previously). Regards, Jeroen
Re: Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger (compressed)
Hi, Try commenting out the code in the function: setDoublePrecision() located in jamvm/src/os/linux/i386/init.c This changes the precision of the FPU to 64 bits from extended 80-bit precision which is the Linux default. This is necessary to completely conform to the Java specification. See http://www.vinc17.org/research/extended.en.html for a bug report on various OS VMs. GMP appears to be very sensitive to the compiler used. I would guess it would also produce wrong results if the processor mode was changed. Perhaps cacao does not do this. Can you also try the test given in the above page? Thanks, Rob. On 9/3/06, Raif S. Naffah [EMAIL PROTECTED] wrote: hello Robert, On Sunday 03 September 2006 15:26, Robert Lougher wrote: Hi, What architecture were you running JamVM on? here is the uname related lines in my jamvm config.log: uname -m = i686 uname -r = 2.6.17-1.2174_FC5smp uname -s = Linux uname -v = #1 SMP Tue Aug 8 16:00:39 EDT 2006 cheers; rsn
[cp-patches] FYI:HTML parser leading/trailing space fix
Roman reported that the HTML parser eats too much whitespace: the
sequence like
b text /b must be parsed preserving at most one leading and trailing
space
(now all are discarded). As this is an interpretation and not a
programming bug,
this patch may break existing HTML parser tests that require complete
discarding of the word surrounding whitespace. These tests should be
corrected
later.
2006-09-03 Audrius Meskauskas [EMAIL PROTECTED]
* gnu/javax/swing/text/html/parser/HTML_401F.java (defineElements):
Disallow H1 - H6 in the paragraphs.
* gnu/javax/swing/text/html/parser/support/textPreProcessor.java
(preprocess): Leave at most one leading and/or trailing space.
* javax/swing/text/html/HTMLDocument.java (HTMLReader.handleText):
Do not add any text after closing the HTML tag.
### Eclipse Workspace Patch 1.0
#P classpath
Index: javax/swing/text/html/HTMLDocument.java
===
RCS file: /sources/classpath/classpath/javax/swing/text/html/HTMLDocument.java,v
retrieving revision 1.40
diff -u -r1.40 HTMLDocument.java
--- javax/swing/text/html/HTMLDocument.java 25 Aug 2006 11:40:44 - 1.40
+++ javax/swing/text/html/HTMLDocument.java 3 Sep 2006 20:31:04 -
@@ -1181,7 +1181,7 @@
*/
public void handleText(char[] data, int pos)
{
- if (data != null data.length 0)
+ if (shouldInsert() data != null data.length 0)
addContent(data, 0, data.length);
}
Index: gnu/javax/swing/text/html/parser/HTML_401F.java
===
RCS file: /sources/classpath/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java,v
retrieving revision 1.4
diff -u -r1.4 HTML_401F.java
--- gnu/javax/swing/text/html/parser/HTML_401F.java 16 Jul 2006 15:03:08 - 1.4
+++ gnu/javax/swing/text/html/parser/HTML_401F.java 3 Sep 2006 20:31:01 -
@@ -2445,8 +2445,10 @@
attr(VALUE, null, null, 0, IMPLIED)
}
);
+
+ // Headers in the paragraph are not allowed.
defElement(P, 0, false, true, new ContentModel( 0,
- new noTagModel(P), null),
+ new noTagModel(new String[] { P, H1, H2, H3, H4, H5, H6 }), null),
NONE
,
new String[] {
Index: gnu/javax/swing/text/html/parser/support/textPreProcessor.java
===
RCS file: /sources/classpath/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java,v
retrieving revision 1.2
diff -u -r1.2 textPreProcessor.java
--- gnu/javax/swing/text/html/parser/support/textPreProcessor.java 2 Jul 2005 20:32:15 - 1.2
+++ gnu/javax/swing/text/html/parser/support/textPreProcessor.java 3 Sep 2006 20:31:01 -
@@ -42,17 +42,17 @@
/**
* Pre - processes text in text parts of the html document.
- * Not thread - safe.
+ *
* @author Audrius Meskauskas, Lithuania ([EMAIL PROTECTED])
*/
public class textPreProcessor
{
/**
- * Pre - process non-preformatted text.
- * \t, \r and \n mutate into spaces, then multiple spaces mutate
- * into single one, all whitespace around tags is consumed.
- * The content of the passed buffer is destroyed.
- * @param text A text to pre-process.
+ * Pre - process non-preformatted text. \t, \r and \n mutate into spaces, then
+ * multiple spaces mutate into single one, all whitespace around tags is
+ * consumed. The content of the passed buffer is destroyed.
+ *
+ * @param a_text A text to pre-process.
*/
public char[] preprocess(StringBuffer a_text)
{
@@ -64,17 +64,22 @@
int a = 0;
int b = text.length - 1;
+// Remove leading/trailing whitespace, leaving at most one character
try
{
-while (Constants.bWHITESPACE.get(text [ a ]))
+while (Constants.bWHITESPACE.get(text[a])
+Constants.bWHITESPACE.get(text[a + 1]))
a++;
-while (Constants.bWHITESPACE.get(text [ b ]))
+
+while (b a Constants.bWHITESPACE.get(text[b])
+Constants.bWHITESPACE.get(text[b - 1]))
b--;
}
catch (ArrayIndexOutOfBoundsException sx)
{
-// A text fragment, consisting from line breaks only.
-return null;
+// A text fragment, consisting from spaces and line breaks only,
+// mutates into single space.
+return new char[] { ' ' };
}
a_text.setLength(0);
@@ -83,10 +88,9 @@
boolean spaceNow;
char c;
-chars:
-for (int i = a; i = b; i++)
+chars: for (int i = a; i = b; i++)
{
-c = text [ i ];
+c = text[i];
spaceNow = Constants.bWHITESPACE.get(c);
if (spacesWere spaceNow)
continue chars;
