This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: PATCH: Reduce allocation overhead, fix IA64 GC descriptors


Tom -

I tried this patch, together with taking out the IA64-specific code from
_Jv_AllocObject.  That seems to be fine, except that your code needs a cast
in the IA64 implementation of get_finalizer().  I used (in include/jvm.h):

#ifdef __ia64__
  void *get_method(int i) { return &method[i]; }
  void set_method(int i, void *fptr) { method[i] = *(vtable_elt *)fptr; }
  void *get_finalizer()
  {
    // We know that get_finalizer is only used for checking whether
    // this object needs to have a finalizer registered.  So it is
    // safe to simply return just the PC component of the vtable
    // slot.
    return ((vtable_elt *)(get_method(0)))->pc;
  }
#else
  void *get_method(int i) { return method[i]; }
  void set_method(int i, void *fptr) { method[i] = fptr; }
  void *get_finalizer() { return get_method(0); }
#endif

How do you want to proceed?  Should I check in just the run-time changes?
Do you want to do it?

Are there correctness concerns with the front-end changes other than the way
class_has_finalize_method() is written?  If that's the only concern, I would
argue for checking in the front-end changes as well.  The controversial code
there seems to be isolated, and it's easy to replace if someone thinks of a
better way to do it.  It's also easy to stub out by having it always return
true, if there turns out to be a serious problem.  I'd be happy to add
comments to that effect. 

In any case, it would be nice to check in the class.c change to the
front-end, since the current code is broken in the
TARGET_VTABLE_USES_DESCRIPTORS case.  And, in spite of my earlier statement,
that part is only somewhat separable from the runtime changes.  (I think
that checking in only the runtime changes would break every Java program on
IA64.  Currently only those that allocate enough to garbage collect are
broken.  I'm not sure whether that's an improvement or a regression,
actually.)

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> ...
> How does the appended look?
> 
> As I understand it the different parts of your patch are separable.
> Let's get the parts that don't require compiler changes in separately.
> 
> Tom
> 
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
> 	* include/jvm.h (_Jv_VTable::get_finalizer): Now conditional on
> 	__ia64__.
> 
> Index: include/jvm.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/libjava/include/jvm.h,v
> retrieving revision 1.45
> diff -u -r1.45 jvm.h
> --- include/jvm.h 2001/10/23 05:42:03 1.45
> +++ include/jvm.h 2001/11/22 20:42:33
> @@ -48,12 +48,20 @@
>  #ifdef __ia64__
>    void *get_method(int i) { return &method[i]; }
>    void set_method(int i, void *fptr) { method[i] = 
> *(vtable_elt *)fptr; }
> +  void *get_finalizer()
> +  {
> +    // We know that get_finalizer is only used for checking whether
> +    // this object needs to have a finalizer registered.  So it is
> +    // safe to simply return just the PC component of the vtable
> +    // slot.
> +    return get_method(0)->pc;
> +  }
>  #else
>    void *get_method(int i) { return method[i]; }
>    void set_method(int i, void *fptr) { method[i] = fptr; }
> +  void *get_finalizer() { return get_method(0); }
>  #endif
>  
> -  void *get_finalizer() { return get_method(0); }
>    static size_t vtable_elt_size() { return sizeof(vtable_elt); }
>    static _Jv_VTable *new_vtable (int count);
>  };
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]