sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Question about _svmf_stopping_java()

[Archie C. <ar...@de...>]

Etienne Gagnon wrote:
> > However, I don't think this really gives you much advantage. It lets
> > a thread continue in native mode instead of halting, but it probably
> > is not going to get much further before having to come back to java mode
> > and then halt anyway. Just a thought experiment really.
> 
> Theoretically, it could quite possibly work (I would have to think carefully
> about all corner cases, but there's no deep reason it wouldn't work), but
> practically, I don't see much benefit.  Current code simply depends on
> the well tested _svmf_halt_if_requested().  Adding custom code for such critical
> and difficult to write correctly code (even though it is short, it is very
> tricky) is not something I look forward to. :-)

I hear you :-) Simplicity is sometimes it's own reward..

The way I see it, if a thread is running in native mode then it is
(by design) not allowed to directly touch any VM state, period,
with a few exceptions (e.g., a thread in Object.wait() that needs
to touch a fat lock). In those exception cases, the state it's
touching is protected by a special mutex (e.g., the fat lock mutex).

So as long as those exceptions are properly handled, then as far as
the VM is concerned a thread running in native mode is equivalent
to a halted thread. In either case, the VM state cannot be modified
by the thread (which is why we try to halt them in the first place).

But you would have to handle the exception cases. Using the fat lock
example, if you had other native threads running during GC then the GC
thread would have lock each thread's wait list mutex before changing
the object pointers in the list (after moving the pointed-to object).

So the tradeoff would be a questionable performance increse for an
increase in complexity and race condition potential.. definitely not
worth it.

-Archie

__________________________________________________________________________
Archie Cobbs     *    Halloo Communications    *     http://www.halloo.com

Re: [Sablevm-developer] Question about _svmf_stopping_java()

[Chris P. <chr...@ma...>]

Etienne Gagnon wrote:

> Archie Cobbs wrote:
>
>> However, I don't think this really gives you much advantage. It lets
>> a thread continue in native mode instead of halting, but it probably
>> is not going to get much further before having to come back to java mode
>> and then halt anyway. Just a thought experiment really.
>
>
> Theoretically, it could quite possibly work (I would have to think 
> carefully
> about all corner cases, but there's no deep reason it wouldn't work), but
> practically, I don't see much benefit.  Current code simply depends on
> the well tested _svmf_halt_if_requested().  Adding custom code for 
> such critical
> and difficult to write correctly code (even though it is short, it is 
> very
> tricky) is not something I look forward to. :-)
>
> It also makes the state diagram simpler.  [Yes, I know, I have not 
> written
> it down, and my ex-supervisor almost killed me when I made a 1+ hour 
> presentation
> to the Sable group about this stopping the world business, after my 
> thesis was
> accepted without having written anything about it... ;-)]



If anyone has good notes of that presentation I will type them up some 
time (I might need help with the diagram portion).  Unfortunately I 
don't have good notes.

Cheers,
Chris

Re: [Sablevm-developer] Question about _svmf_stopping_java()

[Etienne G. <gag...@uq...>]

Archie Cobbs wrote:
> However, I don't think this really gives you much advantage. It lets
> a thread continue in native mode instead of halting, but it probably
> is not going to get much further before having to come back to java mode
> and then halt anyway. Just a thought experiment really.

Theoretically, it could quite possibly work (I would have to think carefully
about all corner cases, but there's no deep reason it wouldn't work), but
practically, I don't see much benefit.  Current code simply depends on
the well tested _svmf_halt_if_requested().  Adding custom code for such critical
and difficult to write correctly code (even though it is short, it is very
tricky) is not something I look forward to. :-)

It also makes the state diagram simpler.  [Yes, I know, I have not written
it down, and my ex-supervisor almost killed me when I made a 1+ hour presentation
to the Sable group about this stopping the world business, after my thesis was
accepted without having written anything about it... ;-)]

Etienne
-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Question about _svmf_stopping_java()

[Archie C. <ar...@de...>]

Etienne Gagnon wrote:
> > In _svmf_stopping_java(), if the current thread is in state
> > SVM_THREAD_STATUS_HALT_REQUESTED you halt it by calling
> > _svmf_halt_if_requested().
> > 
> > Is this really necessary? Couldn't you just change the thread's
> > state to SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED
> > and let it continue? If it tries to return to Java mode later,
> > then it would have to halt of course.
> 
> Yes it is necessary.  When a thread is in state
> SVM_THREAD_STATUS_HALT_REQUESTED, there is another thread that would
> like to GC, but has temporarily gone to sleep until all non-native
> threads (in state SVM_THREAD_STATUS_HALT_REQUESTED) have reported
> back and gone to sleep, allowing GC to proceed.

Why wouldn't something like the following also work (ignoring
synchronization in this example)?

_svm_stopping_java()
{
   if (env->thread_status == SVM_THREAD_STATUS_HALT_REQUESTED)
     {
       /* now there's one less thread running in java mode */
       vm->pending_halt_thread_count--;

       /* were we the last java-mode thread to halt? */
       if (vm->pending_halt_thread_count == 0)
	{
	  /* yes, so signal requesting thread */
	  _svmm_cond_signal (vm->requesting_thread_cond);
	}
     }
   else
     assert(env->thread_status == SVM_THREAD_STATUS_RUNNING_JAVA);

   /* continue execution in native mode */
   env->thread_status = SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED;
}

