[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: when GC is permitted

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.



Felix Winkelmann <felix@xxxxxxxxxxxxx> writes:
> I should have been more precise there: I understand the intention
> behind the "critical section". My point is that with an extra-indirection
> (as proposed by Tom or as used in JNI/minor - if I understand it right)
> the second class values point to something opaque. The values inside
> C locals and registers point to some "box" object that could easily be
> registered
> with the collector. Since the user can only access the data via
> extraction forms, it's completely transparent.
> 
> This means that the problem would simply go away (IMHO), provided the
> current draft proposal is changed in an appropriate manner.

Oh, I see now.  Yes, you're right --- JNI-style interfaces don't have
this problem; all their critical sections can be wrapped up inside the
API functions themselves.

But you need to be clear about exactly what JNI-style really implies.
Here's the implementation of mn_car, with run-time typechecking
removed:

    mn_ref *
    mn_car (mn_call *call, mn_ref *pair)
    {
      mn_ref *result;

      mn__begin_incoherent (call);
      {
        result = mn__make_local_ref (mn__untag_pair (pair->obj)->car);
      }
      mn__end_incoherent (call);

      return result;
    }

mn__make_local_ref is an allocation.  Sure, it's implemented with free
lists, and when the free list is empty, it'll just bump a pointer to
get the next ref out of a block, which is initialized lazily, and each
new block is allocated to be twice the size of the previous one, so
you're doing log (n) mallocs for n references, blah blah blah.

But here's the alternative.  Under a SRFI-50 style interface, here's
the implementation of car:

    scheme_value
    SCHEME_CAR (scheme_value pair)
    {
      return untag_pair (pair)->car;
    }

Under most reasonable tagging systems, untag_pair can be a
subtraction; the '->car' is a subsequent addition, which can be folded
in with the untagging; and then the whole thing can be easily inlined,
and possibly turned into an offset in the addressing mode of a load
instruction.  So the whole thing turns into a single instruction.

There's no comparison.  I think JNI entails at least one order of
magnitude more instructions to implement 'car'.

This is why Richard doesn't like JNI-style.

(BTW, Tom will be quite disappointed with what GCC's optimizer will do
to Pika-style code; go and try it.)