From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner To: gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) Date: Wed, 08 Sep 1999 06:33:00 -0000 Message-id: References: <199909080607.IAA00513@mira.isdn.cs.tu-berlin.de> <199909080744.JAA00799@mira.isdn.cs.tu-berlin.de> X-SW-Source: 1999-09/msg00290.html "Martin v. Loewis" writes: > > Yes, keeping the offsets zero is required by the Java Virtual Machine > > specification. > > Hmm. Could you point me to the exact quote in the JVM spec? All over. For example the checkcast specification. And it is implicit in the description of the verifier, and the fact that there is no instruction to "widen" (up-cast?) a pointer. > > But certainly there is a wide-spread *presumption* in Java that > > neither up-casts and down-casts changes a pointer. > > Well, for Objects, that property is preserved. I'm talking about casts > to and from interfaces, here. What do you think I'm talking about? > > Furhermore, it is not possible to implement a "simple" Java > > interpreter if this assumption is violated. That is because there is > > no instruction in the JVM to convert a pointer whose type is a > > derived class to a pointer to one of its base classes or interfaces; > > this operation is assumed to be a no-op. The only option would be > > a "complex" interpreter, for example a Just-In-Time compiler (JIT), > > or something else that analyzes the whole method. > > I assume the 'simple' Java interpreter would iterate over a list of > implemented interfaces when making a call-to-interface. In this context, all I mean by "simple" interpreter is one that can execute a bytecode operation without first having analyzed the entire method. Fast method calls can still be compatible with that. In Gcj we use a slow search, but the traditional implementation uses a cache. > When passing an object to CNI code expecting an interface, you'd have > to cast. However, I think you could preserve the desired > single-pointer approach for the byte code interpreter, and still use > the virtual-base approach in native code. No, I don't think so. A pointer is a pointer. If we have an array of interface pointers, we can't represent that differently depending on whether we pass it to a compiled method or an interpreted method. > For C++, the primary goals would be speed-efficiency and compact > representation. I don't think any of these alternatives would be more > efficient than vtable calls. My proposed design is *more* space-efficient than the traditional C++ implementation, because it does not use extra per-object vtable pointers. My guess it would be a couple of instructions slower, but I'm not sure. It would still be constant-time, and in-line. I put my design up on http://www.bothner.com/~per/jv-inherit.txt -- --Per Bothner bothner@pacbell.net per@bothner.com http://www.bothner.com/~per/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner To: gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: References: <199909080607.IAA00513@mira.isdn.cs.tu-berlin.de> <199909080744.JAA00799@mira.isdn.cs.tu-berlin.de> X-SW-Source: 1999-09n/msg00290.html Message-ID: <19990930180200.b4ZtVcd0BhSLbyFtuOD1e5TQ-vqQFHb4xuaPm8sQ97M@z> "Martin v. Loewis" writes: > > Yes, keeping the offsets zero is required by the Java Virtual Machine > > specification. > > Hmm. Could you point me to the exact quote in the JVM spec? All over. For example the checkcast specification. And it is implicit in the description of the verifier, and the fact that there is no instruction to "widen" (up-cast?) a pointer. > > But certainly there is a wide-spread *presumption* in Java that > > neither up-casts and down-casts changes a pointer. > > Well, for Objects, that property is preserved. I'm talking about casts > to and from interfaces, here. What do you think I'm talking about? > > Furhermore, it is not possible to implement a "simple" Java > > interpreter if this assumption is violated. That is because there is > > no instruction in the JVM to convert a pointer whose type is a > > derived class to a pointer to one of its base classes or interfaces; > > this operation is assumed to be a no-op. The only option would be > > a "complex" interpreter, for example a Just-In-Time compiler (JIT), > > or something else that analyzes the whole method. > > I assume the 'simple' Java interpreter would iterate over a list of > implemented interfaces when making a call-to-interface. In this context, all I mean by "simple" interpreter is one that can execute a bytecode operation without first having analyzed the entire method. Fast method calls can still be compatible with that. In Gcj we use a slow search, but the traditional implementation uses a cache. > When passing an object to CNI code expecting an interface, you'd have > to cast. However, I think you could preserve the desired > single-pointer approach for the byte code interpreter, and still use > the virtual-base approach in native code. No, I don't think so. A pointer is a pointer. If we have an array of interface pointers, we can't represent that differently depending on whether we pass it to a compiled method or an interpreted method. > For C++, the primary goals would be speed-efficiency and compact > representation. I don't think any of these alternatives would be more > efficient than vtable calls. My proposed design is *more* space-efficient than the traditional C++ implementation, because it does not use extra per-object vtable pointers. My guess it would be a couple of instructions slower, but I'm not sure. It would still be constant-time, and in-line. I put my design up on http://www.bothner.com/~per/jv-inherit.txt -- --Per Bothner bothner@pacbell.net per@bothner.com http://www.bothner.com/~per/