Subclassing CompiledMethod

Is my observation correct that CompiledMethod cannot be subclassed?

I was trying to port John Brant's MethodWrapper package from VisualWorks to
Dolphin, and made the following observations:

The Compiler always generates CompiledMethod objects, you can't tell it
which class it should use (VW has SmalltalkCompiler>>methodClass).  This can
be solved by using a constructor method for the CompiledMethod subclass that
copies the named and indexed instance variables from the new method object.

It doesn't work for classes that have a different shape than CompiledMethod,
i. e. have instance variables added to it.  The position of the literal
frame has changed; the memory layout is not the same as for CompiledMethods
and so the VM gets confused.

(There are ways to still implement wrappers -- class variables or an
extended indexed var section could be used)

What do you think of this?  Is there a chance that in a future release the
CompiledMethod might be subclassable?

BTW, I'm still enjoying your great product -- how come everybody says that?
:-)

Cheers,
Andreas

Andreas,

> It doesn't work for classes that have a different shape than
CompiledMethod,
> i. e. have instance variables added to it.  The position of the literal
> frame has changed; the memory layout is not the same as for
CompiledMethods
> and so the VM gets confused.

I don't have recent confirmation from OA on this, but, there at least were
classes that were not to be subclassed, and I suspect that this persists.
If you search the newsgroup archives, you'll run across more detail, but, it
basically went something like this: "the VM knows the layout of certain
classes, such as Process, Semaphore, immediate objects, and (you should
probably assume) anything that contains a large number of primitive
methods".  It makes sense (IMHO at least) that the boundary between the VM
and the image would require some restrictions.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Andreas Timmermann" <[hidden email]> wrote in message
news:99gckj$gco$05$[hidden email]...
> Is my observation correct that CompiledMethod cannot be subclassed?
>
> I was trying to port John Brant's MethodWrapper package from VisualWorks
to
> Dolphin, and made the following observations:
>
> The Compiler always generates CompiledMethod objects, you can't tell it
> which class it should use (VW has SmalltalkCompiler>>methodClass).  This
can
> be solved by using a constructor method for the CompiledMethod subclass
that
> copies the named and indexed instance variables from the new method
object.
>
> It doesn't work for classes that have a different shape than
CompiledMethod,
> i. e. have instance variables added to it.  The position of the literal
> frame has changed; the memory layout is not the same as for
CompiledMethods
> and so the VM gets confused.
>
> (There are ways to still implement wrappers -- class variables or an
> extended indexed var section could be used)

VisualAge also has this problem. Instead of creating subclasses for VA, I
made MethodWrapper a subclass of Object. I just compiled normal methods, and
inserted the wrapper into the normal CompiledMethod (instead of inserting
the method itself). This is only slightly less efficient since it requires
two objects instead of one, but it should work for Dolphin.


John Brant

John,

> VisualAge also has this problem. Instead of creating subclasses for VA, I
> made MethodWrapper a subclass of Object. I just compiled normal methods,
and
> inserted the wrapper into the normal CompiledMethod (instead of inserting
> the method itself). This is only slightly less efficient since it requires
> two objects instead of one, but it should work for Dolphin.

Excellent idea, thanks for sharing!  This should be easily done.
I'll share the code with anybody interested.

Cheers,
Andreas

VisualAge does not prevent you from subclassing CompiledMethod, this
is what I did when I developed some CompiledMethod wrappers (and is
also how Envy breakpoints work in VA.

It may be that the VM "knows" the layout of CompiledMethod and so you cannot
add any new instVars (I did not try this). However do just what I did (and the
breakPoint implementation) and when you create the Wrapper make the literal
frame a few slots bigger then required and add any extra needed info here :o).

Cheers
Ian


John Brant wrote:

"Ian Meikle" <[hidden email]> wrote in message
news:[hidden email]...
> VisualAge does not prevent you from subclassing CompiledMethod, this
> is what I did when I developed some CompiledMethod wrappers (and is
> also how Envy breakpoints work in VA.

Yes, you can create a subclass of CompiledMethod in VisualAge. However, you
cannot add an instance variable without having to adjust the literals by the
number of instance variables added. For example, if you add three instance
variables, you will need to generate a method that has three literals that
aren't used. This is very difficult to do in VA, since it likes to remove
dead literals.

You can also create a subclass of CompiledMethod in Dolphin, and like VA if
you add an instance variable, you must adjust the literals for this instance
variable. When it comes to extending the methods, both Dolphin and VA have
roughly the same problems.

> It may be that the VM "knows" the layout of CompiledMethod and so you
cannot
> add any new instVars (I did not try this). However do just what I did (and
the
> breakPoint implementation) and when you create the Wrapper make the
literal
> frame a few slots bigger then required and add any extra needed info here
:o).

You can do this, but it far from optimal. For example, compare the code in
the CompiledMethod for the filePointer between VisualAge and VisualWorks. In
VisualWorks, there is an instance variable that contains the filePointer to
the ENVY record, but in VisualAge, the filePointer is stored in the last
literal position and a flag must be set. This flag tells the code whether
the last literal is the filePointer or whether it is some normal method
literal. Even the flag isn't an instance variable of compiled method.
Instead the flag is part of the compiled method's basic hash.


John Brant