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 GMP 969ms. - 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