However, I don't think this really gives you much advantage. It lets
a thread continue in native mode instead of halting, but it probably
is not going to get much further before having to come back to java mode
and then halt anyway. Just a thought experiment really.

-Archie

__________________________________________________________________________
Archie Cobbs     *    Halloo Communications    *     http://www.halloo.com

Re: [Sablevm-developer] Question about _svmf_stopping_java()

[Etienne G. <gag...@uq...>]

Hi Archie,

Archie Cobbs wrote:
> In _svmf_stopping_java(), if the current thread is in state
> SVM_THREAD_STATUS_HALT_REQUESTED you halt it by calling
> _svmf_halt_if_requested().
> 
> Is this really necessary? Couldn't you just change the thread's
> state to SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED
> and let it continue? If it tries to return to Java mode later,
> then it would have to halt of course.


Yes it is necessary.  When a thread is in state SVM_THREAD_STATUS_HALT_REQUESTED,
there is another thread that would like to GC, but has temporarily gone to sleep
until all non-native threads (in state SVM_THREAD_STATUS_HALT_REQUESTED) have
reported back and gone to sleep, allowing GC to proceed.

   while (env->thread_status == SVM_THREAD_STATUS_HALT_REQUESTED)
     {
       env->thread_status = SVM_THREAD_STATUS_HALTED;
==> another thread is pending GC : we halt this thread.

       vm->pending_halt_thread_count--;
==> we decrease by one the number of non-native threads that have not
     yet halted to let GC proceed.

       /* is there any other thread pending halt? */
       if (vm->pending_halt_thread_count == 0)
==> all non-native threads are halted (i.e. the current thread was the
     last non-halted one).
	{
	  /* no, so signal requesting thread */
	  _svmm_cond_signal (vm->requesting_thread_cond);
==> we wake up the GC thread so that it proceeds with GC.
	}

       /* halt thread */
==> we put current the thread to sleep until GC is done (more-less, as another
     GC can start before we wake up...  the pleasures of multi-threading ;-) ).
       do
	{
	  _svmm_cond_wait (vm->halted_threads_cond, vm->global_mutex);
	}
       while (env->thread_status == SVM_THREAD_STATUS_HALTED);
     }

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Etienne G. <gag...@uq...>]

Chris Pickett wrote:
> So ... is this really the case?  Why?
> 
> I definitely see your point about the Java programs restricted to being 
> open source under Cygwin if it *is* the case.
> 
> But that wouldn't that mean it's also illegal to run proprietary 
> programs with Kaffe (GPL)?  Or any other GPL'd interpreter / emulator?

This is what the FSF thinks.  Look at:

http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

Of course, not everybody interprets things like the FSF (for example
Debian has chosen a looser interpretation of derivative work), but
if you want to be absolutely sure, you shouldn't run the SPECjvm
on Kaffe.

> I thought SableVM was under the LGPL for different reasons, such as 
> being able to use it in a proprietary embedded OS or something.

And I also have chosen the LGPL after discussing longly with Richard Stallman
about licensing issues of JVMs.  I personally am inclined to use the
FSF's interpretation above, but I can live with people taking Debian's
interpretation as long as it's not for some GPL work *I* write. :-)

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Generational GC and Hashcode

[Grzegorz B. P. <ga...@de...>]

W liście z sob, 17-01-2004, godz. 19:16, Etienne Gagnon pisze: 
> Note:  Can somebody copy my explanations below into a document and add it into
> sablevm/doc?  Thanks.
Hi Etienne,

Done. (in staging)

With big pleasure. :-)

				GBP

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

Re: [Sablevm-developer] Generational GC and Hashcode

[Etienne G. <gag...@uq...>]

Hi Carl,

Note:  Can somebody copy my explanations below into a document and add it into
sablevm/doc?  Thanks.

Carl Lebsack wrote:
>>From what I have read, the hashcode is used by various hashing functions 
> when storing objects, and thus the hashcode should be constant for the 
> life of the object.  It is also suggested that the hashcode be distributed 
> across the range of integers, and although does not need to be unique for 
> each object, uniqueness will provide better performance.  It is suggested 
> to use the heap address of the object for the hashcode, but in a copying 
> collector, such as in SableVM, the location of the object will not be 
> static.

Right.

> Could someone explain to me how the lockword bits denoting SVM_HASH_NONE, 
> SVM_HASH_NOT_MOVED, SVM_HASH_MOVED  work in conjunction with the garbage
> collector, specifically with env->vm->heap.hashcode_base?  I feel I 
> understand the intention, but not the details.  I think the major 
> difference between the current collector and a generational collector is 
> that only a small subset of the objects are relocated during a collection 
> of the nursery.

OK.  Here it goes.

First, you must note that the method Object.hashcode() can be called on
any object (or array).  As the hashcode is an "int", a naive implementation
of java.lang.Object could look as:

package java.lang;

public class Object
{
   private static nextHashcode = 0;

   private final int hashcode = nextHashcode++;
...

   public int hashcode()
   {
     return hashcode;
   }
}

Of course, this does not work; synchronization is missing (concurrent object
creation) and so on, but it illustrates the idea.

In this naive implementation, every object/array instance has a 32 bit field
for storing its hashcode.  If an application has many small objects on which
the hashcode() method is *never* called throughout its execution, then the
space overhead can be relatively big.

