Avian and Soft/Phantom References

[Terasgr]

Hello people
(no I won't resurrect an old thread - I'll create a new one)

I am experimenting with Avian and ReferenceQueues as well as SoftReference and PhantomReference.

Although these references seem to exist in Avian, it seems that they are not supported. Excuse me if I am wrong, but I think both of them behave like WeakReferences, thus making it impossible to practically use them.

A test case is trivial:
Create an Object which overrides its finalize method, keep a reference to this object in a SoftReference and run the GC.
It seems that it is freed automatically.

Likewise PhantomReference doesn't seem to fill up properly the ReferenceQueue - or at least not in a compatible manner.

I am more interested in PhantomReference (and how to fill its queue), and if there is some way that I can help to fix this issue. The reason it is required it's because after too much experimenting on the Java world, I'm convinced that PhantomReference queues is the only proper way to synchronize ObjC and Java objects.

[Joel Dice .]

Hi,

You're right that Avian treats SoftReferences as if they were
WeakReferences, but that seems to be within the scope of the
documentation:

"All soft references to softly-reachable objects are guaranteed to
have been cleared before the virtual machine throws an
OutOfMemoryError. Otherwise no constraints are placed upon the time at
which a soft reference will be cleared or the order in which a set of
such references to different objects will be cleared. Virtual machine
implementations are, however, encouraged to bias against clearing
recently-created or recently-used soft references." (from
https://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html).

Avian doesn't "bias against clearing recently-created or recently-used
soft references", but that's an optional feature.

Can you provide a specific, runnable test case illustrating how
PhantomReference is misbehaving?

Cheers,
Joel

> --
> You received this message because you are subscribed to the Google Groups
> "Avian" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to avian+un...@googlegroups.com.
> To post to this group, send email to av...@googlegroups.com.
> Visit this group at https://groups.google.com/group/avian.
> For more options, visit https://groups.google.com/d/optout.

[Terasgr]

Τη Τρίτη, 10 Οκτωβρίου 2017 - 10:21:53 μ.μ. UTC+3, ο χρήστης Joel Dice έγραψε:

Hi,

Can you provide a specific, runnable test case illustrating how
PhantomReference is misbehaving?

Cheers,
Joel

According to the documentation:

Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

This is "translated" in the referral JDK implementation, that, although the object reference is not directly accessible through the get() method, the object still exists (and can be retrieved through reflection.

[Joel Dice .]

Interesting. Note that the behavior has changed for Java 9, though:

http://mail.openjdk.java.net/pipermail/jdk9-hs-rt-changes/2015-December/001914.html
https://docs.oracle.com/javase/9/docs/api/java/lang/ref/PhantomReference.html

We could certainly change Avian to match the Java 8 behavior, but
given that Avian already matches the Java 9 behavior that seems like a
step backwards.

Can you explain what you're trying to do with PhantomReferences?
Perhaps there's an alternative approach that's compatible with Avian
and Java 9.

[Panayotis Katsaloulis]

Oh, not again...
If we manage to survive Java 9, we could survive anything...

BTW, are there any possible issues with Java 9? (I suspect no).

Also, do you accept additions to the core library, especially in the
functional interface?
:)
It is something I use all the time and I miss it - while I love the
minimalistic approach of the core avian libraries.

--
Panayotis Katsaloulis

[Joel Dice .]

I just tried building Avian with OpenJDK 9. There was a problem with
the Avian makefile where we try to parse the output of `java
-version`, but that was easy to fix. The more concerning problem is
that apparently the `-bootclasspath` flag is incompatible with
`-target 9`, and I don't know how to deal with that. There may be
other problems, too.

Yes, feel free to open PRs for standard library additions, as long as
its your own work (i.e. not copied from somewhere else).

[Terasgr]

Yes, feel free to open PRs for standard library additions, as long as
its your own work (i.e. not copied from somewhere else).

What is the preferred way to do this?

I mean, look at the docs and recreate the documented functionality?

Can I still keep the same parameter names for clarity, as well as the same generic names etc?

[Joel Dice .]

Yes, we've generally been using the JRE JavaDocs as a starting point.
I don't think it matters whether the parameter and generic names match
what's in the JavaDocs. If there's only one obvious name for
something, feel free to just use that name.

If you're not sure how a method or class should behave, you can write
a test and run the test on OpenJDK. In fact, you should write tests
for stuff you add anyway so we can add them to the test suite.

[Panayotis Katsaloulis]

I was thinking for a modest addition, namely the functional interface,
which is really obvious what it does.

By the way, I know I am hijacking the thread for a second time, but if
something goes wrong with the "bootimage-generator" tool, it breaks
with "Abort trap: 6", which is not really helpful.

How can I debug this and maybe find a solution why it crashed?

--
Panayotis Katsaloulis

[Joel Dice .]

Build with `mode=debug` and `MAKEFLAGS=` (which will show you the
commands make is running) and then run the bootimage-generator command
using gdb, e.g.:

gdb --args build/linux-x86_64-debug-bootimage/bootimage-generator -cp
build/linux-x86_64-debug-bootimage/classpath -bootimage
build/linux-x86_64-debug-bootimage/bootimage-bin.o -codeimage
build/linux-x86_64-debug-bootimage/codeimage-bin.o -bootimage-symbols
_binary_bootimage_bin_start:_binary_bootimage_bin_end
-codeimage-symbols
_binary_codeimage_bin_start:_binary_codeimage_bin_end -hostvm
build/linux-x86_64-interpret-debug/libjvm.so

Then you can run it and see where it is aborting.