Why Continuations Are Coming to Java • Hacker News Board

Re: Why Continuations Are Coming to Java

#181

Post by giancarlostoro » Wed, Jul 03, 2019, 5:23 PM UTC

pron wrote: post #161

giancarlostoro wrote: post #81

Earlier quoted context omitted.

Any idea how these fibers compare to the ones used by D as well? I also wonder if this means Kotlin will adopt Fibers since it does build on top of JVM capabilities.

I don't know D; I also don't currently know what Kotlin's plans are.

Fair enough, I know D has fibers, but I'm not sure how different implementations are between languages in regards to fibers. As for Kotlin it was more of a personal reflection, that is fine if you don't know.

Thanks for answering though, I look forward for this. I shared it accross a number of dev communities I frequent and one joke was "java and lightweight in the same sentence" which made me chuckle since I know Fibers are amazing.

Re: Why Continuations Are Coming to Java

#182

Post by brighter2morrow » Wed, Jul 03, 2019, 6:21 PM UTC

rileyphone wrote: post #121

twic wrote: post #27

> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…

There is a Project Loon somewhere, it's a google attempt to deliver internet through balloons.

More bandwidth than Comcast

Re: Why Continuations Are Coming to Java

#183

Post by chrisseaton » Wed, Jul 03, 2019, 11:30 PM UTC

garmaine wrote: post #170

chrisseaton wrote: post #166

Earlier quoted context omitted.

Again, there's plenty of address space in 48 bits, but you need to commit physical memory in order to allocate the space for the page table for that address space. And that's per-process, and it's going to thrash the TLB.

That's not how the OS's page management tables work. The OS assigns space for the stack at a (typically random) location in the process' address space, but no physical allocation is made. The very first time the stack is used a page fault exception is generated, causing a context switch to the OS. Only then does the memory management subsystem allocate a page for the stack and return control back to the program. Hand…

> The one major point of difference is that to make an address allocation in the page table doesn't require a physical allocation

No it does require a physical allocation. The page table entry for the new virtual memory needs to be a physical allocation!

People say 'you can have 256 TB of virtual memory'! Yes you can, but you will need 256 GB of physical memory to hold the page table for that, won't you, assuming 4 KB pages, even if none of that 256 TB is committed to physical memory.

You say 'that's not how the OS's page management tables work' - yes it is! Look up Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3, Chapter 4, formats of page-directory entry and page-table entry. It's committed memory.

Re: Why Continuations Are Coming to Java

#184

Post by cetpa » Thu, Jul 04, 2019, 5:47 AM UTC

JAVA is threaded go down to the OS level and is relatively resource-expensive (RAM and context switching) so don't scale well. If you want to know more visit CETPA INFOTECH PVT LTD

Re: Why Continuations Are Coming to Java

#185

Post by garmaine » Sat, Jul 06, 2019, 5:38 PM UTC

chrisseaton wrote: post #183

garmaine wrote: post #170

Earlier quoted context omitted.

That's not how the OS's page management tables work. The OS assigns space for the stack at a (typically random) location in the process' address space, but no physical allocation is made. The very first time the stack is used a page fault exception is generated, causing a context switch to the OS. Only then does the memory management subsystem allocate a page for the stack and return control back to the program. Hand…

> The one major point of difference is that to make an address allocation in the page table doesn't require a physical allocation No it does require a physical allocation. The page table entry for the new virtual memory needs to be a physical allocation! People say 'you can have 256 TB of virtual memory'! Yes you can, but you will need 256 GB of physical memory to hold the page table for that, won't you, assuming 4 K…

You don't have to allocate a page on the table for an area of memory that is not physically allocated at all. Yes, accessing it will trap to the operating system, but that's the entire point.