In VMs that use non-moving collectors, a simple strategy can be used to eliminate
the need to use an additional 32 bits per object/array instance: one can simply
use the object's address as hashcode.  This can have deficiencies in hashcode
value distribution, specially if the heap is restricted to a small subset of
memory, but it is usually good enough, and it can save much memory.

This does not work for moving collectors, as the address of objects/arrays change
throughout their lifetime (hashcode cannot change, of course).  A clever trick
(got it from IBM researchers) allows one to get away with a two-bit hashcode that
can be put in the header of an object, thus saving a word for every object
instance.  Note that I did not use this trick for arrays, as the overhead is
usually less important.  All arrays need at least: lockword, vtable pointer,
and length.  Adding hashcode, even to arrays of 0 (!!!) elements is at most 33%
overhead (instead of 50%), and is very likely to be less (there aren't too many
situations where arrays of 0 elements are useful).

The two bits indicate one of three states:

SVM_HASH_NONE:      hashcode() was never called on this object.  The object has
                     no hashcode.
SVM_HASH_NOT_MOVED: hashcode(0 has been called, and GC has not happened since the
                     first call.  The object has a hashcode that is not explicitly
                     stored; it has to be computed.  See below for details.
SVM_HASH_MOVED:     hashcode() has been called, and GC has happened since, so the
                     hashcode is explicitly saved at the end of the object.

It works like this:
1- All arrays are assigned a hashcode at allocation time.  The hashcode is saved in
    the array header.
2- Objects are allocated, and 2 bits of the header are reserved for hashcode.  These
    bits are initialized to SVM_HASH_NONE.  An object has no real hashcode until
    hashcode() is called on it.  Experiments show that many objects do not ever
    need a hashcode, so this is good.
3- When Object.hashcode() is called on an instance, the following algorithm is applied:

    if instance is array
      return stored hashcode

    // instance is an object

    else if instance.hashcode_state == SVM_HASH_NONE
      instance.hashcode_state = SVM_HASH_NOT_MOVED
      return compute_hashcode(instance)

    else if instance.hashcode_state == SVM_HASH_NOT_MOVED
      return compute_hashcode(instance)

    else // instance.hashcode_state == SVM_HASH_MOVED
      return stored hashcode (at end of object)

    as for compute_hashcode, it looks like this:

    int compute_hashcode(instance)
    {
       int offset = instance.address - start_of_current_heap;
       return offset + hashcode_base_value;
    }

     hashcode_base_value is a constant *between* GCs.  It is a virtual
     base address of a hypothetical contiguous heap.  So, on VM startup,
     this value is initialized to 0.  After first GC, it is incremented
     by the size of the discarded "from" space (copying collector).  Same
     after every GC.  So, it looks like:

     |---HEAP-1---|---HEAP-2---|---HEAP-3---|---
     ^            ^            ^            ^
     |            |            |            |
     |            |            |            \
     |            |            \             - Value after 3rd GC == size of HEAP-1 + HEAP-2 + HEAP-3
     |            \             - Value after 2nd GC == size of HEAP-1 + HEAP-2
     \             - Value after 1st GC == size of HEAP-1
      - Initial value (0)

     This approach has several advantages:  It makes hashcodes less volatile across
     executions of the same application (even if malloc() returns different
     addresses for the heap).  It also ensures a better distribution of hashcode values,
     as they are given increasing values until the 32-bit values space is exhausted
     at which point modulo 32-bits applies.

4- When GC happens, a little additional care has to be given to objects when
    their hashcode state is SVM_HASH_NOT_MOVED or SVM_HASH_MOVED.

    if object.hashcode_state == SVM_HASH_NOT_MOVED
      we must compute hashcode one last time and store it at the
      end of the object in the TO space.  We also set the hashcode
      state of the TO copy to SVM_HASH_MOVED.

    if object.hashcode_state == SVM_HASH_MOVED
      we must copy a longer object.



Have fun!

Etienne


-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Chris P. <chr...@ma...>]

>If running a java program on a JVM means linking to the JVM
>  
>

So ... is this really the case?  Why?

I definitely see your point about the Java programs restricted to being 
open source under Cygwin if it *is* the case.

But that wouldn't that mean it's also illegal to run proprietary 
programs with Kaffe (GPL)?  Or any other GPL'd interpreter / emulator?

I thought SableVM was under the LGPL for different reasons, such as 
being able to use it in a proprietary embedded OS or something.

Cheers,
Chris

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Grzegorz B. P. <ga...@de...>]

W liście z sob, 17-01-2004, godz. 17:07, Chris Pickett pisze: 
> Well, I read it as this:  the libsablevm.dll can be created and 
> distributed under the LGPL, but you need cygwin1.dll to run.  If you 
> modify cygwin1.dll and distribute the changes, it must be done under the 
> GPL.
> 
> Just provide two downloads -- one for SableVM, with source, licensed 
> under the LGPL, and one for cygwin1.dll, with source, licensed under the 
> GPL.  If the cygwin1.dll source isn't part of the sablevm tree then I 
> don't see the problem.  However, if you don't want to host the cygwin 
> source but just the unmodified .dll, I *think* that's okay -- as long as 
> you meet section 3b or 3c of the GPL (the written offer for 3 years does 
> not necessarily imply having it available for download without even 
> asking, if I read it correctly).
> 
> I don't think they would make the exception to allow you to build an 
> LGPL'd .dll if the resulting program was GPL'd automatically at runtime 
> just because you're forced to link to cygwin1.dll.  That's misleading 
> and I don't think Cygwin is out to mislead people.

