Regarding the original motivation for squooshed compiled methods, the story I heard that it was primarily to save OOPS, not bytes. A 16-bit object table VM let you allocate 32K objects total, of which ~15K were taken by the base image. Of those, something like 7K were CMs. Separate objects for bytecodes and literals would run application writers clean out of objects.

Cheers,

Kent

http://rdrvr.blogspot.com/2008/08/hacking-compiledmethod-allocating-space.html

David

Why not redesign CM format from scratch then? I think this is the case where you sacrifice too much for backward compatibility.

Second: I doubt that CM needs subclassing.
AFAIK, Squeak allows to put arbitrary object in method dictionary, and then if VM discovers such abnormal thing, its just encapsulates arguments into a MessageSend and sends #performMessage: (if i remember correctly) message to that object.
So, this is a nice and already present way to circumvent rigid CM format: for those who wants, they could use such scheme – just put own arbirtary object into a method dict and then do whatever is needed within a message handling method.
Its maybe not fast, but flexible and does not requires too much mumbo-jumbo at VM level.

My own preference: keep VM as stupid as possible, and let complex and clever things live at language side instead.