gmane.comp.programming.garbage-collection.boehmgc

Re: RE: GC version numbering

Petter Urkedal — 2012-05-23T07:19:07

Is it necessary to jump to 8.0.0?  I don't think it's that uncommon to
drop a 0-suffix from version numbers, so it would be as if the
patchlevel for previous stable releases were all 0 (7.0 < 7.1 < 7.2 <
7.2.1).

RE: RE: GC version numbering

Boehm, Hans — 2012-05-22T23:59:44

I'm also fine with Andy's proposal.  In fact I was envisioning something like this in the slightly longer term.  The question is whether we should switch from 7.2 to 8.0.0 for a small bug fix.  My initial assumption was "no", but it may be worth it just to allow us to change version numbering cleanly.  I don't have a strong preference either way.

Hans

Re: RE: GC version numbering

Petter Urkedal — 2012-05-22T16:12:10

I agree that the numeric MAJOR.MINOR.PATCHLEVEL is what seems most
familiar to me, though I don't see a problem using a letter for the
patchlevel either.  My comment about sorting is not an issue as the
schemes are not mixed, so I think package systems can use the either
scheme unchanged.

Using odd/even for stable/unstable may have some implications for the
development process, so it may not be suitable for any project, but if
used:  I suspect the first minor series (X.0.Z) would usually be
unstable, so unless there is precedence, it may be most convenient if
the odd minor versions are stable.

Re: Can sigaltstack be used in a GC registered thread?

Andrew Haley — 2012-05-22T15:56:10

True enough.  There is some slack allowed for when a spinlock fails
and we have to call into pthread code but I'll grant you that there is
a possibility of an unexpected stack overflow if libc does something
really unexpected.

If a thread is not in Java state when a stack overflow segfault
occurs, it'll write-enable the yellow zone and return to complete the
pthread operation, which now has more stack to play with.  The size of
the yellow zone should be adequate for any plausible libc operation.
The yellow zone will be protected again when we return to java.  The
red zone is beyond the yellow zone, and it's a hard stop: if the libc
code touches that it'll result in a crash dump.


As above, possible, but the libc mutex code would have to do something
really silly.


StackOverflowError?  Not very much; it's an Error, and you're
basically dead when that happens.

Andrew.

Re: RE: GC version numbering

Andy Wingo — 2012-05-22T09:00:57


This would be fine.

Not to bikeshed, but let me float one more idea:

  M.N.O is stable if N is even, and unstable otherwise

  O increments on each release

It's easy and conventional -- which is really what these releases are
about: communicating the state of your library with the world.  In that
regard, the more conventional, the better.

If you think this is a good idea, then one way to switch to it would be
to skip 7.2 and 7.3 altogether.

One way to change to this strategy would be to make the following
substitutions:

  7.2 -> 8.0.0
  7.2b -> 8.0.1

  7.3alphaN -> 8.1.N
  7.4 -> 8.2

Again, I don't mean to delay things.  The proposal you gave is fine with
me.  But I do think the changes I propose would be better and easy to
make at this point.

Peace,

Andy

Re[2]: [Gc] RE: GC version numbering

Ivan Maidanski — 2012-05-22T08:18:21

Hi Petter and Hans,

Mon, 21 May 2012 22:35:39 +0200 Petter Urkedal <urkedal-Xs7T9bWjGN0< at >public.gmane.org>:

I add new tag after changing version in configure.
To me it's not a problem to modify a couple of files bumping the version - the problem is to decide when we should do it and what numbers should use.

Again back to gc7.2, let's finally use version name "gc-7.2b" (seems to be suitable for all parties), right?

Regards,
Ivan

Re: Re[2]: RE: GC version numbering

Petter Urkedal — 2012-05-21T21:06:34

I don't doubt you can transform it, but the human side of it may be
equally important, as users sometimes will need to relate their package
version to a Git tag or to a version on a different OS.

Re: Can sigaltstack be used in a GC registered thread?

Petter Urkedal — 2012-05-21T20:58:47