I think you read it right. Mostly.

I still have this issue here. See this:

If running a java program on a JVM means linking to the JVM,
then the java program links to cygwin.a too (let alone .dll).
But the the exception is for OpenSource(tm) programs only.
Though if the java program is not OpenSource(tm) licensed
then we're not allowed to use the exception, so we fall under the GPL
and we're not allowed to run this non-OpenSource(tm) program.

It means that on SableVM on Cygwin we can run GPL-incompatible programs,
BUT they have to be OpenSource(tm).

So... anybody to polish the SableVM Cygwin port? :-)

I'd be glad to help.

					Grzegorz B. Prokopski


-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

[Sablevm-developer] Generational GC and Hashcode

[Carl L. <le...@ia...>]

I am finishing up an implementation for Generational garbage collection 
for SableVM and have a question regarding the hashcode.  I have based the 
GC on the original copying GC but am not sure I understand how the 
hashcode is handled.

From what I have read, the hashcode is used by various hashing functions 
when storing objects, and thus the hashcode should be constant for the 
life of the object.  It is also suggested that the hashcode be distributed 
across the range of integers, and although does not need to be unique for 
each object, uniqueness will provide better performance.  It is suggested 
to use the heap address of the object for the hashcode, but in a copying 
collector, such as in SableVM, the location of the object will not be 
static.

Could someone explain to me how the lockword bits denoting SVM_HASH_NONE, 
SVM_HASH_NOT_MOVED, SVM_HASH_MOVED work in conjunction with the garbage 
collector, specifically with env->vm->heap.hashcode_base?  I feel I 
understand the intention, but not the details.  I think the major 
difference between the current collector and a generational collector is 
that only a small subset of the objects are relocated during a collection 
of the nursery.

Carl Lebsack
PhD Student
Iowa State University

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Chris P. <chr...@ma...>]

>
> I don't think they would make the exception to allow you to build an 
> LGPL'd .dll if the resulting program was GPL'd automatically at 
> runtime just because you're forced to link to cygwin1.dll.  That's 
> misleading and I don't think Cygwin is out to mislead people.
>
> Cheers,
> Chris
>

Unless that really is the case, and it's a special case in the licensing 
that Cygwin did not realize.  Maybe Greg you should ask on one of the 
Cygwin lists?

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Chris P. <chr...@ma...>]

>Can I build a Cygwin program that does not require cygwin1.dll at
>runtime?
>
>No. If your program uses the Cygwin API, then your executable cannot run
>without cygwin1.dll. In particular, it is not possible to statically
>link with a Cygwin library to obtain an independent, self-contained
>executable.
>
>====
>The side question now is that: our app, linked with cygwin.a will use
>cygwin1.dll anyway, so will it be covered by GPL at runtime? Will it
>permit running not open-source binaries legally?
>
>So even though we might be able to get LGPLed SableVM under cygwin,
>this can only be the case if we don't distribute cygwin1.dll with it.
>Whether it is an issue to make user fetch the dll (but not necessarily
>whole cygwin!, just the dll) on his own - depends on a POV.
>  
>

Well, I read it as this:  the libsablevm.dll can be created and 
distributed under the LGPL, but you need cygwin1.dll to run.  If you 
modify cygwin1.dll and distribute the changes, it must be done under the 
GPL.

Just provide two downloads -- one for SableVM, with source, licensed 
under the LGPL, and one for cygwin1.dll, with source, licensed under the 
GPL.  If the cygwin1.dll source isn't part of the sablevm tree then I 
don't see the problem.  However, if you don't want to host the cygwin 
source but just the unmodified .dll, I *think* that's okay -- as long as 
you meet section 3b or 3c of the GPL (the written offer for 3 years does 
not necessarily imply having it available for download without even 
asking, if I read it correctly).

I don't think they would make the exception to allow you to build an 
LGPL'd .dll if the resulting program was GPL'd automatically at runtime 
just because you're forced to link to cygwin1.dll.  That's misleading 
and I don't think Cygwin is out to mislead people.

Cheers,
Chris

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Grzegorz B. P. <ga...@de...>]

W liście z sob, 17-01-2004, godz. 14:22, Etienne Gagnon pisze: 
> So, we have to find a way to make sure we link statically with cygwin and
> dynamically with everything else.

Honestly speaking - I am a bit lost with how it actually works under
cygwin. But from what I understood so far (I might be wrong here)
from my experiences is that one has to have cygwin1.dll (which is
under GPL) on his manchine anyway, even to run statically compiled
programs.

====
http://download.franklin.com/franklin/ebookman/developer/doc/cygwin/1_GS/int02.html#Build&usedlls

import library
        The import library is a regular UNIX-like .a library, but it
        only contains the tiny bit of information needed to tell the
        operating system how your program interacts with (or imports)
        the .dll as data. This information is linked into your .exe
        file. This is also generated by the dlltool utility.

====
http://cygwin.com/faq/faq_4.html#SEC98

Can I build a Cygwin program that does not require cygwin1.dll at
runtime?

No. If your program uses the Cygwin API, then your executable cannot run
without cygwin1.dll. In particular, it is not possible to statically
link with a Cygwin library to obtain an independent, self-contained
executable.

====
The side question now is that: our app, linked with cygwin.a will use
cygwin1.dll anyway, so will it be covered by GPL at runtime? Will it
permit running not open-source binaries legally?

