www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - really good talk about the Hotspot VM

reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
This talk is really good and contains a lot of usefull 
information very densly packed:
https://www.youtube.com/watch?v=vzzABBxo44g

The speaker has 30 years of experience working on javas hotspot 
vm and shares his opinions on what you should do. My takeaways 
from this talk are:

GC:
-You want a fully percise GC (e.g. know _all_ pointers even the 
ones on the stack), the benenift outweights the cost for tracking 
pointers.
-You do not want to pin allocations in the gc heap as it is to 
restrictive for your gc implementation.
-GC safepoints worked out really well.

TLS:
To get fast thread local storage, align the start of the stack so 
you can chop of a few bits of the stack pointer to get to the 
TLS-section. We might be able to use this on platforms with slow 
TLS?

Kind Regards
Benjamin Thaut
Jul 16 2015
next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
On Thu, 16 Jul 2015 17:30:05 +0000, Benjamin Thaut wrote:


 The speaker has 30 years of experience working on javas hotspot vm


How is this possible?  Time travel?
Jul 16 2015
next sibling parent "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote:

 On Thu, 16 Jul 2015 17:30:05 +0000, Benjamin Thaut wrote:


 The speaker has 30 years of experience working on javas 
 hotspot vm


 How is this possible?  Time travel?


I confused that one. He actually states that he has 35 years of 
experience building compilers and 20 years on the Hotspot VM, 
which still is a huge amount of experience.
Jul 16 2015
prev sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote:

 On Thu, 16 Jul 2015 17:30:05 +0000, Benjamin Thaut wrote:


 The speaker has 30 years of experience working on javas 
 hotspot vm


 How is this possible?  Time travel?


was wondering the same :D
Jul 16 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 17 July 2015 at 06:51:27 UTC, extrawurst wrote:

 On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote:

 On Thu, 16 Jul 2015 17:30:05 +0000, Benjamin Thaut wrote:


 The speaker has 30 years of experience working on javas 
 hotspot vm


 How is this possible?  Time travel?


 was wondering the same :D


It wasn't the case, but it could have been possible as the 
starting point for HotSpot VM was developed for other languages 
than Java.

If you look at the first point:
    "HotSpot started as a Self VM ported to Java"

Self is 28 years old and had eventually a VM based on a 
Strongtalk VM by another company that begun development 21 years 
ago. Sun bought it 18 years ago and released HotSpot 16 years ago.

https://en.wikipedia.org/wiki/Strongtalk
https://code.google.com/p/strongtalk/

(Lars Bak worked on Strongtalk VM,  HotSpot, V8 and Dart VM… so 
they are probably related designwise, one way or another.)
Jul 17 2015
parent "extrawurst" <stephan extrawurst.org> writes:
On Friday, 17 July 2015 at 07:36:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 17 July 2015 at 06:51:27 UTC, extrawurst wrote:

 On Thursday, 16 July 2015 at 17:37:44 UTC, Justin Whear wrote:

 [...]


 was wondering the same :D


 It wasn't the case, but it could have been possible as the 
 starting point for HotSpot VM was developed for other languages 
 than Java.

 If you look at the first point:
    "HotSpot started as a Self VM ported to Java"

 Self is 28 years old and had eventually a VM based on a 
 Strongtalk VM by another company that begun development 21 
 years ago. Sun bought it 18 years ago and released HotSpot 16 
 years ago.

 https://en.wikipedia.org/wiki/Strongtalk
 https://code.google.com/p/strongtalk/

 (Lars Bak worked on Strongtalk VM,  HotSpot, V8 and Dart VM… so 
 they are probably related designwise, one way or another.)


Interesting insights! Thank you!
Jul 17 2015
prev sibling next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote:

 This talk is really good and contains a lot of usefull 
 information very densly packed:
 https://www.youtube.com/watch?v=vzzABBxo44g

 [...]


Treating D's GC the same as a managed language running in a VM's 
GC will only end in disappointment.
Jul 16 2015
parent reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:

 On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote:

 This talk is really good and contains a lot of usefull 
 information very densly packed:
 https://www.youtube.com/watch?v=vzzABBxo44g

 [...]


 Treating D's GC the same as a managed language running in a 
 VM's GC will only end in disappointment.


Why? The only real difference is that a java vm generates the 
machine code during runtime while the D compiler generates the 
machine code ahead of time. The underlying implementation of the 
important GC parts (e.g. pointer discovery, safe points, etc) are 
still the same. And if you look for a state of the art GC, they 
only exist for VMs. I don't know any other compiled language with 
a GC you could compare against.
Jul 16 2015
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 16 July 2015 at 21:04:33 UTC, Benjamin Thaut wrote:

 On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:

 On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut 
 wrote:

 This talk is really good and contains a lot of usefull 
 information very densly packed:
 https://www.youtube.com/watch?v=vzzABBxo44g

 [...]


 Treating D's GC the same as a managed language running in a 
 VM's GC will only end in disappointment.


 Why? The only real difference is that a java vm generates the 
 machine code during runtime while the D compiler generates the 
 machine code ahead of time. The underlying implementation of 
 the important GC parts (e.g. pointer discovery, safe points, 
 etc) are still the same. And if you look for a state of the art 
 GC, they only exist for VMs.


