NEW this year: ECOOP 2022 will have two rounds of reviewing.
Round 1 paper submission deadline: ** December 1, 2021 **
============================
ECOOP 2022
Call for Papers
ECOOP 2022 will be held on Mon 6th - Fri 10th of June in Berlin, Germany.
https://2022.ecoop.org/
============================
ECOOP is a conference about programming originally focused on object-orientation, but now including all practical and theoretical investigations of programming languages, systems and environments. ECOOP solicits innovative solutions to real problems as well as evaluations of existing solutions.
Authors are asked to pick one of the following categories:
- Research.
The most traditional category for papers that advance the sate of the art.
- Reproduction.
An empirical evaluation that reconstructs a published experiment in a different context in order to validate the results of that earlier work.
- Experience.
Applications of known PL techniques in practice as well as tools. Industry papers will be reviewed by practitioners. We welcome negative results that may provide inspiration for future research.
- Pearls/Brave New Ideas.
Articles that either explain a known idea in an elegant way or unconventional papers introducing ideas that may take some time to substantiate. These papers may be short.
==== Submissions ====
Submission must not have been published, or have major overlap with previous work. In case of doubt, contact the chair. Proceedings are published in open access by Dagstuhl LIPIcs in the Dagstuhl LIPIcs LaTeX-style template.
ECOOP uses double-blind reviewing. Authors’ identities are only revealed if a paper is accepted. Papers must 1. omit author names and institutions, and 2. use the third person when referencing the authors’ own work. Nothing should be done in the name of anonymity that weakens the submission; see the DB FAQ. When in doubt, contact the chair.
There is no page limit on submissions, but authors must understand that reviewers have a fixed time budget for each paper, so the quality of the comments is likely to be inversely proportional to length. Brevity is a virtue.
Authors will be given a three-day period to read and respond to the reviews of their papers before the program committee meeting. Responses have no length limit.
==== Artifact Evaluation and Intent ====
To support replication of experiments, authors of research papers may submit artifacts to the Artifact Evaluation Committee. They will be asked whether they intend to submit an artifact at submission time. It is understood that some paper do not have artifacts.
======== Important Dates ========
ECOOP 2022 will have two deadlines for submissions, three months apart. Future years may have more deadlines. Papers submitted in each round can be (a) accepted, (b) rejected, or (c) asked for revisions. Revisions can be submitted at a later round. Papers retain their reviewers during revision.
- Submission R1: 1 December 2021
- R1 Artifacts due: 10 December 2021
- Response R1: 23 January 2022
- Notification R1: 1 February 2022
- Submission R2: 1 March 2022
- R2 Artifacts due: 10 March 2022
- Response R2: 23 April 2022
- Notification R2: 1 May 2022
==== Journal First and Journal After ====
We have Journal First / After arrangements with ACM’s Transactions on Programming Languages and Systems (TOPLAS), Elsevier’s Science of Computer Programming (SCP) and AITO’s Journal of Object Technology (JOT).
Only new research papers are eligible to be Journal First (JF). JF papers will have an extended abstract in the ECOOP proceedings. The deadline is that same as round 1 of submissions and the notification is aligned with round 2 notification. TOPLAS JF papers should be submitted according to this announcement. SCP JF papers should follow this call for papers. JF papers are presented at the conference and eligible for awards.
Journal After (JA) papers are papers for which the authors request to be considered for post conference journal publication. Once accepted by the ECOOP PC, these papers will be forwarded to the journal editors. Reviews and reviewers will be forwarded and used at the editor’s discretion. JA papers will have an extended abstract (up to 12 pages) in the conference proceedings.
Find answers to frequently asked questions on our website: https://2022.ecoop.org/track/ecoop-2022-papers
As of today, if the Windows system time is changed, already running VM instances will not reflect this change. With this patch, this bug is fixed. The full bug report is on squeak-dev: http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-June/215908.html
This bug only affects builds for Windows versions prior to Windows 8, never builds do not use the tick variables any longer. See:
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/57260c215c025e17b57e…
(However, as #499 is still unmerged, currently, also builds for Windows 10 are affected by the bug. Looks like we were never benefitting from @eliotmiranda's improvements for the Win8 APIs (cf. fae0d31cd52341977d37d150d8d2c9272f9864bf) until today 😆)
Independently of this patch, we will want to fix cross-platform-occurring VM hangs when the system clock is pulled backward. See the bug report on squeak-dev for this, again.
Please review thoroughly!
/cc @marceltaeumel
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/588
-- Commit Summary --
* windows: resync the VM time when the system clock gets changed
-- File Changes --
M platforms/win32/vm/sqWin32Heartbeat.c (7)
M platforms/win32/vm/sqWin32Window.c (4)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/588.patchhttps://github.com/OpenSmalltalk/opensmalltalk-vm/pull/588.diff
--
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/pull/588
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: a385f5b69e7bda720e980dd61e683a0bf4810cd7
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a385f5b69e7bda720e…
Author: David T. Lewis <lewis(a)mail.msen.com>
Date: 2021-09-04 (Sat, 04 Sep 2021)
Changed paths:
M platforms/unix/config/Makefile.install
M platforms/unix/config/configure
M platforms/unix/config/make.cfg.in
Log Message:
-----------
Add a configure option to specify name of the installed squeak run script.
When running configure from a ./mvm script, the following command line
option is now available:
--scriptname=SCRIPT run script name installed in PREFIX [squeak]
This allows the various mvm scripts to specify scriptname such that
sudo make install will install /usr/local/bin/spur64 for a 64-bit spur VM,
/usr/local/bin/cog for a 32-bit cog VM, and so forth. Does not affect
naming of squeak.sh, which may be subject to similar name space conflicts.
A corresponding update has been made to the cmake/configure installation
for the classic interpreter VM (squeakvm.org SVN repository).
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3062.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.3062
Author: eem
Time: 7 September 2021, 2:00:13.46964 pm
UUID: 7fa2d499-15d9-4799-94a9-030ab3615de8
Ancestors: VMMaker.oscog-eem.3061
Cogit: Split followForwardedLiteralsIn: into followForwardedLiteralsImplementationIn: to avoid unnecessary ensureWritableCodeZone/ensureExecutableCodeZone in followForwardedLiteralsInOpenPICList.
Spur: Update SMM's class comment. Better comment objectAfterMaybeSlimBridge:limit:.
Simulator: fix CArray>>#at:put: to mimic C's integer truncation so that the encryption primitives simulate without error.
=============== Diff against VMMaker.oscog-eem.3061 ===============
Item was changed:
----- Method: CArray>>at:put: (in category 'accessing') -----
at: offset put: val
| address |
address := unitSize * offset + self ptrAddress.
^unitSize <= 2
ifTrue:
[unitSize = 1
+ ifTrue: [interpreter byteAt: address put: (val bitAnd: 16rFF)]
+ ifFalse: [interpreter shortAt: address put: (val bitAnd: 16rFFFF)]]
- ifTrue: [interpreter byteAt: address put: val]
- ifFalse: [interpreter shortAt: address put: val]]
ifFalse:
[unitSize = 4
+ ifTrue: [interpreter long32At: address put: (val bitAnd: 16rFFFFFFFF)]
+ ifFalse: [interpreter long64At: address put: (val class == SmallInteger "this saves time..."
+ ifTrue: [val]
+ ifFalse: [val bitAnd: 16rFFFFFFFFFFFFFFFF])]]
+
+ "[1 to: 1024 * 1024 do: [:i| i <= SmallInteger maxVal ifTrue: [i] ifFalse: [i bitAnd: 16rFFFFFFFFFFFFFFFF]]] bench. '275 per second. 3.63 milliseconds per run. 0 % GC time.'.
+ [1 to: 1024 * 1024 do: [:i| i class == SmallInteger ifTrue: [i] ifFalse: [i bitAnd: 16rFFFFFFFFFFFFFFFF]]] bench. '355 per second. 2.82 milliseconds per run. 0 % GC time.'
+ [1 to: 1024 * 1024 do: [:i| i bitAnd: 16rFFFFFFFFFFFFFFFF]] bench. '14.1 per second. 70.9 milliseconds per run. 2.95811 % GC time.'"!
- ifTrue: [interpreter long32At: address put: val]
- ifFalse: [interpreter long64At: address put: val]]!
Item was changed:
----- Method: CogMethodZone>>followForwardedLiteralsInOpenPICList (in category 'jit - api') -----
followForwardedLiteralsInOpenPICList
<option: #SpurObjectMemory>
| openPIC |
<var: #openPIC type: #'CogMethod *'>
openPIC := openPICList.
[openPIC notNil] whileTrue:
+ [cogit followForwardedLiteralsImplementationIn: openPIC.
- [cogit followForwardedLiteralsIn: openPIC.
openPIC := self cCoerceSimple: openPIC nextOpenPIC to: #'CogMethod *'].
self pruneYoungReferrers!
Item was added:
+ ----- Method: Cogit>>followForwardedLiteralsImplementationIn: (in category 'garbage collection') -----
+ followForwardedLiteralsImplementationIn: cogMethod
+ <option: #SpurObjectMemory>
+ <var: #cogMethod type: #'CogMethod *'>
+ | writableCogMethod hasYoungObj hasYoungObjPtr |
+ self assert: (cogMethod cmType ~= CMMethod or: [(objectMemory isForwarded: cogMethod methodObject) not]).
+ writableCogMethod := self writableMethodFor: cogMethod.
+ hasYoungObj := objectMemory isYoung: cogMethod methodObject.
+ (objectMemory shouldRemapOop: cogMethod selector) ifTrue:
+ [writableCogMethod selector: (objectMemory remapObj: cogMethod selector).
+ (objectMemory isYoung: cogMethod selector) ifTrue:
+ [hasYoungObj := true]].
+ hasYoungObjPtr := (self addressOf: hasYoungObj put: [:val| hasYoungObj := val]) asInteger.
+ self mapFor: cogMethod
+ performUntil: #remapIfObjectRef:pc:hasYoung:
+ arg: hasYoungObjPtr asVoidPointer.
+ hasYoungObj
+ ifTrue: [methodZone ensureInYoungReferrers: cogMethod]
+ ifFalse: [writableCogMethod cmRefersToYoung: false]!
Item was changed:
----- Method: Cogit>>followForwardedLiteralsIn: (in category 'garbage collection') -----
followForwardedLiteralsIn: cogMethod
<api>
<option: #SpurObjectMemory>
<var: #cogMethod type: #'CogMethod *'>
- | writableCogMethod hasYoungObj hasYoungObjPtr |
- self assert: (cogMethod cmType ~= CMMethod or: [(objectMemory isForwarded: cogMethod methodObject) not]).
- writableCogMethod := self writableMethodFor: cogMethod.
self ensureWritableCodeZone.
+ self followForwardedLiteralsImplementationIn: cogMethod.
- hasYoungObj := objectMemory isYoung: cogMethod methodObject.
- (objectMemory shouldRemapOop: cogMethod selector) ifTrue:
- [writableCogMethod selector: (objectMemory remapObj: cogMethod selector).
- (objectMemory isYoung: cogMethod selector) ifTrue:
- [hasYoungObj := true]].
- hasYoungObjPtr := (self addressOf: hasYoungObj put: [:val| hasYoungObj := val]) asInteger.
- self mapFor: cogMethod
- performUntil: #remapIfObjectRef:pc:hasYoung:
- arg: hasYoungObjPtr asVoidPointer.
- hasYoungObj
- ifTrue: [methodZone ensureInYoungReferrers: cogMethod]
- ifFalse: [writableCogMethod cmRefersToYoung: false].
self ensureExecutableCodeZone!
Item was changed:
----- Method: Spur32BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') -----
objectAfterMaybeSlimBridge: objOop limit: limit
"Object parsing.
1. all objects have at least a word following the header, for a forwarding pointer.
2. objects with an overflow size have a preceding word with a saturated numSlots. If the word
following an object doesn't have a saturated numSlots field it must be a single-header object.
If the word following does have a saturated numSlots it must be the overflow size word.
+
This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed
to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use
startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace
in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first.
This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of
the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace.
The test for a slim bridge is only performed if applied to an overflow header, and typically only
1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits. The complication is that
image segment loading evaporates the word array by setting the overflow slots to 1, and this
is ambiguous with a slimbridge. The resolution is that if the segmentArray has an overflow header,
+ and is in new space, then its slot size can be zeroed and its overflow header changed to a slimbridge.
+
+ At some point we should allow slimbridges (slivers?) throughout object memory, and use them to
+ provide object alignment by slimbridges (slivers?) padding up to the following (aligned) object."
- and is in new space, then it slot size can be zeroed and its overflow header changed to a slimbridge."
<inline: true>
| followingWordAddress followingWord |
followingWordAddress := self addressAfter: objOop.
(self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue:
[^limit].
self flag: #endianness.
followingWord := self longAt: followingWordAddress + 4.
^followingWord >> self numSlotsHalfShift = self numSlotsMask
ifTrue: [((self oop: objOop isLessThan: oldSpaceStart)
and: [1 = (self longAt: followingWordAddress)]) "i.e. the raw overflow slots in the overflow word"
ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] "skip the one word slimbridge"
ifFalse: [followingWordAddress + self baseHeaderSize]]
ifFalse: [followingWordAddress]!
Item was changed:
----- Method: Spur64BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') -----
objectAfterMaybeSlimBridge: objOop limit: limit
"Object parsing.
1. all objects have at least a word following the header, for a forwarding pointer.
2. objects with an overflow size have a preceding word with a saturated numSlots. If the word
following an object doesn't have a saturated numSlots field it must be a single-header object.
If the word following does have a saturated numSlots it must be the overflow size word.
+
This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed
to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use
startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace
in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first.
This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of
the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace.
The test for a slim bridge is only performed if applied to an overflow header, and typically only
1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits. The complication is that
image segment loading evaporates the word array by setting the overflow slots to 1, and this
is ambiguous with a slimbridge. The resolution is that if the segmentArray has an overflow header,
+ and is in new space, then its slot size can be zeroed and its overflow header changed to a slimbridge.
+
+ At some point we should allow slimbridges (slivers?) throughout object memory, and use them to
+ provide object alignment by slimbridges (slivers?) padding up to the following (aligned) object."
+
- and is in new space, then it slot size can be zeroed and its overflow header changed to a slimbridge."
<inline: true>
| followingWordAddress followingWord |
followingWordAddress := self addressAfter: objOop.
(self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue:
[^limit].
self flag: #endianness.
followingWord := self longAt: followingWordAddress.
^followingWord >> self numSlotsFullShift = self numSlotsMask
ifTrue:
[((self oop: objOop isLessThan: oldSpaceStart)
and: [(followingWord bitAnd: 16rFFFFFFFFFFFFFF) = 1])
ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] "skip the one word slimbridge"
ifFalse: [followingWordAddress + self baseHeaderSize]]
ifFalse: [followingWordAddress]!
Item was changed:
CogClass subclass: #SpurMemoryManager
(excessive size, no diff calculated)
Branch: refs/heads/Cog
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: e4b6c726af21682611a83e766d33fffa724c1ac7
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e4b6c726af21682611…
Author: Eliot Miranda <eliot.miranda(a)gmail.com>
Date: 2021-09-06 (Mon, 06 Sep 2021)
Changed paths:
M src/spur32.cog/cointerp.c
M src/spur32.cog/cointerp.h
M src/spur32.cog/cointerpmt.c
M src/spur32.cog/cointerpmt.h
M src/spur32.cog/gcc3x-cointerp.c
M src/spur32.cog/gcc3x-cointerpmt.c
M src/spur32.sista/cointerp.c
M src/spur32.sista/cointerp.h
M src/spur32.sista/gcc3x-cointerp.c
M src/spur32.stack/gcc3x-interp.c
M src/spur32.stack/interp.c
M src/spur32.stack/validImage.c
M src/spur64.cog/cointerp.c
M src/spur64.cog/cointerp.h
M src/spur64.cog/cointerpmt.c
M src/spur64.cog/cointerpmt.h
M src/spur64.cog/gcc3x-cointerp.c
M src/spur64.cog/gcc3x-cointerpmt.c
M src/spur64.sista/cointerp.c
M src/spur64.sista/cointerp.h
M src/spur64.sista/gcc3x-cointerp.c
M src/spur64.stack/gcc3x-interp.c
M src/spur64.stack/interp.c
M src/spur64.stack/validImage.c
Log Message:
-----------
CogVM source as per VMMaker.oscog-eem.3061
SpurMemoryManager:
Fix a regression in image segment loading introduced by VMMaker.oscog-eem.2819.
The old image segment array shortening code created a header ambiguous with a
slimbridge if the array was in new space. In this case we also have to shorten
the array's normal slot count so its header is taken as a slimbridge.
newSpaceLimit is equal to oldSpaceStart and therefore surplus to requirements.