So even though we might be able to get LGPLed SableVM under cygwin,
this can only be the case if we don't distribute cygwin1.dll with it.
Whether it is an issue to make user fetch the dll (but not necessarily
whole cygwin!, just the dll) on his own - depends on a POV.

Besides that, if we want to seriously treat cygwin port - somebody would
need to first fix builds of libffi to actually produce cygffi.dll
(probably just re-auto*-ization will help) and fix libpopt not to
segfault i.e. on short params (like "-p").

HTH

					Grzegorz B. Prokopski

PS: Give all the technical quirks we've seen under cygwin - I really
wonder how do the WSfU solve these problems.

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

Re: [Sablevm-developer] Accepted sablevm 1.0.9+svn20040115-1 (i386 source all)

[Grzegorz B. P. <ga...@de...>]

W liście z sob, 17-01-2004, godz. 12:01, Etienne Gagnon pisze: 
> Hi Greg,
> 
> Why doesn't this newer package close bug 215314?
> As it currently stand, this bug prevents SableVM from entering testing.
Hi Etienne,

It's barely the _first_ upload of much newer version.
There will surely be new uploads. When I am confident that the
new version is good enough - it will close this bug and let it
go into testing. It should be quite soon.

Cheers,

				Grzegorz B. Prokopski

BTW: I tried to run bugview from debbuggtk package and I got this:

sablevm: INTERNAL ERROR (source file "native_interface.c", line 23281):
 todo

which is caused by a call to
GetObjectArrayElement (JNIEnv *_env, jobjectArray array, jsize indx)

hmm... more than 10 functions around this one are just stubs. It doesn't
look very good. Any chaces to get them filled in w/ real code?

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

Re: [Sablevm-developer] Declaring SableVM ported to Windows... tomorrow ;-)

[Etienne G. <gag...@uq...>]

Grzegorz B. Prokopski wrote:
>  In accordance with section 10 of the GPL, Red Hat, Inc. permits
>  programs whose sources are distributed under a license that complies
>  with the Open Source definition to be linked with libcygwin.a without
>  libcygwin.a itself causing the resulting program to be covered by the
>  GNU GPL.
 >
 >  This means that you can port an Open Source(tm) application to cygwin,
 >  and distribute that executable as if it didn't include a copy of
 >  libcygwin.a linked into it. Note that this does not apply to the cygwin
 >  DLL itself. If you distribute a (possibly modified) version of the DLL
 >  you must adhere to the terms of the GPL, i.e., you must provide sources
 >  for the cygwin DLL."

This is great!

> As far as I can read it means that as long as the user fetches the
> cygwin.dll himself and we don't distribute it with SableVM - we can
> safely provide SableVM binaries compiled for Cygwin w/o falling under
> the GPL.

No!  It means that if we statically link libcygwin.a into libsablem.dll, then
libsablevm.dll can still be licensed under the LGPL, allowing SableVM to
be used for running proprietary Java programs and linking with proprietary
JNI libraries.

But, if instead, libsablevm.dll dynamically links with cygwin.dll, then
normal GPL rules apply.

[Please re-read the "This means that you can port an Open Source(tm)..."
paragraph carefully.]

So, we have to find a way to make sure we link statically with cygwin and
dynamically with everything else.

Have fun!

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Accepted sablevm 1.0.9+svn20040115-1 (i386 source all)

[Etienne G. <gag...@uq...>]

Hi Greg,

Why doesn't this newer package close bug 215314?

As it currently stand, this bug prevents SableVM from entering testing.

Etienne

Grzegorz Prokopski (Debian Developer) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Format: 1.7
> Date: Thu, 15 Jan 2004 22:57:46 -0500
> Source: sablevm
> Binary: libsablevm1 sablevm libsablevm1-dev
> Architecture: source all i386
> Version: 1.0.9+svn20040115-1
> Distribution: unstable
> Urgency: low
> Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
> Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
> Description: 
>  libsablevm1 - Free implementation of JVM second edition - library
>  libsablevm1-dev - Free implementation of JVM secon edition - development files
>  sablevm    - Free implementation of Java Virtual Machine (JVM) second edition
> Changes: 
>  sablevm (1.0.9+svn20040115-1) unstable; urgency=low
>  .
>    * Completly new and improved version. Uses NEW GNU Classpath. We're
>      pulling from SVN, but don't worry - it's much better than old 1.0.9.
>    * SableVM debian package is now native, so look at upstream changelog.
> Files: 
>  203477f44d20a8b646c87a65ed66a244 864 interpreters optional sablevm_1.0.9+svn20040115-1.dsc
>  cc2e44a9c0d0e5f4a1ac09a19fffe8c8 546754 interpreters optional sablevm_1.0.9+svn20040115-1.tar.gz
>  48ddc45c45403d8a7099fe619d87812c 32512 interpreters optional sablevm_1.0.9+svn20040115-1_i386.deb
>  17c0bf5714409115db38a234576b2160 154604 libs optional libsablevm1_1.0.9+svn20040115-1_i386.deb
>  87d44a3ee85626237a03fd2f6be5f689 22030 libdevel optional libsablevm1-dev_1.0.9+svn20040115-1_all.deb
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAB5zZcxjwiKS4/ekRAngGAJ9P71OSESpmt2A53RWkeRYA6D1H7ACgsdgo
> nhkaE01IVxgweL5wQdvatZg=
> =RTmr
> -----END PGP SIGNATURE-----
> 
> 
> Accepted:
> libsablevm1-dev_1.0.9+svn20040115-1_all.deb
>   to pool/main/s/sablevm/libsablevm1-dev_1.0.9+svn20040115-1_all.deb
> libsablevm1_1.0.9+svn20040115-1_i386.deb
>   to pool/main/s/sablevm/libsablevm1_1.0.9+svn20040115-1_i386.deb
> sablevm_1.0.9+svn20040115-1.dsc
>   to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1.dsc
> sablevm_1.0.9+svn20040115-1.tar.gz
>   to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1.tar.gz
> sablevm_1.0.9+svn20040115-1_i386.deb
>   to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1_i386.deb
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
> 
> 