Not even that, as there are AOT compilers for Java, so VM == 
language runtime.

With the ongoing work on Graal and Substrate, even Oracle might 
be supporting AOT on the reference implementation.

For me the best part was he saying nowadays he would just 
bootstrap Java, not use C or C++.


 I don't know any other compiled language with a GC you could 
 compare against.


.NET? Given that they offer NGEN, MDIL and now .NET Native, 
besides JIT.

4.6 is also bringing new GC improvements.

--
Paulo
Jul 16 2015
prev sibling next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 16 July 2015 at 21:04:33 UTC, Benjamin Thaut wrote:

 On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:

 On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut 
 wrote:

 This talk is really good and contains a lot of usefull 
 information very densly packed:
 https://www.youtube.com/watch?v=vzzABBxo44g

 [...]


 Treating D's GC the same as a managed language running in a 
 VM's GC will only end in disappointment.


 Why? The only real difference is that a java vm generates the 
 machine code during runtime while the D compiler generates the 
 machine code ahead of time. The underlying implementation of 
 the important GC parts (e.g. pointer discovery, safe points, 
 etc) are still the same. And if you look for a state of the art 
 GC, they only exist for VMs. I don't know any other compiled 
 language with a GC you could compare against.


If you have a way to implement self-healing code in D please 
share it. Or forwarding pointers, or card marking, or read/write 
barriers without abusing the MMU(which is dog slow,) or...

Any of these would require massive changes to D that will never 
happen. But while everyone is tripping over themselves to try and 
copy something that will *not* work in D, they refuse to 
acknowledge what massive benefits D's GC can provide over Java's.
Jul 16 2015
next sibling parent "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 16 July 2015 at 22:23:41 UTC, rsw0x wrote:

 On Thursday, 16 July 2015 at 21:04:33 UTC, Benjamin Thaut wrote:

 On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:

 [...]


 Why? The only real difference is that a java vm generates the 
 machine code during runtime while the D compiler generates the 
 machine code ahead of time. The underlying implementation of 
 the important GC parts (e.g. pointer discovery, safe points, 
 etc) are still the same. And if you look for a state of the 
 art GC, they only exist for VMs. I don't know any other 
 compiled language with a GC you could compare against.


 If you have a way to implement self-healing code in D please 
 share it. Or forwarding pointers, or card marking, or 
 read/write barriers without abusing the MMU(which is dog slow,) 
 or...

 Any of these would require massive changes to D that will never 
 happen. But while everyone is tripping over themselves to try 
 and copy something that will *not* work in D, they refuse to 
 acknowledge what massive benefits D's GC can provide over 
 Java's.


And yes, I'm well aware that someone will get pedantic and preach 
to me about using page protection to implement these 
things(despite mentioning it,) but it is _slow_, and you will be 
SOL in a few years when nobody uses 4K pages anymore.
Jul 16 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 16 July 2015 at 22:23:41 UTC, rsw0x wrote:

 If you have a way to implement self-healing code in D please 
 share it. Or forwarding pointers, or card marking, or 
 read/write barriers without abusing the MMU(which is dog slow,) 
 or...

 Any of these would require massive changes to D that will never 
 happen. But while everyone is tripping over themselves to try 
 and copy something that will *not* work in D, they refuse to 
 acknowledge what massive benefits D's GC can provide over 
 Java's.


Like what? Implementation may be difficult, but payback - fast 
and easy code - is huge. It's a matter of choice. What's wrong if 
people could choose the faster option for their code? BTW, isn't 
card marking the same as write barrier and why would you need to 
abuse anything slow for it?
Jul 19 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 19 Jul 2015 11:29:04 +0000, Kagamin wrote:


 Like what? Implementation may be difficult, but payback


...slow and ugly code...=
Jul 19 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 16 Jul 2015 21:04:32 +0000, Benjamin Thaut wrote:


 On Thursday, 16 July 2015 at 17:52:33 UTC, rsw0x wrote:

 On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote:

 This talk is really good and contains a lot of usefull information
 very densly packed: https://www.youtube.com/watch?v=3DvzzABBxo44g

 [...]


 Treating D's GC the same as a managed language running in a VM's GC
 will only end in disappointment.


=20
 Why?


two words: "memory barriers".=
Jul 16 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 16 July 2015 at 17:30:06 UTC, Benjamin Thaut wrote:

 This talk is really good and contains a lot of usefull 
 information very densly packed:
 https://www.youtube.com/watch?v=vzzABBxo44g

 The speaker has 30 years of experience working on javas hotspot 
 vm and shares his opinions on what you should do. My takeaways 
 from this talk are:

 GC:
 -You want a fully percise GC (e.g. know _all_ pointers even the 
 ones on the stack), the benenift outweights the cost for 
 tracking pointers.
 -You do not want to pin allocations in the gc heap as it is to 
 restrictive for your gc implementation.
 -GC safepoints worked out really well.


Because in Java, everything is in the VM and you can play all 
kind of trick that wouldn't work for us.


 TLS:
 To get fast thread local storage, align the start of the stack 
 so you can chop of a few bits of the stack pointer to get to 
 the TLS-section. We might be able to use this on platforms with 
 slow TLS?


That is beautiful ! But does not quite work with Fibers. Still, I 
want to believe, there is most likely something here that is 
worth looking into.
Jul 17 2015