I should have mentioned that the code I was using is mostly pure.  It
allocates memory and does some logging.  Data created or altered by a
failed computation would not be used.  Though, I see your point:  I
should have checked available stack space before allocating to avoid
corrupting GC internal structures.  Likewise for logging.  Strangely, it
worked anyway.

On 2012-05-21, Boehm, Hans wrote:

Re: RE: GC version numbering

Petter Urkedal — 2012-05-21T20:35:39

If the goal is to avoid editing the configure.ac, then there may be
another solution.  "git describe --tags" will return a revision based on
the closest tag, e.g.

    git describe --match gc\* --tags HEAD--> gc7_3alpha2-2-g5b25be3
    git describe --match gc\* --tags 6cba390--> gc7_3alpha2

The AC_INIT arguments cannot be a shell substitutions, but the Autoconf
info page explicitly mentions m4_esyscmd_s for this purpose, so

    AC_INIT([gc],
      m4_bpatsubsts(m4_esyscmd_s([git describe --match gc\* --tags]),
[_], [.], [\<gc], [], [-\([0-9]+\)-g[0-9a-f]+\>], [.r\1]),
      [gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org])

or something similar [1] is valid.  This won't work on a tarball, but
that can be fixed by adding a command to the dist-target which stores
the tag in a distributed file.  The above command should than consider
this file before using "git describe".

I'm not sure whether this is a good idea.  Though the Autotools supports
it, 3rd party tools may expect literals for the AC_INIT arguments

RE: RE: GC version numbering

Boehm, Hans — 2012-05-21T20:02:23

That's what I had in mind.

Hans

RE: Can sigaltstack be used in a GC registered thread?

Boehm, Hans — 2012-05-21T18:59:22

Right.  But I thought there was at least some attempt to ensure that
native code that gets called under the covers as part of a Java library call
roughly follows the Java stack overflow protocol?  If it's user-written
native code, you could argue that stack overflows are the user's problem.
But if the code is part of the JVM implementation that seems less
defensible to me.

I haven't looked at this in a long time ...

Right.  That's what I was alluding to above, and I thought it tried to
include the JVMs native code stack space requirements.  For example, there are
presumably paths along which monitor entry ends up in libc, e.g. Linux
futex code, and you presumably want to handle the case in which the futex
generates a stack overflow?  Or does libc run on a separate stack?

In any case, it still ends up as an unchecked error
that can be thrown from any function call.
(The spec http://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.3
also still allows it to be thrown asynchronously.)
How much J

Re: Re[2]: RE: GC version numbering

Vitaly Magerya — 2012-05-21T16:49:22

Right. What I meant to say was that however you'll name this tarball,
there will be a way to tag it inside the ports system so that it would
sort properly (e.g. 7.2_1 will likely be used instead of 7.2-rev-b),
so our sorting rules should not constrain you.

Re: Can sigaltstack be used in a GC registered thread?

Andrew Haley — 2012-05-21T15:49:29


No, it doesn't work that way.  If a stack overflow happens in libc
code, it won't be caught as a stack overflow exception.  Calls to
native code don't run in Java state, and any segfault in one results
in a crash dump.


Unexpected like how?  HotSpot always bangs the stack at entry to a
method, and knows how much scratch space is needed.

Andrew.

RE: Can sigaltstack be used in a GC registered thread?

Boehm, Hans — 2012-05-21T15:27:26

The core issue here is that stack overflow signals are essentially
asynchronous.  As far as the programmer is concerned, they can occur anywhere.
Worse yet, they may occur at a "point in the code" that doesn't really
exist, because the compiler has transformed the code.  That means invariants
may be arbitrarily broken, locks may be held, etc.  Posix doesn't, and
can't, guarantee that longjmping out of such a signal handler is safe.
In some cases it may work, but its hard to guarantee correctness, GC or
not.

I believe that Java implementations that try to generate stack overflow
exceptions usually handle this by always making sure that they encounter
stack overflow exceptions at a known point.  For example, they check at
the beginning of each function that the function, including any native
library code it invokes, has enough stack space to run to completion.  This isn't
entirely free, though it may be fairly cheap.  It still doesn't strike me
as 100% solid, since the libc API doesn't really include maximum