-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] adventures in not understanding the java stack

[Chris P. <chr...@ma...>]

David B=E9langer wrote:

>On Sat, Jan 17, 2004 at 12:21:30AM -0500, Chris Pickett wrote:
> =20
>
>>So ... can somebody explain (3) for me?  Can native code affect stack=20
>>values or control flow without going through the exception_handler: in =

>>interpreter.c or going through _svmf_stop_the_world?  If so, where does=
=20
>>it do it?
>>   =20
>>
>
>Look at NATIVE_STATIC_METHOD and NATIVE_NONSTATIC_METHOD.
>
>All the code to unwind the stack is in _svmf_interpreter.  Though the
>exception object is built by the native method or one of the
>method/function it calls.
>
> =20
>
that's what i thought.  i had changed _svmf_interpreter() to:

    athrow_handler:
    ...
    abstractmethoderror_handler:
    exception_handler:
  =20
    <my code to flag exceptions / kill speculative children is here>

    <normal exception handler stuff>

and i don't understand how an exception can be thrown natively or=20
non-natively without passing by "exception_handler:" in=20
_svmf_interpreter ...

>GC is usually trigger by creating new instance and not enough memory.
>There is also a native method that forces gc.
>Java_java_lang_Runtime_gc.  There is a single gc entry point that will
>stop all threads (except the current one) before doing the actual gc.
>Look in gc_copying.c.
>
> =20
>

okay, i had assumed that _svmf_stop_the_world was always called and=20
always visited all threads for each gc, whether gc is called natively or =

not.  I had changed _svmf_stop_the_world() in thread.c to:

    /* visit all threads */
    for (...)
      {
        jboolean succeeded;
     =20
        <my code to flag gc is here>

        if (current =3D=3D env)
        ...
      }

and I still don't understand how GC could be called without passing=20
through this code for each thread.  after looking at=20
Java_java_lang_Runtime_gc, i see that it calls=20
_svmf_copy_gc_no_exception(), which in turn calls _svmf_stop_the_world ..=
=2E

anyway, i think there might be some other control flow issue related to=20
exceptions that i don't understand.  i put abortion code in=20
INTERNAL_CALL_END as well, in the event that a new speculative thread=20
gets started in the middle of the exception handler and the=20
non-speculative parent hits this instruction without hitting the=20
"exception_handler:" handler label in _svmf_interpreter() .....

so -- apart from calling gc and throwing exceptions, is there anything=20
that a native or non-native method could be doing to invalidate the=20
requirements i have (original email)?  note that speculation is never=20
started in a preparation sequence.

i'm sorry, i just really don't understand how i'm not catching this if i =

make the above changes.  anyway, if it sounds like i'm doing everything=20
right i'll go back over my changes again, but i keep thinking there's=20
some piece that i'm missing.

cheers,
chris

Re: [Sablevm-developer] building out-of-the-box on non-Linux platform

[Grzegorz B. P. <ga...@de...>]

W liście z sob, 17-01-2004, godz. 04:17, David Bélanger pisze: 
> Hi,
> 
> I think it would be great if SableVM could be built out-of-the-box on
> all platforms including the non-Linuxian FreeBSD and OS X.  It will
> simplify my life as I want to build and test on these platforms.
> Currently source code is not an issue, it is more a configure/Makefile
> isssue.
> 
> src/libsablevm/Makefile.am has some line like:
> libsablevm_la_LIBADD = -lpthread -lm -lffi -lltdl -lrt
> 
> FreeBSD does not like -lpthread.
> OS X does not like -lrt.
> 
> This is because functionnality is located elsewhere and there are
> no such libXX.so file...  (Actually, on OS X, there is a single
> libSystem that includes implementation of libc, libm, libpthread and
> probably others.  libc etc. are only symlinks to libSystem.  But there
> are no librt symlinks in the default installation)
> 
> A long time ago, I had:
> if REQ_LPTHREAD
> REQ_LIBS = -lpthread -lm -lffi -lltdl -lrt
> else
> REQ_LIBS = -lc_r -lm -lffi -lltdl -lrt
> endif
> libsablevm_la_LIBADD = ${REQ_LIBS}
> 
> where REQ_LPTHREAD was set in ./configure.ac.
> 
> This was ok for FreeBSD but will become more complex with -lrt on/off.
> Note: I tried first with simpler things but automake/conf tools didn't
> like it.  There are some restriction of what the right hand side arg
> of libsablevm_la_LIBADD can be for the autoconf/make tools, don't
> remember which one.

svn diff -r 1204:HEAD \
 svn://svn.sablevm.org/developers/mlord/sandbox/sablevm-staging |less

