RFC: make linking BC-compiled classes more lazy - part one

[Robert Schuster]

Hi Andrew,
thanks for reviewing this. I will fix all the issues you mentioned.

And for the records: The patch Andrew reviewed was *not* the one I posted
lately. Instead it is the verifier fix and both parts of my linker patch.

Thanks again for going through this rather big patch.

>>-  if (field_type == NULL)
>>-    throw new java::lang::NoClassDefFoundError(field_name->toString());
>>+  // Note: This call will resolve the primitive type names ("Z", "B", ...) to
>>+  // their Java counterparts ("boolean", "byte", ...) if accessed via
>>+  // field_type->name later. Using these variants of the type name is in turn
>>+  // important for the find_field_helper function. However if the class
> 
> 
> Two spaces after each full stop, please.  GNU coding convention.
Just a natural language issue: What is a full stop ?

>>       if (target_class == NULL)
>>-	throw new java::lang::NoClassDefFoundError 
>>-	  (_Jv_NewStringUTF (sym.class_name->chars()));
>>-      
>>+        {
>>+          ffi_closure *closure =
>>+            (ffi_closure *) _Jv_Malloc( sizeof( ffi_closure ));
>>+          ffi_cif *cif = (ffi_cif *) _Jv_Malloc( sizeof( ffi_cif ));
>>+
>>+          // Pretends that we want to call a void (*) (void) function via
>>+          // ffi_call.
>>+          ffi_type **arg_types = (ffi_type **) _Jv_Malloc( sizeof( ffi_type * ));
> 
> 
> We need to mprotect(PROT_READ | PROT_WRITE | PROT_EXEC) this memory or
> alloc it from the heap.
I am new to this. The specs for mprotect say that the memory region has to be
aligned at the page size. How is this being done efficiently and portably? I am
thinking about using the modulo division, the address and the page size. Is that
the way to go?

cya
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20051206/ce6b9371/attachment.sig>