Re[2]: [Gc] RE: GC version numbering

Ivan Maidanski — 2012-05-21T15:13:15

Hi Vitaly,

Mon, 21 May 2012 15:22:05 +0300 Vitaly Magerya <vmagerya-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:

In exactly this case (i.e. if the version will not be updated in configure and config.h), you would have to rely only on tarball names.

Regards,
Ivan Maidanski

Re: RE: GC version numbering

Bruce Mitchener — 2012-05-21T13:18:08

What about just following something like http://semver.org/ ?

 - Bruce

On Mon, May 21, 2012 at 7:22 PM, Vitaly Magerya <vmagerya-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: RE: GC version numbering

Vitaly Magerya — 2012-05-21T12:22:05

For what it's worth, FreeBSD ports don't allow dashes in versions,
and 7.2b sorts higher than 7.2.1 (7.2.b < 7.2.b1 < 7.2 < 7.2.1 < 7.2b
< 7.2b.1). In any case, we don't rely on tarball names to be properly
sorted according to the ports rules, so it's not inconvenient either
way.

Re: Can sigaltstack be used in a GC registered thread?

Petter Urkedal — 2012-05-21T07:17:10

For some purposes, it's sufficient to be able to longjmp back to a good
point or raise an exception.  E.g. I used libgc for a theorem prover
(unpublished), and while running though the TPTP suite, it would
occasionally cause a stack overflow, which I "handled" by skipping to
the next problem.  The signal stack handler I used is here:
https://github.com/paurkedal/culibs/blob/master/cuflow/errors.c (Note: I
should be calling the existing handler at the bottom of segv_handler.)

Re: RE: GC version numbering

Petter Urkedal — 2012-05-21T06:28:14

I think it would be nice if the tar revisions are also valid revisions
for common packaging systems.  E.g. RPM uses the dash to separate the
software version from the package revision (which indicates patches and
changes to packaging).  I think gc-7.2b is ok from RPM's point of view,
but I'm not sure how it sorts compared to gc-7.2.1.

RE: Can sigaltstack be used in a GC registered thread?

Boehm, Hans — 2012-05-21T04:28:48

AFAIK, the collector makes no attempt to handle a stack overflow.  It does make an attempt to invoke a preexisting SIGSEGV handler if one was previously installed.  It's conceivably possible, though no doubt untested, to install a stack overflow handler that somehow maps additional stack space and returns.  I can't think of another approach that would work with the current code structure.  And I believe this is a common problem for lots of system libraries.  I believe you're also out of luck if you generate a stack overflow while calling the libc malloc.

The collector should support a mode in which the collection always runs only in collector threads, rather than running on one of the client threads.  That should perhaps even be the default if thread support is enabled.  But it currently doesn't support that mode.  That would reduce stack space consumption and the chance of overflowing the stack in the collector.  I don't think it would be that difficult to implement, but AFAIK it hasn't been done.

I belie

Can sigaltstack be used in a GC registered thread?

Jean-Claude Beaudoin — 2012-05-21T01:34:12

Hi,

After reading the GC sources for a while trying to figure out the
minimal stack requirements for GC function calls I came across
the following consideration:

"sigaltstack" cannot be used in a thread registered with the GC
since the stack analysis the GC would perform during a collect
would be invalid if the collection were to happen during the
dynamic-extent of a signal handler using that "alternate stack".

Am I wrong on this or is this in fact the case?

BTW, a bit of googling shows that mono seems to be facing
the same issue.

I am a bit surprised that I did not get a single reply to my previous
message to this list about call stack overflow handling.
I insert here below a copy of the message in case it was simply
misrouted.

The structure of this GC makes it live at the outer edge of an
application call tree making the probability that a call stack
overflow may happen during the execution of a GC function
quite significant.  Currently if such a thing happens the GC
simply seems to crash the whole a