will show you what was changed for cygwin port (not yet merged)
It also didn't like -lrt (only Solaris requires it apparently)
but it wasn't solved nicely.

But if we take a look at these parts:

+++ configure.ac        (revision 1385)
+dnl defining macro (platform_win32) only for Cygwin or Mingw
+AC_MSG_CHECKING([for some Win32 platform])
+
+case "$host" in
+  *-*-mingw*|*-*-cygwin*)
+    platform_win32=yes
+    ;;
+  *)
+    platform_win32=no
+    ;;
+esac
+AC_MSG_RESULT([$platform_win32])
+AM_CONDITIONAL(PLATFORM_WIN32, test "$platform_win32" = "yes")
+
+++ src/libsablevm/Makefile.am  (revision 1385)
+if PLATFORM_WIN32
+no_undefined = -no-undefined
+endif
+
[...]
+libsablevm_la_LDFLAGS = -version-info @LIBRARY_VERSION@ $(no_undefined)

One could add detection of other platforms in configure.ac and
accordignly add in makefiles ex. 
+if PLATFORM_SOLARIS
+lrt=-lrt
+endif
and so on...

But I don't think I like this stuff, first because it'd require us to
create PLATOFORM_* defines for maaaany platforms, second - this config
info (what to link with or not) looks like global stuff, so why would
it reside in one Makefile.am and not in the other one(s)? We should
save ourselves coding and do maximum of it in one place (configure),
while minimizing changes in other places (Makefiles).

Ideally, I think we'd have in configure.ac sth. like:
+AC_MSG_CHECKING([if we need -no-undefined])
+
+case "$host" in
+  *-*-mingw*|*-*-cygwin*)
+    no_undefined=-no-undefined
+    AC_MSG_RESULT([yes])
+    ;;
+  *)
+    AC_MSG_RESULT([no])
+    ;;
+esac

+AC_MSG_CHECKING([if we need -lrt])
+
+case "$host" in
+  *solaris*)
+    lrt=-lrt
+    AC_MSG_RESULT([yes])
+    ;;
+  *)
+    AC_MSG_RESULT([no])
+    ;;
+esac

+AC_MSG_CHECKING([if we need -lpthread])
+
+case "$host" in
+  *freebsd*)
+    AC_MSG_RESULT([no])
+    ;;
+  *)
+    lpthread=-lpthread
+    AC_MSG_RESULT([yes])
+    ;;
+esac

(system id strings, besides cygwin/mingw should probably be narowed)

and then use @no_undefined@, @lrt@ and @lpthread@ in Makefiles - where
needed. They either would contain respective params or be empty.

Other way would be to just have one case "$host" and set some variable
to full set of params needed to link libsablevm.

There's probably yet another, even better way to do it :-)

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org

[Sablevm-developer] building out-of-the-box on non-Linux platform

[David <db...@cs...>]

Hi,

I think it would be great if SableVM could be built out-of-the-box on
all platforms including the non-Linuxian FreeBSD and OS X.  It will
simplify my life as I want to build and test on these platforms.
Currently source code is not an issue, it is more a configure/Makefile
isssue.

src/libsablevm/Makefile.am has some line like:
libsablevm_la_LIBADD =3D -lpthread -lm -lffi -lltdl -lrt

FreeBSD does not like -lpthread.
OS X does not like -lrt.

This is because functionnality is located elsewhere and there are
no such libXX.so file...  (Actually, on OS X, there is a single
libSystem that includes implementation of libc, libm, libpthread and
probably others.  libc etc. are only symlinks to libSystem.  But there
are no librt symlinks in the default installation)

A long time ago, I had:
if REQ_LPTHREAD
REQ_LIBS =3D -lpthread -lm -lffi -lltdl -lrt
else
REQ_LIBS =3D -lc_r -lm -lffi -lltdl -lrt
endif
libsablevm_la_LIBADD =3D ${REQ_LIBS}

where REQ_LPTHREAD was set in ./configure.ac.

This was ok for FreeBSD but will become more complex with -lrt on/off.
Note: I tried first with simpler things but automake/conf tools didn't
like it.  There are some restriction of what the right hand side arg
of libsablevm_la_LIBADD can be for the autoconf/make tools, don't
remember which one.

I will play more with it but any help/advice from autoconf/make expert
would be appreciated on the best way it could be done.


David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] adventures in not understanding the java stack

[David <db...@cs...>]

On Sat, Jan 17, 2004 at 12:21:30AM -0500, Chris Pickett wrote:
> So ... can somebody explain (3) for me?  Can native code affect stack=20
> values or control flow without going through the exception_handler: in=20
> interpreter.c or going through _svmf_stop_the_world?  If so, where does=
=20
> it do it?

Look at NATIVE_STATIC_METHOD and NATIVE_NONSTATIC_METHOD.

All the code to unwind the stack is in _svmf_interpreter.  Though the
exception object is built by the native method or one of the
method/function it calls.

GC is usually trigger by creating new instance and not enough memory.
There is also a native method that forces gc.
Java_java_lang_Runtime_gc.  There is a single gc entry point that will
stop all threads (except the current one) before doing the actual gc.
Look in gc_copying.c.

David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] adventures in not understanding the java stack

[David <db...@cs...>]

