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]

Re: preliminary invocation patch


>>>>> "Per" == Per Bothner <per@bothner.com> writes:

>> I wonder if there is an easy(-ish) way to make it so that this code
>> can continue to remain in sync with Classpath as well.

Per> Well, our String uses native code, and with append(int) using
Per> _Jv_FormatInt StringBuffer would also use native code, so I guess
Per> not.

We could have StringBuffer.append(int) call a method elsewhere that
expects a buffer and offset argument.  For instance it could call a
package-private method on String or Integer.  This method could have
different implementations in Classpath and libgcj.

Per> I suspect Classpath synchronization is less relevant for
Per> java.lang anyway.

Full synchronization is an ideal.  For some things we already know we
won't achieve it.  For instance we aren't planning to ever synchronize
String.

The more we have synchronized, the easier maintenance becomes.  That's
because we can merge in either direction with fewer special cases.  So
I think the default should be to synchronize.

In this particular case, right now it might make sense to diverge.  In
the long term I would like to replace our compiler-generated uses of
StringBuffer with calls to a new unsynchronized StringBuffer-like
class.  At this point StringBuffer itself will be less important, and
so we might choose to resync it.

Tom


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