Would it be possible for the allocator/GC to know what allocations are made within a request and make a generation for specifically for it? Allocations too big to fit would be made like usual
Since objects cannot be promoted to the old generation inside the request cycle, objects in the new gen are request allocated objects.
So if we were to eagerly trigger a minor GC after a request, we'd have very little objects to scan, and only need to sweep garbage, which is only a small fraction of time spent in GC.
Ah, that's a relief. It sounded incredibly scary if it was some new type of species just now. I would imagine that it would overwhelm our ecosystems wreaking havoc until a new balance is eventually found with new winners and new types of species dominating our environment.
I can't shake a vague memory that Java was named in an early brainstorming session with post-it notes on walls with tons of good and bad names, where eventually Java remained as the winner. I believe I've heard about this as a prime example of good brain storming methods from the early days when it wasn't at all obvious.
Does anybody know if this is right or if I'm confusing it with something else?
If you excuse some speculation:
(clarifications appreciated of course.)
If i remember correctly, ages ago (Windows Server 2003?) Microsoft introduced in-kernel HTTP-handling for the IIS web-server. I think it was for performance improvements with less copying between kernel- and user-space memory.
I suspect the for me unknown WinHTTP apis mentioned here could use these optimizations? Maybe that's why they mention security requirements? (Which would obviously be needed when doing parsing in the kernel.)
The security requirements are more due to trying to keep nasty things from being downloaded in the context of a game running on the Xbox. Games tend to run at fairly high privilege levels on Xbox, so Microsoft is probably worried mainly about jailbreaks.
The thing you're thinking about is http.sys and it was introduced in Windows 2008/IIS7 to support the new "Integrated Mode" request pipeline.
WinHTTP doesn't have anything to do with http.sys it just listens for HTTP requests and then hands them off to the right bits inside IIS.
WinHTTP is essentially a HTTP stack for client services running on Windows Server to allow them to make HTTP requests. It has a sibling API named WinINet which is aimed at use in desktop environments. I think the threading models are main differentiator (I been a while since I looked at this).
reply