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.)

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!

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.

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?

On Sun, 19 Jul 2015 11:29:04 +0000, Kagamin wrote:

> Like what? Implementation may be difficult, but payback
...slow and ugly code...