Wasn't there talk recently of adding GC integration to profiling?
Would that be a use-case for a separate, runtime pluggable GC core? Or
would we rather put a lot of branching in the ordinary GC core to
support rarely used functionality? Hookable gc and pluggable GC seem
very similar to me.
On Mon
Hi folks,
I am not involved whatsoever in Parrot, but as a Perl developer
(implementing languages as well) and fanboy I'm subscribed here.
On 12.09.2011 11:28, Jonathan "Duke" Leto wrote:
An interesting read:
http://mail.python.org/pipermail/pypy-dev/2011-September/008288.html
Duke
Regar
This is the approach I was going to suggest. If we want to say that our
GC will not need to be improved in the foreseeable future, limiting
ourselves to a single GC algorithm is fine. However, I would strongly
advocate compile-time GC selection. Since we're now free to make
reasonable* breaking
Hello
> Thinking more about it, inf GC will only work as a runtime option for
> programs that don't consume too much memory. Compiling parrot or Rakudo with
> inf GC only will certainly fail. But it should be possible to get similar
> behavior to inf GC by tuning the GC memory thresholds. So ignor
On 12/09/11 22:04, Andrew Whitworth wrote:
Okay, here's what I'm going to do. I'm going to rip out the ms2 GC
core, rip out the command-line --gc option, and flatten the GC API
calls down in a branch. That way we can see if there really is any
kind of performance gains to be had and if so, how mu
Okay, here's what I'm going to do. I'm going to rip out the ms2 GC
core, rip out the command-line --gc option, and flatten the GC API
calls down in a branch. That way we can see if there really is any
kind of performance gains to be had and if so, how much. If we like
what we see, we'll set up the
I had forgotten about the infinite GC - that's probably worth keeping
a compile time choice for.
On Mon, Sep 12, 2011 at 1:35 PM, Nick Wellnhofer wrote:
>
> IIRC this has been discussed on IRC quite a while ago. I think the consensus
> was that runtime selection of GCs is not very important.
>
>
Howdy,
Sad to be the bearer of bad news, but OSL was recently hacked (kernel.org and
linux.com are currently down), and that means naughty people had root access on
a machine on the OSL network for a while.
My recommendation to people with accounts on parrotvm.osuosl.org:
If you had an ssh priva
IIRC this has been discussed on IRC quite a while ago. I think the
consensus was that runtime selection of GCs is not very important.
There are also two parts to the issue. The first one is the wrapper
functions in src/gc/api.c. They could be folded into the GC backends
with very small dupli
Seems reasonable to me to remove the runtime pluggability if there's a
lack of alternatives.
Adding a compile-time option seems reasonable, but only if we have
another serious contender. (And they can get themselves tested out in
a branch by replacing the existing GC well in advance of needing the
That would alleviate pain but would certainly be more work right now.
My big concern is testing this to see if there is a performance
improvement to be had. None of the cores we have besides GMS is worth
going through the effort for, and we don't even have plans on the
table yet for an alternate.
Howdy,
A while ago we talked about allowing GC's to be chosen at compile time.
Wouldn't that alleviate this pain whilst still allowing GC's to be
pluggable?
Duke
On Mon, Sep 12, 2011 at 7:59 AM, Nicholas Clark wrote:
> On Mon, Sep 12, 2011 at 10:42:17AM -0400, Andrew Whitworth wrote:
>
>> Is an
Howdy,
An interesting read:
http://mail.python.org/pipermail/pypy-dev/2011-September/008288.html
Duke
--
Jonathan "Duke" Leto
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
_
On Mon, Sep 12, 2011 at 10:42:17AM -0400, Andrew Whitworth wrote:
> Is anybody out there using or relying on the alternate GCs besides
> GMS? I think I want to rip the older ones out. Right now, because GCs
> are pluggable, we have to go through an indirect function call for
> every single GC API
Is anybody out there using or relying on the alternate GCs besides
GMS? I think I want to rip the older ones out. Right now, because GCs
are pluggable, we have to go through an indirect function call for
every single GC API call, and the C optimizer can't really do anything
with that. I want to rip
15 matches
Mail list logo
