Vm-dev June 2018

vm-dev@lists.squeakfoundation.org

21 participants
83 discussions

Start a nNew thread

Build completed: opensmalltalk-vm 1.0.1342
by AppVeyor 27 Jun '18

27 Jun '18

1 0

Build failed: opensmalltalk-vm 1.0.1341
by AppVeyor 26 Jun '18

26 Jun '18

1 0

Build failed: opensmalltalk-vm 1.0.1340
by AppVeyor 26 Jun '18

26 Jun '18

1 0

Re: [Vm-dev] free-chunk-management-in-the-cog-vm
by Clément Bera 21 Jun '18

21 Jun '18

> In the end I decided to rebuild the linked lists while sweeping > afterdiscussing with Eliot. It avoids most of the unlinking operations on > the linked lists of free chunks. > > There are still some unlinking, but it's less common so the single linked > list for chunk of size 1 is now affordable (I don't see 75% of time spent > in free chunk unlinking like before on pathological cases). > > In selective compactor, segments are compacted using unlinking but only > segments mostly empty are compacted, so low amount of free chunks of size > 1. The problem was in the sweep phase and we fixed it. > > On Mon, Jun 18, 2018, 14:31 Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > >> Hi Eliot, >> >> On Sun, 17 Jun 2018, Eliot Miranda wrote: >> >> > >> > Hi Levente, >> > >> > >> >> On Jun 17, 2018, at 5:36 PM, Levente Uzonyi <leves(a)caesar.elte.hu> >> wrote: >> >> >> >>> On Mon, 18 Jun 2018, Ben Coman wrote: >> >>> >> >>> A random thought, I wonder if size-1 chunks can be managed packed >> into >> >> size-2 chunks. >> >> >> >> Or, just use the XOR trick to store each node's two links in a single >> pointer sized field: >> >> >> https://everything2.com/title/Storing+a+doubly-linked+list+using+just+a+sin… >> > >> > Alas, while this lovely trick does indeed encode a doubly-linked list >> in a single field it only works for full traversals. The xor is of the two >> neighbours, so to get to the next one needs the prev, and to get to the >> prev one needs the next. So one can start from either end but not in the >> middle. Clément’s modification is to allow rapid removal without needing >> to traverse the entire list, so the xor trick is not fit for purpose here. >> >> Well, it wasn't clear if that's a requirement, but I could have figured >> it >> out, because if you always iterate over the list, you can just keep a >> pointer to the previous node to delete the current node. >> >> If performance is important here, random deletion can still be done in >> O(1) time at the cost of maintaining an external doubly linked list with >> each node having a pointer to the chunk and the chunk using its sole slot >> to point to its list node. >> >> > >> > BTW the compactor I wrote before the current one (SpurPigCompactor >> preceded SpurPlanningCompactor) used exactly this trick. It didn’t work >> for reasons unrelated to the xor trick. Just mentioning it as proof that I >> love the technique. >> >> Nice. :) >> >> Levente >> >> > >> >> >> >> Levente >> >> > >

3 3

Fwd: squeak-vm is marked for autoremoval from testing
by Tobias Pape 21 Jun '18

21 Jun '18

Note that squeak-vm on debian is going to go away… > Begin forwarded message: > > From: Debian testing autoremoval watch <noreply(a)release.debian.org> > Subject: squeak-vm is marked for autoremoval from testing > Date: 21. Juni 2018 um 06:40:01 MESZ > To: squeak-vm(a)packages.debian.org > Delivered-To: tobias+squeak(a)netshed.de > Delivered-To: squeak-vm_summary(a)packages.qa.debian.org > Delivered-To: dispatch+squeak-vm_summary(a)tracker.debian.org > > squeak-vm 1:4.10.2.2614-4.1 is marked for autoremoval from testing on 2018-07-16 > > It is affected by these RC bugs: > 899694: squeak-vm: Invalid maintainer address pkg-squeak-devel(a)lists.alioth.debian.org > >

2 2

Signed at:[put:] primitives for bits classes
by Eliot Miranda 21 Jun '18

21 Jun '18