> 1) An exception being thrown in the callee (or one of the callee's=20
> callees), or some other exception-related irregular control flow --=20
> currently flagged at exception_handler: in interpreter.c, at ATHROW, an=
d=20
> at INTERNAL_CALL_END
> 2) GC being called in the callee (or one of the callee's callees) --=20
> flagged inside _svmf_stop_the_world()
> 3) The callee (or one of the callee's callees) being a native method.
>=20

> but ... I don't understand (3).
>=20

Hi Chris,

Native methods can throw exceptions and/or trigger garbage collection.


David


---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] adventures in not understanding the java stack

[Chris P. <chr...@ma...>]

Hello,

In order for speculation to work, I require the following to be true for 
INVOKE<X> instructions:

1) the method has fully exited and the instruction after the INVOKE<X> 
is the next instruction to be executed when the height of 
stack.current_frame returns to the height before the INVOKE<X> (this 
handles the problem of recursion)
2) the stack after the INVOKE<X> is identical to the stack before the 
INVOKE<X>, except for possibly popped parameters (including a possible 
objectref) and a possibly pushed return value.

I've found that the following can invalidate this:

1) An exception being thrown in the callee (or one of the callee's 
callees), or some other exception-related irregular control flow -- 
currently flagged at exception_handler: in interpreter.c, at ATHROW, and 
at INTERNAL_CALL_END
2) GC being called in the callee (or one of the callee's callees) -- 
flagged inside _svmf_stop_the_world()
3) The callee (or one of the callee's callees) being a native method.

I can understand (1) -- irregular control flow means that the stack 
returns to the same height without the instruction after the INVOKE<X> 
being next
I can understand (2) -- GC being called would change references on the 
stack, thus making requirement 2 fail

but ... I don't understand (3).

So ... can somebody explain (3) for me?  Can native code affect stack 
values or control flow without going through the exception_handler: in 
interpreter.c or going through _svmf_stop_the_world?  If so, where does 
it do it?

Also, is there anything else you can think of that might break 
requirements 1 and 2?

Cheers, and thanks for any suggestions,
Chris

[Sablevm-developer] staging update

[David <db...@cs...>]

Hi,

I moved more changes to SableVM/staging as I am currently attempting
to decrease my diffs with staging...


System with non-.so shared lib naming convention
------------------------------------------------
System independent library naming.
Class libraries had lib + name + .so hard coded.

This name computation has currently been moved to
VMSystem.mapLibraryName native function for now.

So Windows .dll or other name computation should go
to java_lang_VMSystem.c.

Note: This change should ideally be moved out of
      SableVM to Classpath.
Note: As I am writing this email, I am thinking it may
      be done entirely in Java provided that some
      properties to identify the platform.  But then the
      VM has to setup the properties...

Runtime.exec() and Process
--------------------------
* Cleanup and reimplemented Runtime.execInternal only with JNI methods
  as it should
  go to Classpath as a standard Unix fork/exec implementation, no?
* Other Process method impl moved.
* GetObjectArrayElement() implemented.

Fixes
-----
* Added test to see if lt_dlinit is successful.
* Fixed typo in comment.


David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] Accepted sablevm-classlib 1.0.9+svn20040115-1 (i386 source all)

[Grzegorz P. (D. D. <ga...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 16 Jan 2004 01:35:14 -0500
Source: sablevm-classlib
Binary: libsablevm-native1 libsablevm-classlib1-java
Architecture: source all i386
Version: 1.0.9+svn20040115-1
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description: 
 libsablevm-classlib1-java - GNU Classpath modified to work with SableVM JVM
 libsablevm-native1 - GNU Classpath modified to work with SableVM JVM (native part)
Changes: 
 sablevm-classlib (1.0.9+svn20040115-1) unstable; urgency=low
 .
   * NEW version of GNU Classpath. We're pulling SVN version, but
     don't be scared. It's *much* better than any previous version.
Files: 
 b9060eaab493d240263617667d4ef5e4 653 libs optional sablevm-classlib_1.0.9+svn20040115-1.dsc
 06bbc8fd89bf9f223fc5919c25d2700c 4739072 libs optional sablevm-classlib_1.0.9+svn20040115-1.tar.gz
 718f41216c3c318407bb6e54f2a2217d 1976032 libs optional libsablevm-classlib1-java_1.0.9+svn20040115-1_all.deb
 d036d9e052fdfb58df34b75d230743e1 318306 libs optional libsablevm-native1_1.0.9+svn20040115-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAB5zWcxjwiKS4/ekRAh7AAKC0ni7r2Wb6OgD/BhyzmJ8TGUbRJgCg0ow1
7kHcsTYRgYuR13pGgItSFYM=
=D0r8
-----END PGP SIGNATURE-----


Accepted:
libsablevm-classlib1-java_1.0.9+svn20040115-1_all.deb
  to pool/main/s/sablevm-classlib/libsablevm-classlib1-java_1.0.9+svn20040115-1_all.deb
libsablevm-native1_1.0.9+svn20040115-1_i386.deb
  to pool/main/s/sablevm-classlib/libsablevm-native1_1.0.9+svn20040115-1_i386.deb
sablevm-classlib_1.0.9+svn20040115-1.dsc
  to pool/main/s/sablevm-classlib/sablevm-classlib_1.0.9+svn20040115-1.dsc
sablevm-classlib_1.0.9+svn20040115-1.tar.gz
  to pool/main/s/sablevm-classlib/sablevm-classlib_1.0.9+svn20040115-1.tar.gz