Take a look at Steven Kamradt’s idea a few posts up. If CodeGear does something like this, there shouldn’t ever have to be a "next time". I hope.

But still, the virtual-memory limit on win32 will now be reached sooner than before (even more so now that string has become UTF16 encoded). Not many applications will notice this, sure. But some will. That’s why I would have expected that a change like this had been communicated more clearly.
Also, I don’t see why this was actually released together with Tiburon. There’s no documentation or mention of the new TMonitor functionality either (unless I’ve somehow missed this?)

And on top of all that, there’s no feasible way to get back the original InstanceSize!

I already discussed some options with Hallvard Vassbotn, like patching TObject.GetInstanceSize (which won’t work, as that’s marked ‘inline’ now) or patching TObject.NewInstance (which could work - allocation-wise, but would still report the wrong InstanceSize). In any case, we would have to nullify TMonitor.DestroyObject (or what’s-it’s-name). Last resort would be to detect all classes early in the initialization phase, and decrease all vmtInstanceSize values by 4. None of this is a ‘clean’ ‘fix’, so it would have been nicer if this increase was either left out, or was done via a project-option or some such.

For now, I guess most people will probably accept this without much objections. (I suspect I too won’t even bother patching this.) But I do hope that next time (if you can speak of a ‘next time’ for things like this) we’d be informed beforehand, and where offered a choice. (Actually, the Unicode-move is a great example, as we can still use AnsiString if we wish to do so).

No, I have not noticed a lot of people complaining about this. Indeed, few people seem to have even noticed. It is certainly small next to the increase in size of string instances to support Unicode.

But the basic facts about the desktop computing market today are:

1. Hyper-threading, multicore, and multi-CPU are the rule, not the exception.
2. Unicode is the rule, not the exception (e.g., the web and Windows are both Unicode at the core)
3. Memory is cheaper than it has ever been, and it keeps getting cheaper (at least, if you’re not so unfortunate as to own a machine with Rambus memory…)

I didn’t realize it at that time, but it never occurred to me Allan’s TMonitor experiments where meant to be actually released with Delphi 2009. Only nowI discover InstanceSize changed to 8 bytes (thanks Mason), without a mention anywhere (or was it?)!

Am I the only one getting freaked out about this?!

Our application allocates literally hundreds of millions of instances… if it wasn’t for our own instance-pool (which works with fixed instance sizes), this would have meant a killing increase in memory-usage!
Surely others must get EOutOfMemory too now that they start releasing Delphi 2009 builds of there software?!?

I wish this was communicated more openly, and a fallback to the original InstanceSize was kept possible (because seriously, how many of you are already using the new TMonitor design?)

Oh well. If they’re going to delay things, I really hope they can find time to include fixes for QC #s 72070 and 71837 in there. Bad VCL code or strange generics quirks that don’t always compile right are bad enough, but when the compiler silently creates a bad binary, that’s a critical error IMO.

Thanks for the link, Craig. I just hope I don’t get a bunch of people wandering in, glancing around for a second, saying "hey, this isn’t a programming blog!" and then leaving again.

The feature you describe would be convenient, although I haven’t thought through what the downsides might be. One significant downside is that it is not in the product today. Allen seemed to imply that such a feature could happen in the future, though.