Hi All, right now we have a lot of different at:[put:] primitive variations. Spur supports 8 bit (variableByteSubclass:), 16 bit (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit (variableDoubleWordSubclass:) formats natively. V3 supports only 8 & 32 bit. This message is about simplifying things in Spur. The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 & 64 bit formats. These primitives are implemented in the JIT for maximum performance. The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32 bit formats (characters are in the range 0 to 2^30 - 1). These primitives are implemented in the JIT for maximum performance. The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits classes, irrespective of format. These are used to implement 16-bit sound samples above the 32 bit (variableWordSubclass:) format. These primitives have no JIT implementation. The primitives at: 165 at:put: 165 provide 32-bit signed access bits classes, irrespective of format. These are used to implement various 32-bit signed 2's complement tables above the 32 bit (variableWordSubclass:) format. These primitives have no JIT implementation. Since primitives 143 & 144 don't respect the format of the underlying instance their semantics are effectively locked down. But since, in current usage, 164 & 165 match the formats of the classes in which they're implemented, and I'm unaware of any abuses, these could be extended. I propose extending the semantics of 164 & 165 so that they match 60 & 61, except that they provide signed access to 8, 16, 32 & 64 bit pure bits formats, and providing JIT implementations for maximum performance. Doing so should be easy; they are very close to the JIT implementations of 60 & 61. Once this is done we could eliminate use of 143 & 144 if we changed SoundBuffer to use primitives 164 & 165 and to have a variableDoubleWordSubclass: format. Objections? _,,,^..^,,,_ best, Eliot

4 8

[OpenSmalltalk/opensmalltalk-vm] Design contribution (#269)
by HonshuBloc 19 Jun '18

19 Jun '18

Hello I´m a graphic designer looking for cool open source projects to make a graphic contribution, for free of course :P Î´m wondering if you are interested in a new logo for your project. Regards -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/269

5 5

free-chunk-management-in-the-cog-vm
by Ben Coman 18 Jun '18

18 Jun '18

Hi Clement, Nice article... https://clementbera.wordpress.com/2018/06/07/free-chunk-management-in-the-c… A random thought, I wonder if size-1 chunks can be managed packed into size-2 chunks. Have a variable size1_active_double initially nil. First size-1 allocation, grab a size-2 chunk into size1_active_double. First half returned as the size-1-chunk. Second half marked at "empty". Second size-1 allocation, return second half of size1_active_double as size-1-chunk. Set size1_active_double to nil. Releasing a size-1-chunk. Dependent on whether memory alignment can inform of which half of size-2-chunk is being released. Check if other half is empty ==> add it to the size-2-chunk-list. If other half not empty, add it to one of two singly-linked-lists depending on which half is empty, the empty half used for the linked-list. Next size-1 allocations made from these lists first to fill in the empty half. Considerations * Added complexity * Remaining size-1 singly-linked-list might have minimal impact - added complexity not worth the gain. ____________ Or another random thought *grin* - and this is probably completely off base because of my limited understanding. Piggyback the size-1-chunk management on top of the size-3-chunk-list. Consider one end of the size-3-chunk-list to be "size1-filled-end" with references to free size-1-chunks, and the other end of the size-3-chunk-list to be "size1-empty-end". To release a size-1-chunk, move a size-3-chunk from the "size1-empty-end" to the "size1-filled-end" and store the size-1-chunk reference there. To allocate a size-1-chunk, get it from the "size1-filled" end of the size-3-chunk-list and move that size-3-chunk to the "size1-empty-end" of its list. To compact a size-3-chunk that refers to a size-1-chunk, copy that into another chunk from the size1-empty-end moved to the size1-filled-end. I wonder if that even makes sense. Anyway, it hurts less to let the ideas roam free... cheers -ben

3 4

#adoptInstance: bug?
by Levente Uzonyi 18 Jun '18

18 Jun '18

Hi All, I recently found a bug(?) with #adoptInstance: (primitive 160). If you create a variable class, let's call it A, and a subclass of it, B, where B has an instance variable called foo, then B adoptInstance: (A new: 1) will fail with error code #'bad receiver', which is fine, because B needs more slots than A, but A adoptInstance: (B new: 1) will succeed. The resulting object will have 2 indexable slots instead of 1, because the instance variable will be converted to an indexable slot. Is this the expected behavior? (primitive 115 does the same) Levente

2 1

VMProfileLinuxSupportPlugin causes Linux builds to fail
by Alistair Grant 17 Jun '18

17 Jun '18

Hi Eliot and Everyone, Travis builds are failing due to compilation errors in VMProfileLinuxSupportPlugin. See e.g. https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/393065793 The most recent change to the file was in VMMaker.oscog-eem.2394 on 30 May 2018. Reverting VMProfileLinuxSupportPlugin.c to the previous version from VMMaker.oscog-eem.2347 dated 8 March 2018 avoids the compilation problems. Doing a diff of the two files gives: 2c2 < VMPluginCodeGenerator VMMaker.oscog-eem.2394 uuid: 61ae96f8-fd2b-4208-87ff-cf1cd6b3f859 --- > VMPluginCodeGenerator VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 4c4 < VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2394 uuid: 61ae96f8-fd2b-4208-87ff-cf1cd6b3f859 --- > VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 6c6 < static char __buildInfo[] = "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2394 uuid: 61ae96f8-fd2b-4208-87ff-cf1cd6b3f859 " __DATE__ ; --- > static char __buildInfo[] = "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2347 uuid: 062614a7-e3da-4b30-997a-9568911b9ff5 " __DATE__ ; 17,18c17,18 < #if defined(HAVE_DLFCN_H) < # include <dlfcn.h> --- > #ifdef __OpenBSD__ > #include <dlfcn.h> 19a20,23 > #ifndef _GNU_SOURCE > # define _GNU_SOURCE > #endif > #include <link.h> 104c108 < "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2394 (i)" --- > "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2347 (i)" 106c110 < "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2394 (e)" --- > "VMProfileLinuxSupportPlugin VMMaker.oscog-eem.2347 (e)" Any suggestions? Cheers, Alistair

3 7

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2018