[Pharo-project] Integrating Changes in 1.4 that require a new VM
Hi, Markus Denker wrote: ------------------------------------------------------------------------------------------------------------------------------ There are two changesets waiting for integrating in 1.4 that have serious consequences: - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, but have not been integrated in the VMMaker codebase. http://code.google.com/p/pharo/issues/detail?id=4265 - Finalization code checks for #hasNewFinalization This is true in the current VMs build in Jenkins, but in older VMs this is not in. http://code.google.com/p/pharo/issues/detail?id=4483 ------------------------------------------------------------------------------------------------------------------------------ Since my Android-related branch has not been integrated into the mainline: where should I merge this from to be in sync? Is this back-compatible with Pharo 1.3? Thanks. -- Dimitry Golubovsky Anywhere on the Web
On Thu, Sep 22, 2011 at 6:17 AM, Dimitry Golubovsky <golubovsky@gmail.com>wrote:
Hi,
Markus Denker wrote:
------------------------------------------------------------------------------------------------------------------------------
There are two changesets waiting for integrating in 1.4 that have serious consequences:
- Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, but have not been integrated in the VMMaker codebase.
I would *really* like to back out these changes. The Ephemeron implementation is very much a prototype, requiring a hack to determine whether an object is an ephemeron (the presence of a marker class in the first inst var) that I'm not at all happy with. There is a neater implementation available via using an unused instSpec which IMO has significant advantages (much simpler & faster, instSpec is valid at all times, including during compaction, less overhead, doesn't require a marker class), and is the route I'm taking with the new GC/object-representation I'm working on now. Note that other than determining whether an object is an ephemeron (instSpec/format vs inst var test) the rest of Igor's code remains the same. I'd like to avoid too much VM forking. Would you all consider putting these changes on hold for now? If so, I'll make the effort to produce prototype changes (in the area of ClassBuilder and class definition; no VM code necessary as yet) to allow defining Ephemerons via the int spec route by next week at the latest.
- Finalization code checks for #hasNewFinalization This is true in the current VMs build in Jenkins, but in older VMs this is not in.
http://code.google.com/p/pharo/issues/detail?id=4483
------------------------------------------------------------------------------------------------------------------------------
Since my Android-related branch has not been integrated into the mainline: where should I merge this from to be in sync? Is this back-compatible with Pharo 1.3?
Thanks.
-- Dimitry Golubovsky
Anywhere on the Web
-- best, Eliot
On Sep 22, 2011, at 7:12 PM, Eliot Miranda wrote:
On Thu, Sep 22, 2011 at 6:17 AM, Dimitry Golubovsky <golubovsky@gmail.com> wrote: Hi,
Markus Denker wrote:
------------------------------------------------------------------------------------------------------------------------------
There are two changesets waiting for integrating in 1.4 that have serious consequences:
- Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, but have not been integrated in the VMMaker codebase.
http://code.google.com/p/pharo/issues/detail?id=4265
I would *really* like to back out these changes. The Ephemeron implementation is very much a prototype, requiring a hack to determine whether an object is an ephemeron (the presence of a marker class in the first inst var) that I'm not at all happy with. There is a neater implementation available via using an unused instSpec which IMO has significant advantages (much simpler & faster, instSpec is valid at all times, including during compaction, less overhead, doesn't require a marker class), and is the route I'm taking with the new GC/object-representation I'm working on now. Note that other than determining whether an object is an ephemeron (instSpec/format vs inst var test) the rest of Igor's code remains the same. I'd like to avoid too much VM forking. Would you all consider putting these changes on hold for now?
yes
If so, I'll make the effort to produce prototype changes (in the area of ClassBuilder and class definition; no VM code necessary as yet) to allow defining Ephemerons via the int spec route by next week at the latest.
excellent
- Finalization code checks for #hasNewFinalization This is true in the current VMs build in Jenkins, but in older VMs this is not in.
http://code.google.com/p/pharo/issues/detail?id=4483
------------------------------------------------------------------------------------------------------------------------------
Since my Android-related branch has not been integrated into the mainline: where should I merge this from to be in sync? Is this back-compatible with Pharo 1.3?
Thanks.
-- Dimitry Golubovsky
Anywhere on the Web
-- best, Eliot
participants (3)
-
Dimitry Golubovsky -
Eliot Miranda -
Stéphane Ducasse